parallelSteam高性能：并行计算惹的祸

Java 中提供了ForkJoinPool 并发流式计算框架，推荐系统中也大量使用 parallelSteam 进行业务处理，提高系统处理能力，如：批量获取Status

ForkJoinPool相比之前Java6中的线程池来说使用更加方便（流式计算），Fork-Join的模式也比ThreadPoolExecutor中的BlockingQueue更友好。

 

那么是不是所有的stream调用都应该使用parallelSteam呢？

1、并发消耗更多的资源

https://stackoverflow.com/questions/20375176/should-i-always-use-a-parallel-stream-when-possible

 

实际上，并行计算（parallelStream）比stream 消耗更多的计算资源（更多的比较运算，额外的任务分配、子任务协调）。

如果说有什么优势的话，只能说利用多个同时计算比使用单核计算可能更快；或者主要的执行时间是等待远程返回。

如果业务已经使用了多核的处理能力，如Tomcat容器（每个请求一个线程，多请求并发执行），内部再用一层parallelStream的并发, 整体的处理能力可能会下降。

NQ Model 给出了parallel 加速的形式化描述：NQ > 10000

 

如果没有确认并行计算能够真实改善性能，不要使用。

 

2、公共线程池的灾难

很可能你一个简单的调用，但被其他复杂的任务阻塞了，获得不了计算资源。

如果你不知道谁会使用到线程池，那就不要使用。如果确认有必要使用parallelStream的话，申请特定的线程池，确保该线程池的任务不会相互影响。

 

3、并发计算不能使用ThreadLocal

ThreadLocal作为线程执行的上下文，提供了高速的访问的缓冲区，比传递参数或使用全局的LocalCache更加高效。（ThreadLocal只能线程内访问，不需要考虑多线程并发冲突）

附：Understanding Parallel Stream Performance in Java SE 8

 PDF

thradLoad见我之前的博客:https://blog.csdn.net/singgel/article/details/100899095