ExecutorService.submit（Task）vs CompletableFuture.supplyAsync（Task，Executor）

Question

要並行或異步運行某些東西我可以使用ExecutorService： <T> Future<T> submit(Runnable task, T result); 或CompletableFuture Api： static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier, Executor executor); （讓我們假設我在兩種情況下都使用相同的Executor）

除了返回類型Future vs. CompletableFuture之外，還有任何顯着的差異。 或何時使用什么？

如果我將CompletableFuture API與默認的Executor （沒有執行程序的方法）一起使用，會有什么區別？

Answer 1

除了返回類型Future vs. CompletableFuture之外，還有任何顯着的差異。 或何時使用什么？

這真的很簡單。 當您希望執行線程等待異步計算響應時，可以使用Future 。 一個例子是並行合並/排序。 異步排序，同步排序，等待左邊完成（ future.get() ），合並結果。

當您希望執行某些操作時，使用CompleteableFuture ，結果在完成后，從執行的線程異步執行。 例如：我想異步進行一些計算，當我計算時，將結果寫入某個系統。 請求線程可能不需要等待結果。

您可以在單個Future可執行文件中模仿上述示例，但CompletableFuture提供了更流暢的界面和更好的錯誤處理。

這真的取決於你想做什么。

如果我使用CompletableFutureApi和默認的Executor（沒有執行程序的方法）有什么區別？

它將委托給ForkJoin.commonPool() ，它是系統上CPU數量的默認大小。 如果您正在執行IO密集型操作（讀取和寫入文件系統），則應以不同方式定義線程池。

如果它是CPU密集型的，那么使用commonPool最有意義。

Answer 2

CompletableFuture具有豐富的功能，如鏈接多個期貨，組合期貨，執行未來執行后的一些操作（同步和異步）等。

但是，就性能而言，CompletableFuture與Future沒有什么不同。 即使組合CompletableFuture的多個實例（最后使用.thenCombine和.join），除非我們調用.get方法，否則它們都不會被執行，在此期間，調用線程被阻止。 我覺得在性能方面，這並不比Future好。

如果我在這里遺漏了一些表現，請告訴我。

Answer 3

這為我澄清了未來可以完善的未來之間的區別： 未來與承諾的區別

CompletableFuture更像是一個承諾。