ExecutorService.submit (Aufgabe) vs CompletableFuture.supplyAsync (Aufgabe, Executor)

Question

Um einige Sachen parallel zu laufen oder Asynchron i entweder eine ExecutorService verwenden können: <T> Future<T> submit(Runnable task, T result); oder CompletableFuture Api: static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier, Executor executor); (Lets i in beiden Fällen verwenden die übernehmen gleicher Executor)

Neben dem Rückgabetyp Future vs. CompleableFuture gibt es bemerkenswerte Unterschiede. Oder Wann soll was genutzt werden?

Und was sind die Unterschiede, wenn ich die CompletableFutureApi mit Standard Executor (die Methode ohne Executor) verwenden?

Answer 1

Neben dem Rückgabetyp Future vs. CompleableFuture gibt es bemerkenswerte Unterschiede. Oder Wann soll was genutzt werden?

Es ist wirklich ziemlich einfach. Sie verwenden die Future, wenn Sie möchten, dass der ausführende Thread auf asynchrone Berechnungsantwort wartet. Ein Beispiel dafür ist eine parallele Zusammenführung/Sortierung. Sortiere asynchron links, sortiere synchron, warte nach links, um abzuschließen (future.get()), füge Ergebnisse zusammen.

Sie verwenden eine CompleteableFuture, wenn Sie möchten, dass eine Aktion mit dem Ergebnis nach Abschluss asynchron vom ausgeführten Thread ausgeführt wird. Zum Beispiel: Ich möchte einige Berechnungen asynchron durchführen und die Ergebnisse bei der Berechnung in ein System schreiben. Der anfordernde Thread muss dann möglicherweise nicht auf ein Ergebnis warten.

Sie können das obige Beispiel in einer einzigen ausführbaren Future-Datei nachahmen, aber die CompletableFuture bietet eine flüssigere Schnittstelle mit besserer Fehlerbehandlung.

Es hängt wirklich davon ab, was Sie tun möchten.

Und was sind die Unterschiede, wenn ich die CompletableFutureApi mit Standard Executor (die Methode ohne Executor) verwenden?

Es wird an ForkJoin.commonPool() delegieren, die eine Standardgröße zu der Anzahl der CPUs auf Ihrem System ist. Wenn Sie etwas IO-intensives (Lesen und Schreiben in das Dateisystem) tun, sollten Sie den Thread-Pool anders definieren.

Wenn es CPU-intensiv ist, macht die Verwendung des commonPool am meisten Sinn.

Answer 2

CompletableFuture reiche Funktionen wie Verkettungs mehr Futures hat, die Futures-Kombination, die Ausführung eine Aktion nach der Zukunft ausgeführt wird (sowohl synchron als auch asynchron) usw.

ist jedoch CompletableFuture nicht anders als Zukunft in Bezug auf Performance. Selbst wenn mehrere Instanzen von CompletableFuture kombiniert werden (mit .thenCombine und .join am Ende), wird keine davon ausgeführt, es sei denn, wir rufen die Methode .get auf und während dieser Zeit wird der aufrufende Thread blockiert. Ich fühle mich in Sachen Leistung nicht besser als Future.

Bitte lassen Sie mich wissen, wenn mir hier ein Aspekt der Leistung fehlt.

Answer 3

Das ist für mich geklärt den Unterschied zwischen Zukunft eine komplettierbar Zukunft ein bisschen mehr: Difference between Future and Promise

CompletableFuture eher wie ein Versprechen.