当任务可递归拆分、无强依赖且CPU密集时应使用ForkJoinPool；它适合归并排序等场景，依赖工作窃取机制，但不适用于IO阻塞或小粒度任务。
什么时候该用 ForkJoinPool 而不是普通线程池
当你有一堆可以自然递归拆分、且子任务间无强依赖的任务时，ForkJoinPool 才有优势。比如归并排序、树形结构遍历、大规模数组求和。它底层用工作窃取（work-stealing）机制提升 CPU 利用率，但调度开销比 ThreadPoolExecutor 高。如果任务粒度太小（比如每次只处理 10 个元素），或者任务本身阻塞（如 IO），反而会拖慢整体性能。
- 适合：CPU 密集型、可分割、结果可合并的计算任务
- 不适合：
Runnable类型的纯执行任务（没返回值）、含Thread.sleep()或文件读写、任务数远少于 CPU 核心数 - 注意：
ForkJoinPool.commonPool()是共享的，被所有未指定池的ForkJoinTask共用，高并发下容易成瓶颈
RecursiveTask 和 RecursiveAction 怎么选
看你的任务是否需要返回结果。要返回值就继承 RecursiveTask<t></t>，重写 compute() 并返回 T；不需要返回就用 RecursiveAction，重写 compute() 但不返回任何东西。别混用——比如在 RecursiveAction 里强行 return 一个值，编译不过。
-
RecursiveTask<integer></integer>：适合求和、找最大值等场景，子任务调用invokeAll()后，用left.join() + right.join()合并 -
RecursiveAction：适合批量更新数组、打日志等副作用操作，合并逻辑在compute()内部完成，无需join() - 常见错误：
invokeAll(left, right)后直接用left.get()——这是阻塞式获取，破坏了异步模型，应统一用left.join()
如何控制任务拆分粒度避免栈溢出或性能下降
拆得太细，任务调度开销压倒计算收益；拆得太粗，又起不到并行效果。关键在 compute() 开头的阈值判断。这个阈值不是固定值，得结合数据规模和单次计算耗时测出来。例如对一亿个 int 求和，阈值设为 10_000 往往比 100 或 1_000_000 更稳。
- 典型写法：
if (end - start - 别用递归深度做条件（如
depth > MAX_DEPTH），因为深度难预估，且容易触发StackOverflowError（虽然ForkJoinTask不走 JVM 栈，但误判仍会导致无限 fork） - 测试建议：用
-XX:+PrintGCDetails观察 GC 频率，任务太碎会引发大量短生命周期对象分配
为什么 fork() 后必须配 join()，不能只 fork()
fork() 只是把任务提交进当前线程的工作队列，不保证执行；join() 才真正等待结果，并在必要时帮其他线程“偷”任务来执行，实现负载均衡。漏掉 join()，主线程可能提前返回默认值（如 RecursiveTask 的 0），或者得到未计算完的结果。
立即学习“Java免费学习笔记（深入）”；
- 正确模式：
left.fork(); int rightResult = right.compute(); int leftResult = left.join();（先 fork 一个，再同步算另一个，最后 join 第一个） - 错误模式：
left.fork(); right.fork();然后直接return 0;—— 子任务可能根本没执行就被丢弃 - 注意：
invokeAll(tasks...)内部已封装了 fork + join，不用额外调用，但别在它外面再套一层fork()
最常被忽略的是任务取消和异常传播——ForkJoinTask.cancel(true) 不会中断正在运行的子任务，而 compute() 抛出的异常会被包装成 ExecutionException，需在 join() 后显式处理。这和普通线程池的行为差异很大，上线前务必用带异常分支的 case 跑一遍。
