应优先使用ForkJoinPool处理天然可拆分、递归性强、子任务耗时差异大的分治型计算任务（如树遍历、归并排序），而非IO密集型或独立扁平任务；其默认并行度为CPU核心数减1，旨在预留资源避免调度争抢。
什么时候该用 ForkJoinPool 而不是 ThreadPoolExecutor
当你手头的任务天然可拆、递归性强、且子任务执行时间差异大（比如树遍历、归并排序、大规模数组并行处理），ForkJoinPool 才有明显优势。它不是“更快的线程池”，而是为「分治 + 突发性短任务」设计的专用结构。
常见误用场景：拿它跑一堆独立 HTTP 请求、数据库查询，或简单循环提交 Runnable——这时反而比 ThreadPoolExecutor 慢，因为 fork/join 开销（任务队列、窃取检查、异常传播）白搭。
- 适合：
RecursiveTask或RecursiveAction，任务能fork()出子任务，最后join()合并结果 - 不适合：IO 密集型、阻塞调用多、任务粒度粗（单个任务 > 100ms）、无依赖关系的扁平任务列表
- 注意：
ForkJoinPool.commonPool()是共享的，被所有未指定池的fork/join任务共用，压测时容易互相干扰
ForkJoinPool 默认并行度为什么不是 CPU 核心数
默认并行度 = Runtime.getRuntime().availableProcessors() - 1（JDK 8+），不是直接等于核心数。这是为了给主线程或其他非 ForkJoin 任务留一个空闲核，避免调度争抢——尤其在混合负载场景下更稳。
但如果你的应用是纯计算型、独占 JVM，且明确知道没有其他线程竞争，可以显式构造：
new ForkJoinPool(Runtime.getRuntime().availableProcessors())
不过别盲目调高：并行度 > 核心数只会增加上下文切换开销；
- 常见坑：
ForkJoinPool.commonPool()的并行度不可改，哪怕你调了System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "8")，也只在 JVM 启动前生效 - 动态调整需用自定义池 +
setParallelism(int)（仅对新建池有效，运行中调用无效） - Mac M1/M2 上
availableProcessors()返回的是逻辑核数（含性能核+能效核），实际计算吞吐未必线性增长
为什么 compute() 里调 fork() 后不 join() 就返回，结果却没错
因为 ForkJoinTask 的执行模型不是“先 fork 再等”，而是“触发 fork → 当前线程可能立即执行子任务（helping）→ join 时若子任务未完成才真正挂起”。这是工作窃取的核心机制：空闲线程会从其他队列“偷”任务，所以 join() 不一定导致阻塞。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
但这也带来隐式依赖：如果在 compute() 里漏掉 join()，就等于放弃等待子结果，返回值或副作用很可能错乱。
- 典型错误：写成
left.fork(); right.fork(); return left.compute() + right.compute();—— 这里两个compute()是同步执行，没利用并发，还可能重复计算 - 正确姿势：
left.fork(); return right.compute() + left.join();（让右子任务当前线程算，左子任务异步 fork，再 join 拿结果） - 注意：
invoke()是阻塞调用，fork()+join()是非阻塞发起+同步等待，别混用execute()（无返回）和invoke()（有返回）
工作窃取（Work-Stealing）在什么情况下会失效
窃取机制依赖每个线程维护双端队列（Deque）：本线程从头部 push/pop，其他线程只能从尾部 steal。一旦任务分布极度不均（比如根任务立刻 fork 出 1000 个子任务，全堆在同一个队列），或者子任务创建后立刻被 join（没机会被偷），窃取就无事可做。
更隐蔽的问题是：如果子任务本身又 fork 得太深、太细（比如每次只处理 1 个元素），任务调度开销会压倒计算收益。
- 建议阈值：当
end - start （数组场景）或node.getChildCount() （树场景）时，直接计算，不再 fork - 避免在
compute()中抛出未检查异常：它会被包装成ForkJoinTask.AbnormalCompletionException，上层invoke()捕获的是这个包装类，不是原始异常 - 调试时加
-Djava.util.concurrent.ForkJoinPool.common.threadFactory=...可定制线程名，否则日志里全是ForkJoinPool.commonPool-worker-N，没法定位哪块逻辑在跑
工作窃取不是银弹，它缓解的是“部分线程忙死、部分闲死”的问题，但解决不了任务本身设计不合理、数据局部性差、或者共享锁瓶颈这些底层问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
