如何利用 ForkJoinPool 的工作窃取（Work-Stealing）算法提升 CPU 密集型任务的并行计算效率

工作窃取并不会让单个任务跑得更快，它的真正价值在于——不让任何一颗CPU核心闲着。理解这一点很重要：它提升的是整体吞吐量，而不是缩短单次执行时间。当然，这一切的前提是任务可以拆分、没有阻塞操作、并且粒度设置得刚刚好。

理解双端队列分工：LIFO 执行 + FIFO 窃取

每个工作线程都维护着自己的双端队列（Deque），分工逻辑很清晰：

• 自己干活时，从队列头部（top）取任务，采用 LIFO 方式——谁最后 fork 出来就先执行谁，局部性好，缓存命中率高
• 其他线程来“偷”任务时，从队列尾部（base）取，采用 FIFO 方式——拿走最早入队的、等待最久的任务，这样整体延迟更低
• 头尾操作由不同的线程主导，天然避免了 CAS 竞争和伪共享问题，吞吐量自然更高

合理设置任务拆分阈值（THRESHOLD）

阈值决定了一个任务是否要继续 fork。这个参数如果设得不准，工作窃取就形同虚设：

• 阈值太大：绝大多数子任务直接顺序执行，根本没有机会 fork，别人想来偷都没活可干
• 阈值太小：fork/join 的调度开销——对象创建、队列插入、上下文切换——反而超过了计算本身的收益
• 纯算术类任务（比如数组累加）可以放到 10 万以上；如果涉及随机内存访问或频繁分支预测失败，建议控制在 1 万以内
• 一个实用的验证方式：观察 ForkJoinPool.commonPool().getStealCount()，理想情况下窃取次数应占总任务数的 5%–30%

善用默认公共池，慎建自定义池

绝大多数 CPU 密集型场景，直接用 ForkJoinPool.commonPool() 就够了：

• 默认并行度 = Runtime.getRuntime().a vailableProcessors()，正好匹配理论上的最优核数
• 它已经针对计算密集型任务做了平衡，通常设为核数减 1，留一个给主线程或调度器，减少毛刺
• 只有当你有多个独立的大任务流、需要资源隔离时——比如 A 流占满池子导致 B 流饿死——才考虑 new ForkJoinPool(parallelism)

避开常见陷阱

下面这几个细节如果没处理好，工作窃取很可能从优化变成负优化：

• 任务里带了 IO 或锁操作（比如数据库查询、synchronized 块）——这种情况应该用 ThreadPoolExecutor，ForkJoin 不适合
• 用了 RecursiveAction，却在 compute() 里忘了调用 fork() 和 join()，结果还是单线程在跑
• 子任务平均耗时低于 10μs——窃取动作本身的开销可能比执行还高
• 所有子任务耗时高度一致（比如固定 size 拆分 + 均匀计算），导致几乎不发生窃取，退化为普通并行，白白承担 fork/join 的开销