9

在“Java 8 in action”一书中（由 Urma、Fusco 和 Mycroft 撰写）他们强调并行流在内部使用公共 fork 连接池，虽然这可以全局配置，例如使用 System.setProperty(...)，但不可能为单个并行流指定值。

我已经看到了涉及在定制的 ForkJoinPool 中运行并行流的解决方法。

在本书的后面，他们有一整章专门介绍 CompletableFuture，在此期间他们有一个案例研究，他们比较了使用 parallelStream 与 CompletableFuture 各自的性能。事实证明，它们的性能非常相似——它们强调这样做的原因是它们都默认使用相同的公共池（因此线程数量相同）。

他们继续展示了一个解决方案，并认为 CompletableFuture 在这种情况下更好，因为它可以配置为使用自定义 Executor，线程池大小由用户选择。当他们更新解决方案以利用它时，性能会显着提高。

这让我想到 - 如果使用上面突出显示的解决方法对并行流版本执行相同的操作，性能优势是否会相似，因此这两种方法会在性能方面再次变得相似吗？在这种情况下，当开发人员显然需要更多工作时，为什么要选择 CompletableFuture 而不是并行流。

4

1 回答 1

15

在这种情况下，当开发人员显然需要更多工作时，为什么要选择 CompletableFuture 而不是并行流。

恕我直言，这取决于您要支持的界面。如果您希望支持异步 API，例如

CompletableFuture<String> downloadHttp(URL url);

在这种情况下，只有一个可完成的未来才有意义，因为在等待数据下来时，您可能想做一些不相关的事情。

另一方面parallelStream()，最适合 CPU 密集型任务，您希望每个任务都执行部分工作。即每个线程都在用不同的数据做同样的事情。正如你的意思，它也更容易使用。

于 2016-01-22T11:17:27.640 回答