ForkJoinPool初体验

ForkJoinPool是什么

​ ForkJoinPool是JAVA中较新的线程池，先来尝试一下学习使用。他主要用来处理能够产生子任务的任务。

这个线程池是在 JDK 7 加入的，它的名字 ForkJoin 也描述了它的执行机制，主要用法和之前的线程池是相同的，也是把任务交给线程池去执行，线程池中也有任务队列来存放任务。但是 ForkJoinPool 线程池和之前的线程池有两点非常大的不同之处。第一点它非常适合执行可以产生子任务的任务。

如图所示，我们有一个 Task，这个 Task 可以产生三个子任务，三个子任务并行执行完毕后将结果汇总给 Result，比如说主任务需要执行非常繁重的计算任务，我们就可以把计算拆分成三个部分，这三个部分是互不影响相互独立的，这样就可以利用 CPU 的多核优势，并行计算，然后将结果进行汇总。这里面主要涉及两个步骤，第一步是拆分也就是 Fork，第二步是汇总也就是 Join，到这里你应该已经了解到 ForkJoinPool 线程池名字的由来了。

// 摘自《Java 并发编程 78 讲》

​ 以典型的斐波那契数列为例，f(n)=f(n-1)+f(n-2)。一个任务，可以产生两个子任务，最终汇总成这个任务的结果。经典的实现方式有那么几种：

1. 递归，自顶向下的思想，一直递归到f(1)为止。这样会产生一颗高log(n)的树，节点个数范围大约2^n。对栈的消耗是恐怖的指数级。
2. 迭代，自底向上的思想，可以一直从f(1)开始计算到f(n)，循环中每次结果都是上一项加上再上一项的值，不仅不消耗栈，也没有分裂产生任务的需求。
3. 递归 + 记忆。 每次计算该项前先去map，或者array容器中查询该项是否存在，若存在则直接返回，若不存在则取n-1以及n-2项，若有一项取不到，则将其递归取值，最后累加得到结果，放入容器，并返回。[因为f(n-1)=f(n-2)+f(n-3)，f(n-2)依次往下推都会被重复执行很多次]。
4. 迭代 + 记忆。 自底向上计算，把每次循环的计算结果保存到容器中[这里就不去容器取了，加法的耗时可比去map取短多了]。那放容器有啥用。。用处就是：
   1. 下次有要取 [1…n]范围内的数的结果，可以直接取到，
   2. 下次要取的数m大于n时，可以从n开始自底向上计算，节约一大部分计算时间。

嗯。。有点扯远了，我要实践的是ForkJoinPool。那么从上面的四种经典实现，以及Fork拆分任务的特性，肯定只能只用递归的方法了，那么就基于第三种实现方式做改造。

先贴上第三种实现方式的代码：

/*** 递归的方式 + 缓存*/
public class Fib3 implements Fib{public Map<Integer, Integer> fib = new HashMap<>();@Overridepublic int fib(int n) {Integer result = fib.get(n);if (result != null) {return result;} else {doFib(n);}return fib.get(n);}private void doFib(int n) {if (n <= 2) {fib.put(n, 1);return;}fib.put(n, fib(n - 1) + fib(n - 2));}
}

ForkJoinPool的使用

/*** FibForkJoin 递归 + 缓存*/
public class FibForkJoin2 extends RecursiveTask<Integer> {private volatile static Map<Integer, Integer> map = new ConcurrentHashMap<Integer, Integer>(50);int n;public FibForkJoin2(int n) {this.n = n;}@Overrideprotected Integer compute() {if (n <= 1) {return n;}if (map.get(n) != null) {return map.get(n);}// 分裂任务FibForkJoin2 f1 = new FibForkJoin2(n - 1);f1.fork();FibForkJoin2 f2 = new FibForkJoin2(n - 2);f2.fork();// 合并任务int result = f1.join() + f2.join();map.put(n, result);return result;}
}

MAIN方法测试

    public static void main(String[] args) {int n = 45;ForkJoinPool forkJoinPool = new ForkJoinPool();long endTime;long startTime = System.currentTimeMillis();ForkJoinTask<Integer> task = forkJoinPool.submit(new FibForkJoin2(n));try {System.out.println(task.get());endTime = System.currentTimeMillis();System.out.println("forkJoin耗时 ：" + (endTime - startTime) );} catch (InterruptedException | ExecutionException e) {e.printStackTrace();}Fib3 fib3 = new Fib3();startTime = System.currentTimeMillis();System.out.println(fib3.fib(n));endTime = System.currentTimeMillis();System.out.println("Fib3耗时 ：" + (endTime - startTime) );}

测试结果一

1134903170
forkJoin耗时 ：4
1134903170
Fib3耗时 ：0Process finished with exit code 0

• 结果很“感人”，用了ForkJoinPool反而变慢了，正常的递归+记忆，耗时1毫秒都不到。其实也很好理解的，斐波那契数列计算的一个函数耗时本来就很低，而且加了记忆化之后，就是一个get完事，这样的消耗远低于线程的创建、切换等开销。

• 实际业务场景上，用到线程池去处理的任务，他不会只是计算一点点东西，往往是十分耗时的，我们模拟sleep(30)，来进行尝试，再上方两个代码中都加上sleep，代码如下

// FORK@Overrideprotected Integer compute() {if (n <= 1) {return n;}if (map.get(n) != null) {try {Thread.sleep(30);} catch (InterruptedException e) {e.printStackTrace();}return map.get(n);}FibForkJoin2 f1 = new FibForkJoin2(n - 1);f1.fork();FibForkJoin2 f2 = new FibForkJoin2(n - 2);f2.fork();int result = f1.join() + f2.join();map.put(n, result);return result;}// FIB3
@Overridepublic int fib(int n) {Integer result = fib.get(n);if (result != null) {try {Thread.sleep(30);} catch (InterruptedException e) {e.printStackTrace();}return result;} else {doFib(n);}return fib.get(n);}

实验结果二

1134903170
forkJoin耗时 ：1252
1134903170
Fib3耗时 ：1372Process finished with exit code 0

• 从实验结果二来看，单个仅仅是任务耗时需要10毫秒时，用ForkJoinPool就开始体现优势了。那么再试试高时延的情况，比如改成500毫秒再来尝试

实验结果三

1134903170
forkJoin耗时 ：19235
1134903170
Fib3耗时 ：21231

• 比较结果二以及结果三
  • 实验二耗时比例是0.912，实验三耗时比例是0.90。得出结论一：在高耗时的任务中，耗时越高，ForkJoinPool体现的优势越大。

那么想看看进一步增加耗时会如何，将sleep的时间调整到1000毫秒。

实验结果四

1134903170
forkJoin耗时 ：38345
1134903170
Fib3耗时 ：42438Process finished with exit code 0

• 结果比较，
  • 耗时比例是0.90，变化没有10毫秒改到500毫秒那么大。
  • 忽略计算斐波那契数列耗时总体4ms不到的时间，比较实验三和实验四可以发现，Fib3耗时是原来的1.99（2）倍，而ForkJoinPool的方式也是原来的1.99(2)倍。个人之所以做这个比较，是认为ForkJoinPool应该是更小的数值，不是刚好2倍的，可能是例子不够正确吧。所以自己又增加了一组2000毫秒的，发现倍数两者都是1.98，姑且认为就是趋近线性的优化吧。