在"Java 8 in action"(Urma,Fusco和Mycroft)一书中,他们强调并行流在内部使用公共fork连接池,虽然这可以全局配置,例如使用System.setProperty(...),不可能为单个并行流指定值.
我已经看到了涉及在自定义ForkJoinPool中运行并行流的解决方法.
在本书的后面,他们有一整章致力于CompletableFuture,在此期间他们有一个案例研究,他们比较使用parallelStream VS和CompletableFuture的各自表现.事实证明它们的性能非常相似 - 它们强调了这一点的原因是它们都是默认使用相同的公共池(因此相同数量的线程).
他们继续展示解决方案并争辩说CompletableFuture在这种情况下更好,因为它可以被设置为使用自定义Executor,其用户选择的线程池大小.当他们更新解决方案以利用它时,性能得到显着改善.
这让我想到 - 如果使用上面强调的变通方法对并行流版本做同样的事情,那么性能优势是否会相似,那么这两种方法在性能方面是否会再次相似?在这种情况下,为什么人们会选择CompletableFuture而不是并行流,因为它显然需要开发人员更多的工作.
java parallel-processing multithreading java-stream completable-future