工作窃取是从设计源头消除死等的调度范式，通过任务可分解、耗时不均、无阻塞等条件，结合forkjoinpool双端队列实现零中心化高效负载均衡。
工作窃取不是用来“替代死等”的补丁，而是从设计源头就消除死等的调度范式。它不靠增加线程数或轮询等待来压榨CPU，而是让空闲计算单元自动承接长尾任务，把物理核的利用率从“波动闲置”推向“持续饱和”。关键不在“怎么加”，而在“怎么分、怎么流、怎么控”。
任务必须可分解且耗时不均
硬编码死等往往出现在任务不可拆、依赖强同步或IO阻塞的场景。工作窃取只对满足以下条件的任务有效：
- 能递归或并行切分为多个独立子任务（如数组分段处理、树遍历、矩阵分块）
- 各子任务实际执行时间差异明显（例如部分数据需查缓存、部分触发GC、部分含分支预测失败）
- 无显式阻塞操作：不能有 Thread.sleep()、Object.wait()、synchronized 块、数据库连接等待或文件读写
用 ForkJoinPool 的双端队列机制实现零中心调度
分布式计算层不必自研窃取逻辑——JDK 的 ForkJoinPool.commonPool() 已内置成熟实现。它的吞吐优势来自底层分工：
- 每个线程从自己队列头部（top）LIFO取任务：最新 fork 的子任务优先执行，保持栈局部性，缓存友好
- 空闲线程从他人队列尾部（base）FIFO窃取：拿走最早入队、等待最久的任务，降低整体延迟
- 头尾操作天然隔离，避免 CAS 竞争和伪共享，单核吞吐更高
阈值（THRESHOLD）是调优核心杠杆
阈值决定“何时停止 fork、转为串行执行”。设错会导致两种失效：
- 阈值过大（如 >100 万）：多数子任务未被 fork，直接本地算完，窃取无任务可偷，退化为单线程分片
- 阈值过小（如
- 推荐起点：总数据量 ÷（CPU 核数 × 2），再按计算特征调整——纯算术累加可设 10 万+；含随机内存访问或深度分支的，建议 1 万以内
- 实测验证：监控 ForkJoinPool.commonPool().getStealCount()，理想窃取次数应占总任务数的 5%–30%
默认池足够，慎建自定义池
绝大多数分布式计算场景，直接用 commonPool() 即可：
- 默认并行度 = Runtime.getRuntime().availableProcessors() − 1，预留一核给主线程或调度器，减少毛刺
- 已针对 CPU 密集型任务做平衡，无需手动调参
- 仅当存在多个独立大任务流（如实时流 A 和离线批 B），且需资源隔离防饿死时，才考虑 new ForkJoinPool(parallelism)
不复杂但容易忽略：工作窃取不是靠“更多线程”压榨硬件，而是靠“更少空转”逼近物理吞吐红线。它生效的前提，是任务模型本身支持动态负载流动——一旦任务粒度、阻塞点、拆分逻辑没对齐，再多的窃取也救不了设计缺陷。
