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)。一个任务，可以产生两个子任务，最终汇总成这个任务的结果。经典的实现方式有那么几种：
- 递归，自顶向下的思想，一直递归到f(1)为止。这样会产生一颗高log(n)的树，节点个数范围大约2^n。对栈的消耗是恐怖的指数级。
- 迭代，自底向上的思想，可以一直从f(1)开始计算到f(n)，循环中每次结果都是上一项加上再上一项的值，不仅不消耗栈，也没有分裂产生任务的需求。
- 递归 + 记忆。 每次计算该项前先去map，或者array容器中查询该项是否存在，若存在则直接返回，若不存在则取n-1以及n-2项，若有一项取不到，则将其递归取值，最后累加得到结果，放入容器，并返回。[因为f(n-1)=f(n-2)+f(n-3)，f(n-2)依次往下推都会被重复执行很多次]。
- 迭代 + 记忆。 自底向上计算，把每次循环的计算结果保存到容器中[这里就不去容器取了，加法的耗时可比去map取短多了]。那放容器有啥用。。用处就是：
- 下次有要取 [1…n]范围内的数的结果，可以直接取到，
- 下次要取的数m大于n时，可以从n开始自底向上计算，节约一大部分计算时间。
嗯。。有点扯远了，我要实践的是ForkJoinPool。那么从上面的四种经典实现，以及Fork拆分任务的特性，肯定只能只用递归的方法了，那么就基于第三种实现方式做改造。
先贴上第三种实现方式的代码：
/** * 递归的方式 + 缓存 */ public class Fib3 implements Fib{ public Map<Integer, Integer> fib = new HashMap<>(); @Override public 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; } @Override protected 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耗时 ：0 Process finished with exit code 0
- 结果很“感人”，用了ForkJoinPool反而变慢了，正常的递归+记忆，耗时1毫秒都不到。其实也很好理解的，斐波那契数列计算的一个函数耗时本来就很低，而且加了记忆化之后，就是一个get完事，这样的消耗远低于线程的创建、切换等开销。
- 实际业务场景上，用到线程池去处理的任务，他不会只是计算一点点东西，往往是十分耗时的，我们模拟sleep(30)，来进行尝试，再上方两个代码中都加上sleep，代码如下
// FORK @Override protected 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 @Override public 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耗时 ：1372 Process 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耗时 ：42438 Process finished with exit code 0
- 结果比较，
- 耗时比例是0.90，变化没有10毫秒改到500毫秒那么大。
- 忽略计算斐波那契数列耗时总体4ms不到的时间，比较实验三和实验四可以发现，Fib3耗时是原来的1.99（2）倍，而ForkJoinPool的方式也是原来的1.99(2)倍。个人之所以做这个比较，是认为ForkJoinPool应该是更小的数值，不是刚好2倍的，可能是例子不够正确吧。所以自己又增加了一组2000毫秒的，发现倍数两者都是1.98，姑且认为就是趋近线性的优化吧。
