ForkJoinPool使用以及原理解读，通用流行框架大全

return t1.join() + t2.join()

替换为

return t2.join() + t1.join()

执行效率会略高一些，你会信吗？这个和join方法内的逻辑有关，如果任务最后一个加入，则可以优先执行，而不必等待

2.3 CountedCompleter任务

复杂且使用比较灵活；它可以通过内部逻辑把自己转化为RecursiveTask、RecursiveAction任务，也可以更灵活的使用，并且最大的不同就是其只有一个任务需要join操作且任务间并不阻塞线程池内部的调用，任务间的联系需要通过相应回调来触发，其通过完成回调方法合并其依赖的结果；内部增加了如下两个成员变量

final CountedCompleter<?> completer;
volatile int pending;

completer：依赖当前任务的节点；其像链表，但又不是，说是树可能更合适；最开始的那个任务，是树根节点，其依赖的为其孩子节点

pending： 当前节点依赖的节点个数，也可以说其孩子节点的个数；类中提供了一些列的方法操作，不介绍了；其内部方法调用时，都是先于0比较，然后，才会减少1，所以内部方法进行结束任务时，这个个数+1才是依赖的数目

一般情况下，我们不需直接对pending直接操作，可以使用其已经提供的一些方法进行操作，进而达到效果；方法有下面几个：

• tryComplete：当前点为出发点，向依赖其节点进行循环处理，遇到以下情况会结束

1. pending为0且依赖其的节点为空：pending为0时，回调onCompletion完成处理方法；若依赖其节点为空，则调用quietlyComplete方法设置执行状态为完成
2. 处理当前节点pending值-1成功

• propagateCompletion方法,和tryComplete方法相比，无onCompletion方法回调调用，也即对于每个中间任务无需关注

• quietlyCompleteRoot ： 依照指针域去寻找根依赖节点，并为其设置正常结束状态；比较暴力的结束任务状态，这种适合于找到某一个结果就停止

onCompletion回调方法

这个方法是仅仅通知当前任务所有依赖已经完成，用于任务合并操作，但却在此方法中仅仅知道最后一个完成的依赖任务；

为何CountedCompleter要设置正常结束状态，这时由于ForkJoinTask在执行方法的逻辑

final int doExec() {
int s; boolean completed;
if ((s = status) >= 0) {
try {
completed = exec();
} catch (Throwable rex) {
return setExceptionalCompletion(rex);
}
if (completed)
s = setCompletion(NORMAL);
}
return s;
}

也即是，现有ForkJoinTask的子类exec方法，均是返回true，而只有CountedCompleter返回false，所以其需要设置正常结束状态，任务才会被结算成执行完毕，在任务fork等调用时，才会结束阻塞；如果你只是往里