当任务可递归分割、无外部依赖且CPU密集时才用ForkJoinTask；I/O、锁竞争或小任务场景应选ExecutorService+Runnable/Callable。
什么时候该用 ForkJoinTask 而不是普通 Thread 或 Runnable
当你手头有个计算密集型任务，且它天然能被递归拆成多个子任务（比如归并排序、遍历树结构、大规模数组求和），ForkJoinTask 才值得考虑。它不是为 I/O、网络请求或带锁同步设计的——这些场景用 ExecutorService 提交 Runnable 或 Callable 更合适。
关键判断点：任务是否可分割 + 是否无外部依赖 + 是否 CPU-bound。如果拆分后子任务之间要频繁通信、等锁、读文件或发 HTTP 请求，ForkJoinPool 的工作窃取机制反而会放大线程竞争和上下文切换开销。
-
ForkJoinTask默认使用ForkJoinPool.commonPool()，其并行度通常等于 CPU 核心数减一（JDK 8/9 行为），不适用于需要自定义线程数的场景 - 子任务执行中若抛出未捕获异常，会静默“吞掉”异常，需显式调用
get()或join()才触发ExecutionException - 小任务（例如只处理几十个元素）强行 fork/join，开销可能超过收益；建议设置阈值（如
if (end - start ）直接计算
RecursiveAction 和 RecursiveTask 怎么选
看任务要不要返回结果：RecursiveAction 无返回值，适合“做了就完事”的场景（如对数组每个元素做某种变换）；RecursiveTask 必须重写 compute() 并返回类型 T，适合需要聚合结果的场景（如求和、找最大值）。
二者都要求在 compute() 中自行决定是否 fork() 子任务、何时 join() 等待结果。没有自动并行逻辑——fork 不等于立即执行，只是把子任务提交到当前线程的工作队列或供其他线程窃取。
立即学习“Java免费学习笔记（深入）”；
- 误用
RecursiveAction去做需要汇总的操作，会导致结果丢失（没地方存、也没法等） -
RecursiveTask的join()是阻塞调用，若子任务尚未完成，当前线程会先尝试窃取别的任务，再循环检查；但若所有任务都在忙，仍会挂起 - 不要在
compute()外部调用fork()后又手动execute()——这绕过了ForkJoinPool的工作窃取调度，失去优势
常见错误：fork() 后忘了 join() 或 invoke()
只调用 fork() 不等于执行完毕。子任务被异步提交，主线程继续往下跑，如果此时就去读结果或假设已完成，大概率拿到旧值或 null。
PHP网络编程技术详解由浅入深，全面、系统地介绍了PHP开发技术，并提供了大量实例，供读者实战演练。另外，笔者专门为本书录制了相应的配套教学视频，以帮助读者更好地学习本书内容。这些视频和书中的实例源代码一起收录于配书光盘中。本书共分4篇。第1篇是PHP准备篇，介绍了PHP的优势、开发环境及安装；第2篇是PHP基础篇，介绍了PHP中的常量与变量、运算符与表达式、流程控制以及函数；第3篇是进阶篇，介绍
正确做法分两类：
- 需要结果：用
task.fork(); result = task.join();或更简洁的pool.invoke(task)（同步等待并返回结果） - 不需要结果：用
task.invoke()或直接pool.execute(task)，但注意后者不保证执行顺序，也不返回任何状态 - 混合模式常见坑：
left.fork(); right.compute(); left.join();——这是合理优化（让右子任务在当前线程算，左子任务异步 fork），但如果写成left.fork(); right.fork(); left.join(); right.join();，就失去了流水线效果，变成串行等待
性能陷阱：过度分解与共享变量竞争
ForkJoinPool 的高效依赖于任务轻量、无锁、数据局部性好。一旦任务粒度太细（比如每次只处理一个 int），fork/join 的调度开销会压倒计算收益；一旦多个子任务写同一块堆内存（如共用一个 ArrayList），就会触发 CAS 重试或锁升级，吞掉所有并发优势。
实操建议：
- 用
System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "4")调整公共池并行度（仅调试用，生产应建专用池） - 避免在
compute()中访问静态变量、System.out、数据库连接等全局资源 - 优先用不可变数据或线程本地中间结果（如每个子任务返回自己的部分和，最后由父任务累加）
public class ArraySumTask extends RecursiveTask{ private final int[] array; private final int lo, hi; private static final int THRESHOLD = 1000; ArraySumTask(int[] array, int lo, int hi) { this.array = array; this.lo = lo; this.hi = hi; } @Override protected Long compute() { if (hi - lo zuojiankuohaophpcn= THRESHOLD) { long sum = 0; for (int i = lo; i zuojiankuohaophpcn hi; i++) sum += array[i]; return sum; } int mid = (lo + hi) / 2; ArraySumTask left = new ArraySumTask(array, lo, mid); ArraySumTask right = new ArraySumTask(array, mid, hi); left.fork(); // 异步启动左半部分 long rightResult = right.compute(); // 当前线程算右半部分 long leftResult = left.join(); // 等左半部分结果 return leftResult + rightResult; }}
真正难的不是写对 fork/join，而是判断哪里该停住分解、哪些数据必须隔离、以及怎么验证并行确实带来了收益——这些没法靠框架自动解决。
