ForkJoinPool 适用于可递归拆分、无强依赖、计算密集型任务，如归并排序、分治求极值、树遍历、蒙特卡洛估算；禁用I/O操作，采用工作窃取调度，需慎用 commonPool。
适合用 ForkJoinPool 的任务类型
ForkJoinPool 不是万能线程池，它专为 ForkJoinTask 设计，核心适用场景是「可递归拆分、无强依赖、计算密集型」的任务。比如：大数组归并排序、分治法求最大值/最小值、树形结构遍历（如 JSON 解析树）、蒙特卡洛积分估算。这些任务能自然地 split 成子任务，且子任务之间基本不共享可变状态。
常见误用：拿它执行 HTTP 调用、数据库查询、文件读写——这些 I/O 密集型操作会让工作线程长时间阻塞，拖垮整个池的吞吐，还可能引发 ManagedBlocker 未正确使用导致的饥饿问题。
ForkJoinPool 和 ExecutorService 的关键区别
根本差异不在“并发”本身，而在**任务调度模型**：ExecutorService 是「中心化队列 + 线程轮询」，而 ForkJoinPool 采用「工作窃取（work-stealing）」：每个线程维护自己的双端队列（deque），先从队尾 pop 任务执行；空闲时去其他线程队首偷任务。这大幅降低竞争，也更适合分治任务的不均衡负载。
- 默认并行度 = CPU 核心数（
ForkJoinPool.commonPool()），不是按需扩容 - 不支持
submit(Runnable)返回Future的常规用法，必须用ForkJoinTask子类（RecursiveAction或RecursiveTask） - 没有
shutdownNow()的可靠中断语义，强行关闭可能导致子任务丢失
RecursiveTask vs RecursiveAction 怎么选
看任务是否需要返回结果：RecursiveTask 用于有返回值的分治（如 sum、max），必须重写 compute() 并调用 fork()/join()；RecursiveAction 用于纯副作用操作（如对数组某段做快速排序原地修改），compute() 返回 void。
立即学习“Java免费学习笔记（深入）”；
容易踩的坑：
- 忘记在
compute()中调用join()就直接 return，导致子任务没等完成就返回，结果错乱 - 拆分粒度太细（比如每次只拆 1 个元素），fork/join 开销反超计算收益
- 在
compute()中抛出未检查异常，会包装成ForkJoinTask.ExecutionException，堆栈信息可能被截断
commonPool() 的隐式风险
很多库（如 CompletableFuture 默认异步方法）悄悄用的是 ForkJoinPool.commonPool()，这意味着你的业务代码、JSON 库、日志框架可能共用同一个池。一旦某个任务因 bug 长时间阻塞或耗尽栈空间，会影响所有使用 commonPool 的模块。
建议：
- 明确知道任务特征且可控时，优先创建专用
ForkJoinPool实例，传入自定义并行度和UncaughtExceptionHandler - 避免在
commonPool()中执行任何可能阻塞的操作（包括synchronized块里等待锁） - JDK 19+ 引入了
ScopedValue，但commonPool()仍不支持上下文传播，ThreadLocal 也会失效
真正难处理的从来不是怎么写 fork/join，而是如何界定任务边界、预估拆分阈值、以及意识到 commonPool 不是“免费午餐”。
