forkjoin及其性能分析，是否比for循环快？

最近看了网上的某公开课，其中有讲到forkjoin框架。在这之前，我丝毫没听说过这个东西，很好奇是什么东东。于是，就顺道研究了一番。

总感觉这个东西，用的地方很少，也有可能是我才疏学浅。好吧，反正问了身边一堆猿，没有一个知道的。

因此，我也没有那么深入的去了解底层，只是大概的了解了其工作原理，并分析了下它和普通的for循环以及JDK8的stream流之间的性能对比（稍后会说明其中踩到的坑）。

一、forkjoin介绍

forkjoin是JDK7提供的并行执行任务的框架。 并行怎么理解呢，就是可以充分利用多核CPU的计算能力，让多个CPU同时进行任务的执行，从而使单位时间内执行的任务数尽量多，因此表现上就提高了执行效率。

它的主要思想就是，先把任务拆分成一个个小任务，然后再把所有任务汇总起来，简而言之就是分而治之。如果你了解过hadoop的MapReduce，就能理解这种思想了。不了解也没关系，下面画一张图，你就能明白了。

上边的任务拆分为多个子任务的过程就是fork，下边结果的归并操作就是join。（注意子任务和多线程不是一个概念，而是一个线程下会有多个子任务）

另外，forkjoin有一个工作窃取的概念。简单理解，就是一个工作线程下会维护一个包含多个子任务的双端队列。而对于每个工作线程来说，会从头部到尾部依次执行任务。这时，总会有一些线程执行的速度较快，很快就把所有任务消耗完了。那这个时候怎么办呢，总不能空等着吧，多浪费资源啊。

于是，先做完任务的工作线程会从其他未完成任务的线程尾部依次获取任务去执行。这样就可以充分利用CPU的资源。这个非常好理解，就比如有个妹子程序员做任务比较慢，那么其他猿就可以帮她分担一些任务，这简直是双赢的局面啊，妹子开心了，你也开心了。

二、实操测试性能

话不多说，先上代码，计算的是从0加到10亿的结果。

p