并行流和CompletableFuture之间的差异 [英] Difference between parallel stream and CompletableFuture

问题描述

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

In the book "Java 8 in action" (by Urma, Fusco and Mycroft) they highlight that parallel streams internally use the common fork join pool and that whilst this can be configured globally, e.g. using System.setProperty(...), that it is not possibly to specify a value for a single parallel stream.

我已经看到解决方法在自定义的ForkJoinPool中运行并行流。

I have since seen the workaround that involves running the parallel stream inside a custom made ForkJoinPool.

在本书的后面，他们有一整页专门讨论CompletableFuture，在此期间他们有一个案例研究，他们比较使用parallelStream VS和CompletableFuture的相应性能。事实证明他们的表现非常相似 - 他们强调这是因为他们都是默认使用相同的公共池（因此相同数量的线程）。

Later on in the book, they have an entire chapter dedicated to CompletableFuture, during which they have a case study where they compare the respective performance of using a parallelStream VS a CompletableFuture. It turns out their performance is very similar - they highlight the reason for this as being that they are both as default using the same common pool (and therefore the same amount of threads).

他们继续展示解决方案并争辩说CompletableFuture在这种情况下更好，因为它可以被设置为使用自定义Executor，用户选择的线程池大小。当他们更新解决方案以利用它时，性能会得到显着提升。

They go on to show a solution and argue that the CompletableFuture is better in this circumstance as it can be congifured to use a custom Executor, with a thread pool size of the user's choice. When they update the solution to utilise this, the performance is significantly improved.

这让我想到 - 如果有人对使用变通方法的并行流版本做同样的事情如上所述，性能优势是否相似，两种方法在性能方面是否会再次相似？在这种情况下，为什么人们会选择CompletableFuture而不是并行流，因为它显然需要开发人员更多的工作。

This made me think - if one were to do the same for the parallel stream version using the workaround highlighted above, would the performance benefits be similar, and would the two approaches therefore become similar again in terms of performance? In this case, why would one choose the CompletableFuture over the parallel stream when it clearly takes more work on the developer's part.

推荐答案

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

In this case, why would one choose the CompletableFuture over the parallel stream when it clearly takes more work on the developer's part.

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

IMHO This depends on the interface you are looking to support. If you are looking to support an asynchronous API e.g.

CompletableFuture<String> downloadHttp(URL url);

在这种情况下，只有可以完善的未来才有意义，因为你可能想做一些与你无关的事情等待数据下降。

In this case, only a completable future makes sense because you may want to do something else unrelated while you wait for the data to come down.

另一方面， parallelStream（）最适合CPU绑定任务你希望每项任务都能完成一部分工作。即每个线程使用不同的数据做同样的事情。你的意思是它也更容易使用。

On the other hand parallelStream() is best for CPU bound tasks where you want every tasks to perform a portion of some work. i.e. every thread is doing the same thing with different data. As you meantion it is also easier to use.

这篇关于并行流和CompletableFuture之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！