Die Methode latch.await() von CountDownLatch vs. Thread.join()

Question

Ich habe gesehen, wie ein stackoverflow-Member mit Thread.join() vorschlägt, einen "main" -Thread auf 2 "task" -Threads warten zu lassen.

Ich werde häufig etwas anderes machen (siehe unten) und ich möchte wissen, ob es irgendwelche Probleme mit meinem Ansatz gibt.

final CountDownLatch latch = new CountDownLatch(myItems.length); 

for (Item item : myItems) { 
    //doStuff launches a Thread that calls latch.countDown() as it's final act 
    item.doStuff(latch); 
} 

latch.await(); //ignoring Exceptions for readability 

Answer 1

Ihre Lösung ist einfacher zu skalieren. Thread.join() war eine sehr gute Möglichkeit, Ihr Problem zu lösen, bevor CountdownLatch und die anderen Synchronizer erstellt wurden.

In Bezug auf die Lesbarkeit würde ich den CountdownLatch-Ansatz über die Verbindung auf jedem Thread wählen. Auf diese Weise können Sie auch die Implementierung von Item ändern, um sie möglicherweise an einen Executor-Service zu senden, anstatt Threads direkt zu verwenden.

Answer 2

Der Countdown-Latch wird bevorzugt, um alle Threads gleichzeitig gleichzeitig zu starten.

Answer 3

Ich würde lieber eine Zukunft verwenden (einfach, wenn Sie einen ExecutorService verwenden). Warten Sie nach dem Absenden aller Aufgaben, bis alle fertig sind.

Collection<Future<Void>> futures = new ArrayList<Future<Void>>(myItems.length()); 
for (Runnable item : myItems) { 
    futures.add(executor.submit(item, null)); 

for (Future<Void> future : futures) 
    future.get(); //easy to add a timeout here 

Die endgültige For-Schleife könnte leicht in eine geeignete Methode getrennt werden. Dies kapselt die Synchronisation und erleichtert das Hinzufügen von Zeitüberschreitungen.

Es ist auch mehr auf den allgemeinen Fall anwendbar, wo die Worker-Threads tatsächlich ein Ergebnis zurückgeben müssen. (Wenn es Ihnen egal ist, was die Worker-Threads machen, warum müssen Sie dann auf sie warten?)