ForkJoinPool 仅适用于具备分治特征的计算密集型任务。适合场景包括并行排序、递归求和、归并排序、树形遍历、蒙特卡洛采样；不适合IO密集型、粗粒度或强依赖任务。
ForkJoinPool 不是万能加速器，盲目替换 ExecutorService 反而可能降低性能。它只在任务可分解、子任务轻量、且存在显著计算密集型工作时才体现优势。
什么时候该用 ForkJoinPool 而不是普通线程池？
核心判断依据是任务结构：是否天然具备“分治（divide-and-conquer）”特征。
- 适合场景：
Arrays.parallelSort()、递归求和/最大值、归并排序、树形结构遍历（如 JSON 解析、AST 遍历）、蒙特卡洛模拟中大量独立采样 - 不适合场景：IO 密集型任务（如 HTTP 请求、数据库查询）、任务粒度太粗（单个子任务耗时 > 100ms）、任务之间强依赖或需严格顺序执行
- 关键信号：你正在写一个递归方法，并且每次递归调用都处理数据的一个子区间 —— 这正是
ForkJoinTask的主场
compute() 方法里别直接 join()，要用 invokeAll() 或异步 fork + join
手动管理 fork/join 顺序直接影响工作窃取效率。常见错误是写成同步阻塞式调用：
protected Long compute() {
if (end - start <= THRESHOLD) {
return computeDirectly();
}
int mid = (start + end) / 2;
// ❌ 错误：先 fork 左，再立刻 join 左 → 阻塞当前线程，无法窃取
LeftTask left = new LeftTask(arr, start, mid).fork();
long leftResult = left.join(); // 这里卡住，右任务还没 fork！
RightTask right = new RightTask(arr, mid, end).fork();
return leftResult + right.join();
}正确做法是先 fork 所有子任务，再统一 join：
立即学习“Java免费学习笔记（深入）”；
protected Long compute() {
if (end - start <= THRESHOLD) return computeDirectly();
int mid = (start + end) / 2;
// ✅ 正确：两个都 fork 出去，当前线程空闲可窃取其他队列任务
ForkJoinTask<Long> left = new SumTask(arr, start, mid).fork();
ForkJoinTask<Long> right = new SumTask(arr, mid, end).fork();
return left.join() + right.join(); // 此时才等结果
}更简洁的写法是直接用 invokeAll(left, right)，它内部已做最优调度。
别忽略 parallelism 参数和默认构造行为
ForkJoinPool 的并行度不是 CPU 核心数那么简单，配置不当会导致线程闲置或过度竞争：
-
new ForkJoinPool()使用ForkJoinPool.getCommonPoolParallelism()，默认为Runtime.getRuntime().availableProcessors() - 1（Common Pool 会受 JVM 参数-Djava.util.concurrent.ForkJoinPool.common.parallelism影响） - 自定义池建议显式指定并行度：
new ForkJoinPool(4)，尤其在容器化环境（CPU quota 限制下），availableProcessors()可能返回宿主机总核数而非实际配额 - Common Pool 是共享的，所有未指定池的
parallelStream()、CompletableFuture默认都用它 —— 某个慢任务长期占满 Common Pool，会导致其他模块的并行流也卡住
为什么加了 ForkJoinPool 反而变慢？几个典型坑
性能倒退往往不是框架问题，而是使用方式违背其设计假设：
- 任务粒度过细：比如对每个数组元素都创建一个
ForkJoinTask，任务调度开销远超计算收益；阈值THRESHOLD建议设为至少处理几百次基础运算（如循环累加 500+ 次） - 共享可变状态：多个
compute()并发修改同一个ArrayList或静态计数器，引发锁争用或数据错乱，FJP 不解决线程安全问题 - 混用阻塞操作：在
compute()中调用Thread.sleep()、Object.wait()或同步 IO，会让工作线程“假死”，破坏窃取机制 - 忘记异常传播：
compute()抛出异常时，join()才抛ExecutionException，若没 catch 就吞掉，调试时看不到真实错误栈
真正发挥 ForkJoinPool 效能的关键，在于让每个子任务足够“胖”（有实质计算）、足够“纯”（无共享副作用）、足够“短”（毫秒级完成），同时留给运行时足够空间去动态平衡负载。这些约束条件比代码怎么写更难满足。
