ForkJoinPool专为可递归分解合并的计算型任务设计，适用于归并排序、树遍历等场景；不适用于I/O或阻塞操作，需避免共享状态，合理设置并行度与拆分阈值。
适合递归分治类任务，比如归并排序、快速排序、树遍历
ForkJoinPool 的核心价值在于高效调度可拆分的计算型任务，不是所有并发场景都适用。它专为 ForkJoinTask 设计，尤其是能自然递归分解（fork）再合并（join）的任务。
典型场景包括：
- 对大规模数组做归并排序：每次将数组一分为二，递归排序后
merge - 计算斐波那契数列（仅作演示，实际不推荐——因重复计算多且不可控）
- 遍历深层嵌套的 JS
ON 或 XML 树，对每个节点做独立转换或校验
- 图像分块处理（如滤镜应用），每块独立计算，最后拼接
关键判断点：任务是否满足「可忽略共享状态 + 拆分后子任务粒度均衡 + 合并开销小」。否则容易因过度 fork/join 反而拖慢性能。
不适合 I/O 密集型或阻塞型操作
ForkJoinPool.commonPool() 默认使用「并行度 = CPU 核心数 - 1」的线程数，且所有线程都是 daemon 线程、不允许 block。一旦在 compute() 中调用 Thread.sleep()、Object.wait()、InputStream.read() 或数据库查询，就会卡住工作线程，导致整个池吞吐骤降甚至死锁。
如果必须混合 I/O，正确做法是：
- 用单独的
ThreadPoolExecutor处理 I/O，结果再交由 ForkJoinPool 做后续计算 - 显式创建带自定义
ForkJoinPool并增大并行度（不推荐，掩盖设计问题） - 改用
CompletableFuture.supplyAsync(..., executor)组合不同线程池
常见错误现象：ForkJoinPool 看似“卡住”或响应极慢，但 jstack 显示大量线程停在 Unsafe.park —— 实际是被阻塞操作拖住，而非任务没完成。
RecursiveTask 和 RecursiveAction 的选择取决于是否需要返回值
两者都继承自 ForkJoinTask，区别仅在类型签名：
-
RecursiveTask：适用于有返回值的计算，如求和、查找最大值、构建新对象 -
RecursiveAction：适用于无返回值的副作用操作，如批量修改数组元素、写日志、触发回调
不要为了省事强行用 RecursiveAction 去“绕过”返回值需求——比如在字段里 accumulate 结果。这会破坏 work-stealing 的局部性，也使异常传播变复杂。示例中常见的反模式：
class BadSumAction extends RecursiveAction {
private final int[] arr;
private final AtomicInteger sum = new AtomicInteger(); // ❌ 共享可变状态 + 非 final
...
}应改为：
class GoodSumTask extends RecursiveTask{ private final int[] arr; private final int lo, hi; GoodSumTask(int[] arr, int lo, int hi) { this.arr = arr; this.lo = lo; this.hi = hi; } protected Integer compute() { if (hi - lo <= 1000) { // 阈值需实测调整 return IntStream.range(lo, hi).map(i -> arr[i]).sum(); } int mid = (lo + hi) / 2; GoodSumTask left = new GoodSumTask(arr, lo, mid); GoodSumTask right = new GoodSumTask(arr, mid, hi); left.fork(); // 异步提交左任务 int rightResult = right.compute(); // 当前线程算右任务 int leftResult = left.join(); // 等待左任务结果 return leftResult + rightResult; } }
并行度设置和阈值（threshold）直接影响性能
ForkJoinPool 不是“开箱即用就快”，两个参数必须按 workload 调整：
-
parallelism：影响线程总数。默认用commonPool()是Runtime.getRuntime().availableProcessors() - 1；CPU 密集型任务一般不建议超过该值 -
threshold（拆分阈值）：决定何时停止 fork、转为直接计算。设太小 → 过度拆分，任务调度开销盖过计算收益；设太大 → 无法充分利用多核，部分线程空闲
没有银弹阈值。建议从 arr.length / (4 * parallelism) 起步，在目标机器上用 JMH 实测。特别注意：阈值应基于「计算成本」而非数据量——例如对每个元素做哈希运算，阈值应比单纯加法更大。
容易被忽略的一点：ForkJoinPool 内部使用双端队列（deque）实现 work-stealing，但只对当前线程的 deque 做 push/pop；其他线程只能从 deque 尾部 steal。这意味着任务拆分结构若严重不均（如左子树深、右子树浅），会导致 stealing 效率下降——这不是配置问题，是算法本身缺陷。
