Fork/Join框架核心是“递归任务+局部队列”，依赖工作窃取机制：线程优先从自身双端队列头取任务（LIFO），窃取时从他人队列尾取（FIFO）；拆分粒度需适配并行度，避免过细导致栈溢出或调度开销过大；禁用阻塞操作，慎用共享状态；RecursiveTask用于需合并结果的场景，RecursiveAction适用于无返回副作用操作；commonPool不可用于长时或IO任务，应创建专用池并合理配置。
Fork/Join框架的核心不是“多线程”，是“递归任务+局部队列”
它不解决“怎么开10个线程”，而是解决“一个大任务怎么安全、高效地切碎，再让空闲线程捡着干”。关键在两件事：ForkJoinPool 的工作线程自带双端队列（deque），以及每个线程优先从自己队列头取任务（LIFO），偷任务时才从别人队列尾拿（FIFO）——这直接决定性能是否被拖垮。
常见错误现象：StackOverflowError 频发，或 CPU 利用率忽高忽低；本质是任务拆分粒度太细（比如每次只处理 1 个数组元素），导致 fork 层级过深、调度开销压倒计算收益。
- 拆分阈值别硬写
10或100，用ForkJoinPool.getCommonPoolParallelism()估算当前可用并行度，反推合理粒度（例如：总数据量 ÷ 并行度 × 2～5） - 避免在
compute()里调用阻塞操作（如Thread.sleep()、Object.wait()、数据库查询）——ForkJoinPool默认线程不可替换，阻塞会卡死整个池 - 子任务不要共享可变状态；若必须共享，用
ThreadLocal或AtomicInteger，别碰普通字段
RecursiveTask 和 RecursiveAction 的选型差异很实际
前者返回值，后者不返回；但真正影响决策的不是“要不要结果”，而是“结果聚合方式”。如果中间结果要逐层合并（比如归并排序的 merge、求和、找最大值），用 RecursiveTask；如果只是遍历打点、写文件、发通知这类副作用操作，用 RecursiveAction 更轻量。
容易踩的坑：RecursiveTask 的 join() 是阻塞调用，且会触发任务完成检查与异常传播；若子任务抛出 RuntimeException，父任务 join() 时会原样重抛——不是包装成 ExecutionException。
-
compute()中调用fork()后，必须跟join()或invoke()，否则子任务可能没执行就被丢弃 - 不要在
join()后再做耗时逻辑；它本身已含同步等待，外层再加锁或 IO 会放大延迟 - 调试时可在
compute()开头加System.out.println("task@" + this + " on " + Thread.currentThread().getName())，看是否真被窃取
工作窃取（Work-Stealing）不是“自动负载均衡”，它依赖任务结构
它只在任务已 fork 出去、且其他线程本地队列为空时才触发。如果所有任务都集中在某几个线程的队列里（比如拆分不均、或用了 invokeAll() 一次性提交），窃取根本不会发生。
典型场景：你用 RecursiveTask 实现快排，但每次只按固定位置（如中位数）切分，遇到已排序数组就会退化成链状调用——所有子任务都在一个线程队列里堆着，别的线程干瞪眼。
- 拆分策略尽量随机或基于数据特征（如用
Arrays.parallelSort()内部的 dual-pivot + 随机 pivot 偏移） - 避免深度优先式连续
fork()；可先fork()左子树，再compute()右子树（即“fork-right, compute-left”），减少栈深度和队列堆积 -
ForkJoinPool的默认并行度是Runtime.getRuntime().availableProcessors() - 1，非 CPU 密集型任务需显式构造带自定义并行度的池
别直接用 ForkJoinPool.commonPool() 处理长时任务
公共池被 CompletableFuture、Arrays.parallelXxx() 等大量共用，一旦有慢任务占着线程不放，整个 JVM 的并行能力就塌一块。这不是理论风险，是线上真实发生的线程饥饿。
错误现象：commonPool 中某个任务执行超 5 秒，随后 CompletableFuture.supplyAsync(() -> ...) 开始排队、响应毛刺飙升；jstack 显示大量线程 BLOCKED 在 ForkJoinPool.awaitJoin()。
- IO 密集、网络调用、数据库访问类任务，必须创建专用
ForkJoinPool，并设置合理maxPoolSize和asyncMode = true（启用 FIFO 模式，更适合非计算型任务） - 用完记得调用
shutdown()+awaitTermination()，尤其在短生命周期应用（如 CLI 工具、单元测试）中，否则 JVM 不退出 - 监控建议：通过
pool.getQueuedTaskCount()和pool.getActiveThreadCount()定期采样，比看 CPU 更早发现堆积
最常被忽略的一点：任务对象本身不能持有大对象引用。因为 ForkJoinPool 会复用任务实例（尤其在 adapt() 场景下），残留字段可能污染后续执行。每次 compute() 开始前，该清的变量得清。事情说清了就结束
