ForkJoinPool 适合可递归分解的 CPU 密集型任务，如归并排序、树遍历、分治计算和并行聚合；不适合阻塞 I/O、强顺序依赖、频繁共享写入或超短耗时任务。
什么样的任务适合用 ForkJoinPool
ForkJoinPool 不是通用线程池，它专为「可递归分解的 CPU 密集型任务」设计。如果你的任务能自然切分成子任务，且子任务之间无强依赖、无需频繁同步或 I/O 等待，才值得考虑。
典型场景包括：归并排序、快速排序、树形结构遍历（如 JSON 解析树）、分治型数值计算（如矩阵乘法分块、蒙特卡洛积分）、大规模数组/集合的聚合操作（parallelStream() 底层就用它）。
- ✅ 适合：任务粒度适中（太小会增加调度开销，太大无法充分利用多核），总计算量明显大于同步/通信成本
- ❌ 不适合：含阻塞 I/O（如文件读写、HTTP 调用）、需严格顺序执行、共享状态频繁写入（未加锁易出错）、单次任务耗时极短（
- ⚠️ 注意：
ForkJoinPool.commonPool()是 JVM 共享的，被parallelStream()、CompletableFuture等共用，若某任务长期占用或抛出未捕获异常，可能拖慢其他模块
ForkJoinTask 的两种子类怎么选
你得在 RecursiveAction（无返回值）和 RecursiveTask（有返回值）之间做选择，本质取决于「子任务结果是否需要向上合并」。
- 用
RecursiveTask：比如求一个大数组的 sum，每个子任务算一段，最后left.join() + right.join() - 用
RecursiveAction：比如对数组每个元素做相同变换（如平方），不汇总结果，只关心副作用完成 - 别手动调
fork()/join()顺序：先fork()子任务，再处理当前逻辑，最后join()—— 否则失去并行意义；常见错误是fork().join()连写，等于同步执行 -
compute()方法里避免抛出受检异常：它不声明throws Exception，必须用运行时异常包装，否则编译不过
为什么 commonPool() 的并行度经常不是你预期的
ForkJoinPool.commonPool() 默认并行度 = Runtime.getRuntime().availableProcessors() - 1（至少为 1），不是 CPU 核数，也不是你传的参数。
立即学习“Java免费学习笔记（深入）”；
- 这个值在 JVM 启动时固定，后续调
ForkJoinPool#setParallelism()对commonPool()无效 - 想自定义并行度？必须显式构造新池：
new ForkJoinPool(4)，并用pool.invoke(task)启动 - 并行度过高（比如设成 100）反而降低性能：任务队列竞争加剧、上下文切换增多，尤其在任务本身轻量时
- 注意 JVM 参数：
-Djava.util.concurrent.ForkJoinPool.common.parallelism=8可在启动时覆盖默认值，但仅对commonPool()生效
容易被忽略的陷阱：取消、异常与内存可见性
ForkJoinPool 的取消机制弱于 ThreadPoolExecutor，异常传播也更隐蔽。
-
cancel(true)不保证中断正在运行的子任务：它只设置内部标志位，任务需主动检查isCancelled()并退出；没有自动中断线程的语义 - 子任务中抛出异常，父任务
join()时会收到ExecutionException，但原始异常被包了两层（ExecutionException→ForkJoinTask$RuntimeException→ 你的异常），调试时容易漏看根本原因 - 子任务间共享变量要小心：
ForkJoinPool使用工作窃取（work-stealing），不同线程可能执行同一批任务，volatile或Atomic*不能少；别假设“我在同一个线程里跑完所有子任务” - 任务对象最好不可变：避免多个线程同时修改
this字段导致状态混乱
实际用的时候，先问自己：这任务能不能干净地切？切完各干各的，几乎不碰同一块内存？如果答案模糊，不如老实用 ExecutorService 配合 CountDownLatch 或 CompletableFuture.allOf()。分治不是银弹，强行套用只会让代码更难 debug。
