ForkJoin框架是Java 7专为分治型并行任务设计的轻量级并发框架，适用于可递归拆分、子任务独立且需合并结果的计算密集型场景；它通过工作窃取算法提升CPU利用率，要求任务继承RecursiveTask或RecursiveAction以支持fork/join协作，普通Runnable/Callable会退化为普通线程池行为；使用时需合理设置拆分阈值、避免共享状态、正确处理异常，并优先判断任务是否真正适合fork-join模式。
ForkJoin框架是Java 7引入的、专为**分治型并行任务**设计的轻量级并发框架，它不是通用线程池替代品，而是针对“可递归拆分 + 独立子任务 + 合并结果”这类计算密集型场景做了深度优化。
为什么不能直接用 Executors.newFixedThreadPool 做递归并行？
普通线程池对 fork-join 模式支持差：子任务提交后无法主动“窃取”其他线程的待执行任务，容易导致部分线程空闲、部分线程过载；且没有内置的 join() 阻塞等待 + 结果合并机制。
-
ForkJoinPool内部采用工作窃取（work-stealing）算法：每个线程维护双端队列，空闲时从其他线程队列尾部“偷”任务，大幅提升 CPU 利用率 - 子任务必须继承
ForkJoinTask的子类（如RecursiveTask或RecursiveAction），才能触发fork()/join()协作流程 - 普通
Runnable或Callable提交到ForkJoinPool中，会失去窃取能力，退化为普通线程池行为
RecursiveTask 和 RecursiveAction 怎么选？
看任务是否需要返回结果：
- 要返回值 → 用
RecursiveTask<T>，重写compute()并返回T类型结果 - 纯执行无返回 → 用
RecursiveAction，重写compute()但不返回值 - 二者都必须显式调用
this.fork()拆分子任务，再用this.join()获取结果（RecursiveTask）或同步等待（RecursiveAction）
class SumTask extends RecursiveTask<Long> {
private final int[] array;
private final int lo, hi;
<pre class='brush:java;toolbar:false;'>SumTask(int[] array, int lo, int hi) {
this.array = array;
this.lo = lo;
this.hi = hi;
}
protected Long compute() {
if (hi - lo <= 1000) { // 阈值控制，避免过度拆分
long sum = 0;
for (int i = lo; i < hi; i++) sum += array[i];
return sum;
}
int mid = (lo + hi) / 2;
SumTask left = new SumTask(array, lo, mid);
SumTask right = new SumTask(array, mid, hi);
left.fork(); // 异步提交左子任务
long rightResult = right.compute(); // 当前线程直接算右子任务（避免阻塞）
long leftResult = left.join(); // 等待左子任务完成
return leftResult + rightResult;
}}
立即学习“Java免费学习笔记（深入）”；
常见踩坑点：阈值设置、共享状态、异常处理
实际用起来最容易出问题的不是逻辑，而是这几个细节：
-
threshold（拆分阈值）太小 → 创建过多任务对象，GC 压力大，反而比串行慢；太大 → 并行度不足。建议从array.length / Runtime.getRuntime().availableProcessors()开始试 - 切忌在
compute()中修改外部共享变量（如 static 计数器），ForkJoinPool 不保证执行顺序，也不提供同步保障 - 子任务抛出异常时，
join()会包装成ExecutionException；若想捕获原始异常，需调用getRawResult()或检查getException() - 默认使用
ForkJoinPool.commonPool()，但该池是 daemon 线程池，JVM 退出时不会等待其完成 —— 长期运行服务中建议显式创建new ForkJoinPool(4)并管理生命周期
真正用好 ForkJoin，关键不在“怎么写递归”，而在判断“这个任务是否适合 fork-join”：数据可分段、子任务无依赖、合并成本低、整体是 CPU-bound。IO 或锁竞争多的任务强行套用，只会更慢。
