Work-Stealing 是空闲线程主动窃取其他线程队列尾部任务的机制，非自动均衡；依赖任务拆分结构、执行时间差异与窃取时机，需避免阻塞、合理选用 RecursiveTask/RecursiveAction，并为计算密集型任务创建专用线程池。
Work-Stealing 不是自动均衡，而是「空闲线程主动找活干」
很多人误以为 ForkJoinPool 会“智能调度”让任务均匀分布，其实它不做任何预分配。只有当某个 ForkJoinWorkerThread 自己队列空了，才会去别的线程队列尾部（base 端）尝试窃取一个任务。这意味着：负载是否均衡，完全取决于任务拆分结构 + 执行时间差异 + 窃取时机。
常见错误现象包括：
- 主线程卡在
join()上很久，其他线程早已空闲——说明子任务执行时间严重不均，早完成的线程没任务可偷（因为别人队列还没 push 完） - 大量
Thread.currentThread().getName()显示都是ForkJoinPool.commonPool-worker-N，但 CPU 使用率却只有 40%——可能因阻塞操作（如 IO、锁等待）导致线程无法参与窃取
双端队列 LIFO/FIFO 分离是窃取不冲突的关键
每个工作线程的 Deque 是线程私有的，自己从头部（top）用 pop() 取任务（LIFO），别人从尾部（base）用 take() 窃取（FIFO）。这种设计避免了读写竞争，也不需要全局锁。
实操建议：
- 任务被
fork()时，总是压入当前线程队列头部；所以递归越深，新 fork 出的任务越“新鲜”，优先被本线程处理 - 被窃取的任务是队列里最老的（FIFO），也就是最早 fork 出来但还没执行的——这天然缓解了长尾延迟
- 不要手动修改
Deque或尝试共享队列，所有操作必须走fork()/join()接口
RecursiveTask 和 RecursiveAction 的选择直接影响窃取效率
用错类型不会报错，但会拖慢整体吞吐。核心区别在于：是否需要等结果合并。
使用场景判断：
- 要逐层合并中间结果（如数组求和、归并排序的
merge()、找最大值）→ 必须用RecursiveTask，否则join()返回 void，逻辑断裂 - 只做副作用（遍历打日志、批量写 DB、发通知）→ 用
RecursiveAction，省去返回值搬运开销，且无需调用join() - 混合场景（先计算再触发动作）→ 拆成两个任务链，避免在
compute()里混用阻塞操作
commonPool 不适合长任务，专用池才可控
ForkJoinPool.commonPool() 是 JVM 全局共享的，被 parallelStream()、CompletableFuture 等共用。一旦有慢任务占着线程不放，整个应用的并行流都会卡住。
实操建议：
- 计算密集型任务一律创建专用池：
new ForkJoinPool(parallelism)，parallelism建议设为Runtime.getRuntime().availableProcessors() - 禁用
ManagedBlocker或任何阻塞调用——Fork/Join 不是为 IO 设计的，阻塞会让窃取机制失效 - 调试时加一句
System.out.println("task@" + this + " on " + Thread.currentThread().getName())，确认是否真被窃取，而不是全在主线程里串行跑完
真正容易被忽略的是：Work-Stealing 能起作用的前提，是任务已经 fork 出去、且至少有两个线程处于「一忙一闲」状态。如果所有子任务都在同一个线程队列里堆积，或者任务粒度太粗只剩一个，窃取根本不会发生。
