İplik havuzlarının ve Çatal/Birleşmenin nihai hedefi aynıdır:
Her ikisi de mevcut CPU gücünü maksimum verim için ellerinden
gelenin en iyisini kullanmak ister. Maksimum verim, mümkün
olduğunca çok sayıda görevin uzun bir sürede tamamlanması gerektiği
anlamına gelir. Bunu yapmak için ne gerekiyor? (Aşağıdakiler için
hesaplama görevlerinde herhangi bir eksiklik olmadığı
varsayılacaktır:% 100 CPU kullanımı için her zaman yeterli
olacaktır.Ayrıca "CPU" hiper-iş parçacığı durumunda çekirdekler
veya sanal çekirdekler için eşdeğer olarak kullanıyorum).
- En azından, CPU'lar mevcut olduğu için çalışan çok sayıda iş
parçacığına ihtiyaç vardır, çünkü daha az iş parçacığının
çalıştırılması çekirdek kullanılmadan bırakılır.
- En yüksek düzeyde, CPU'lar mevcut olduğu kadar çok sayıda iş
parçacığı olmalıdır çünkü daha fazla iş parçacığının
çalıştırılması, CPU'ları farklı iş parçacıklarına atayan
Zamanlayıcı için ek yük oluşturacaktır; bu, bazı CPU zamanlarının,
bizim hesaplamamıza değil, zamanlayıcıya gitmesine neden olur.
görev.
Böylece, maksimum verim için, CPU'lardan tam olarak aynı sayıda
ipliğe sahip olmamız gerektiğini anladık. Oracle'ın bulanıklaştırma
örneğinde, hem mevcut CPU'ların sayısına eşit sayıda iş parçacığı
sayısına sahip bir sabit boyutlu iş parçacığı havuzu alabilir veya
bir iş parçacığı havuzu kullanabilirsiniz. Fark etmez,
haklısın!
So when will you get into trouble with a thread pools?
That is if a thread blocks, because your thread is waiting
for another task to complete. Assume the following example:
class AbcAlgorithm implements Runnable {
public void run() {
Future aFuture = threadPool.submit(new ATask());
StepBResult bResult = stepB();
StepAResult aResult = aFuture.get();
stepC(aResult, bResult);
}
}
Burada gördüğümüz, üç adım A, B ve C'den oluşan bir
algoritmadır. A ve B birbirinden bağımsız olarak
gerçekleştirilebilir, ancak C aşaması, A ve B adımının sonucuna
ihtiyaç duyar. Bu algoritmanın yaptığı şey, A görevine gönderilir.
threadpool ve doğrudan görev b gerçekleştirin. Bundan sonra iş
parçacığı A işinin yapılması için bekleyecek ve adım C ile devam
edecektir. A ve B aynı anda tamamlanırsa, her şey yolunda. Ama ya
B'nin B'den daha uzun sürmesi? Bunun sebebi A görevinin doğasını
gerektirdiğinden, ancak durum böyle olmayabilir çünkü Görev
için iş parçacığı Başlangıçta mevcut A ve görev A'nın beklemesi
gerekiyor. (Eğer sadece tek bir CPU mevcutsa ve bu yüzden
threadpool'unuz sadece tek bir iş parçacığına sahipse, bu bile bir
kilitlenmeye neden olacaktır, ancak şimdilik bu noktaya ek olarak).
Bunun anlamı, sadece B görevini yürüten iş parçacığının tüm
iş parçacığını engellemesidir . CPU'lar ile aynı sayıda iş
parçacığına sahip olduğumuzdan ve bir iş parçacığı
engellendiğinden, bir CPU boşta kalıyor demektir
.
Çatal/Birleştir bu sorunu çözer: Çatal/birleştirme çerçevesinde,
aşağıdaki gibi aynı algoritmayı yazarsınız:
class AbcAlgorithm implements Runnable {
public void run() {
ATask aTask = new ATask());
aTask.fork();
StepBResult bResult = stepB();
StepAResult aResult = aTask.join();
stepC(aResult, bResult);
}
}
Aynı görünüyor değil mi? Ancak ipucu, aTask.join
'un engellenmeyeceğidir . Bunun yerine
çalınan çalınan burada devreye girer: İş parçacığı
geçmişte çatallanmış olan diğer işler için etrafa bakacak ve
bunlarla devam edecektir. Öncelikle, kendisine attığı görevlerin
işlenmeye başladığını kontrol eder. Bu yüzden eğer A henüz başka
bir iş parçacığı tarafından başlatılmamışsa, bir sonraki görevini
yapar, aksi takdirde diğer iş parçacıklarının sırasını kontrol eder
ve işlerini çalacaktır. Başka bir iş parçacığının bu görevi
tamamlandığında, A'nın şimdi tamamlanıp tamamlanmadığını kontrol
eder. Yukarıdaki algoritma ise stepC 'yi arayabilir.
Aksi takdirde çalmak için başka bir görev arar. Böylece
çatal/birleştirme havuzları, engelleme eylemleri karşısında
bile% 100 CPU kullanımı sağlayabilir .
Ancak bir tuzak vardır: İşten çalma sadece
ForkJoinTask 'un join çağrısı için
mümkündür. Başka bir iş parçacığı beklemek veya bir G/Ç eylemi
beklemek gibi harici engelleme eylemleri için yapılamaz. Peki ya,
I/O'nun tamamlanmasını beklemek ortak bir görev midir? Bu durumda,
engelleme eylemi tamamlanır tamamlanmaz durdurulacak olan
Çatal/Birleştir havuzuna ek bir iş parçacığı ekleyebilirsek,
yapılacak en iyi ikinci şey olacaktır. Ve ForkJoinPool
aslında ManagedBlocker kullanıyorsak bunu
yapabilir.
Fibonacci
RecursiveTask için JavaDoc bir Çatal/Birleştir
kullanarak Fibonacci sayılarını hesaplamak için örnek. Klasik
özyinelemeli bir çözüm için bkz.
public static int fib(int n) {
if (n <= 1) {
return n;
}
return fib(n - 1) + fib(n - 2);
}
Açıklandığı gibi JavaDocs, fibonacci sayılarını hesaplamak için
oldukça basit bir yoldur, çünkü bu algoritmanın O (2 ^ n)
karmaşıklığı vardır, ancak daha basit yollar mümkündür. Ancak bu
algoritma çok basit ve anlaşılması kolay, bu yüzden ona bağlıyız.
Bunu Çatal/Katıl ile hızlandırmak istediğimizi varsayalım. Saf bir
uygulama şöyle görünecekti:
class Fibonacci extends RecursiveTask {
private final long n;
Fibonacci(long n) {
this.n = n;
}
public Long compute() {
if (n <= 1) {
return n;
}
Fibonacci f1 = new Fibonacci(n - 1);
f1.fork();
Fibonacci f2 = new Fibonacci(n - 2);
return f2.compute() + f1.join();
}
}
Bu Görev'in ayrıldığı adımlar çok kısadır ve bu yüzden de
korkunç bir şekilde çalışacaktır, ancak çerçevenin genel olarak
nasıl çok iyi çalıştığını görebilirsiniz: İki summand bağımsız
olarak hesaplanabilir, ancak her ikisine de finali oluşturmak için
ihtiyaç duyarız. sonuç. Yani bir yarısı başka bir iş parçacığında
yapılır. Çarpışmaya girmeden iplik havuzlarıyla aynı işi yapmak
(mümkün, ama neredeyse basit değil).
Sadece tamlık için: Bu özyinelemeli yaklaşımı kullanarak
Fibonacci sayılarını gerçekten hesaplamak istiyorsanız, optimize
edilmiş bir versiyon:
class FibonacciBigSubtasks extends RecursiveTask {
private final long n;
FibonacciBigSubtasks(long n) {
this.n = n;
}
public Long compute() {
return fib(n);
}
private long fib(long n) {
if (n <= 1) {
return 1;
}
if (n > 10 && getSurplusQueuedTaskCount() < 2) {
final FibonacciBigSubtasks f1 = new FibonacciBigSubtasks(n - 1);
final FibonacciBigSubtasks f2 = new FibonacciBigSubtasks(n - 2);
f1.fork();
return f2.compute() + f1.join();
} else {
return fib(n - 1) + fib(n - 2);
}
}
}
This keeps the subtasks much smaller because they are only split
when n > 10 && getSurplusQueuedTaskCount() <
2 is true, which means that there are significantly more
than 100 method calls to do (n > 10) and there are
not very man tasks already waiting
(getSurplusQueuedTaskCount() < 2).
Bilgisayarımda (Hyper-threading sayılırken 8 çekirdek), Intel
(R) Core (TM) i7-2720QM CPU @ 2.20GHz) fib (50) klasik
yaklaşımla 64 saniye sürüyor ve teorik olarak mümkün olmasa da
oldukça dikkat çekici bir kazanç olan Çatal/Birleştirme yaklaşımı
ile sadece 18 saniye.
özet
- Evet, Örneğinizde Çatal/Birleştir'in klasik iplik havuzlarına
göre avantajı yoktur.
- Engel/Katılma, engelleme söz konusu olduğunda performansı
önemli ölçüde artırabilir
- Çatal/Katılma bazı kilitlenme sorunlarını giderir