work-stealing 由空闲线程主动从其他线程队列头部窃取任务触发，依赖 fork() 入队、join() 协助执行；任务粒度宜为100–10000纳秒，避免i/o与阻塞，需正确使用 fork()/join() 而非 compute() 或 invoke()。
Work-Stealing 是怎么被触发的
不是靠中心调度器分配任务，而是每个线程维护自己的双端队列（Deque），新任务 fork() 时压入自己队列尾部；当线程空闲（自己队列为空），就随机选一个其他线程，从它的队列**头部**偷一个任务——这是关键：尾进头出 + 偷头部，既减少竞争，又保证偷到的是“较老、可能更重”的任务。
常见错误现象：ForkJoinPool 跑不满 CPU，或某些线程长期空转。往往是因为任务粒度太粗（没触发窃取）或太细（偷任务开销反超收益）。
- 任务拆分建议落在 100–10000 纳秒级计算量，用
System.nanoTime()粗略估一下 - 避免在
compute()里做 I/O、锁、阻塞调用，否则窃取线程会卡住，整个池吞吐暴跌 -
ForkJoinPool.commonPool()默认并行度 =CPU核心数 - 1（非 Web 应用场景下），别盲目调大
为什么必须用 fork() + join() 而不是直接 invoke()
invoke() 是同步执行，不进队列，不参与窃取；只有 fork() 才把任务推入当前线程的 Deque 尾部，后续才可能被别人偷走。而 join() 不只是等待，它会先检查任务是否完成，没完成则尝试帮着执行（helping）——这步才是窃取机制真正起效的入口。
使用场景：递归分治（如归并排序、并行流遍历树）必须显式 fork() 子任务，否则所有子任务都在同一线程串行跑完，完全没用上 Work-Stealing。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
left.compute(); right.compute();→ 没 fork，无窃取 - 正确写法：
left.fork(); return right.compute() + left.join(); -
compute()返回前别漏掉join()，否则结果丢失或 NPE
ForkJoinPool 的默认构造参数怎么影响窃取行为
最常被忽略的是 asyncMode 参数。默认 false（LIFO 模式），队列按栈语义操作（尾进尾出），适合深度优先递归；设为 true 则变成 FIFO，任务按提交顺序执行，更适合广度优先或实时性要求高的场景——但此时窃取仍从头部取，FIFO 下偷到的是“最早提交的任务”，可能更符合预期。
性能影响明显：LIFO 模式下局部性更好（刚 fork 的任务数据还在 CPU 缓存里），FIFO 模式下任务更均衡但缓存命中率下降。
- 普通分治计算用默认
false即可 - 如果观察到任务执行时间方差极大（有的几毫秒、有的几百毫秒），可试
new ForkJoinPool(parallelism, factory, handler, true) -
parallelism设太高（比如 > CPU 核心数）反而引发上下文切换抖动，尤其在容器环境里
常见误判：任务没被窃取，真的是机制失效了吗
不是。绝大多数“没看到窃取”是因任务太短、线程数少、或用了 commonPool() 被其他模块抢占。可以用 ForkJoinPool.getStealCount() 查看累计窃取次数，或开启 JVM 参数 -XX:+UnlockDiagnosticVMOptions -XX:+PrintGCDetails（配合 JFR 更准）验证。
容易踩的坑：
- 在
main线程直接pool.invoke(task)，而没用submit()或execute()，导致任务由主线程执行，不进工作线程队列 - 自定义
ForkJoinWorkerThread工厂时忘了调用setDaemon(true)，导致 JVM 不退出 - 用
CompletableFuture的supplyAsync(..., pool)时，传入的是ForkJoinPool实例，但任务内部没调fork()，仍是普通线程池语义
Work-Stealing 不是自动魔法，它只在你严格遵循 fork/join 模式、且任务粒度合理时才真正转动起来。别的都好调，粒度不对，再好的机制也白搭。
