我已经尝试过可以由 CompletableFuture 完成的复杂用例，也可以由 ExecutorService 完成。这也包括处理异常。
我能看到它们之间的唯一区别是，CompletableFuture 在编码过程中提供了更好的可读性和便利性。
是否有任何实际优势/用例可以使用 CompletableFuture 解决，但不能使用 ExecutorService？
【问题讨论】：
标签： java multithreading java-8 future completable-future
想象一下简单的情况，你做动作A，当复杂的时候，用A的结果做B - 是Throwable还是一个有效的结果.再加上还没有CompletableFuture，你不想阻止。仅使用Futures 是否可行？嗯，是。实现起来很痛苦吗？非常。
不要被其 API 的“简单性”所迷惑。在您之前的问题中，您已经看到 not 为某些操作指定 ExecutorService 的作用。这种“简单”的包装还有很多很多更微妙的东西。
CompletableFuture 的非阻塞功能使其高度可用并被开发人员广泛采用。不仅是我们普通的开发者，还有 jdk 的开发者——整个 jdk http 客户端都是围绕CompletableFuture 构建的，这是有原因的。
你的问题不是 vs ExecutorService，而应该是 vs Future。 ExecutorService 仍然可以传递给 CompletableFuture 提供的方法。例如阅读this Q&A，了解各种方法的作用和作用。
【讨论】：
CompletableFuture 的主要优势（至少对我而言）是它允许以更高的概率构建复杂的异步进程，以便从一开始就正确，并且在一段时间后仍然能够理解逻辑。
当然大部分都可以使用 ExecutorService 来实现，这需要对其进行子类化，重写一些方法，重新提交任务......其中大部分都被 CompletableFuture 开箱即用。此外，每次 jdk 更新都会将最佳实践集成到 CompletableFuture 类中。
因此，使用 CompletableFuture 的实际原因是简单（好吧，您仍然需要了解如何使用它）。
例如：
CompletableFuture.supplyAsync(...)
.completeOnTimeout("foo" , 1, TimeUnit.SECONDS);
用ExecutorService来实现没那么简单。
【讨论】：
CompletableFuture 中有“可完成”的原因，这是很大的区别。我认为说实际原因只是简单太简单了，但我并不是说你错了。
Completable，而不是在此之前已经存在的Future。 Future 正在阻塞。想要将某些东西与结果联系起来吗？堵塞。来自 guava 的 ListebableFuture 试图解决这个问题。