Work Stealing 在 ForkJoinPool 中通过双端队列实现：线程本地 LIFO 操作（队尾），偷任务时 FIFO 从他人队列队首取，避免伪共享；仅适用于无状态、CPU 密集型可拆分任务，粒度建议 >100μs。
Work Stealing 在 ForkJoinPool 里怎么实际起作用
ForkJoinPool 默认用双端队列（Deque）给每个线程配一个任务栈，不是共享队列。线程自己干活时从**队尾 push/pop**（LIFO），避免伪共享；偷任务时去别人队列的**队首 take**（FIFO），降低冲突概率。
这不是理论设计——它直接决定你写 ForkJoinTask 时要不要重写 compute() 的拆分逻辑：如果子任务之间有强依赖或状态耦合，偷走一个中间任务可能让执行结果错乱。
- 只在 CPU 密集型、可递归拆分的任务里有效（比如归并排序、遍历树结构），IO 或阻塞操作会卡住整个线程队列
-
ForkJoinPool.commonPool()的并行度默认是Runtime.getRuntime().availableProcessors() - 1，不是核数，别硬凑满核 - 任务太小（比如每次
compute()只做几次加法）反而增加调度开销，建议单个子任务耗时 > 100μs 再考虑 fork
为什么偷任务总从别人队列头拿，而不是尾部
尾部是原线程正在活跃操作的位置，缓存行（cache line）大概率被它独占。如果偷也从尾拿，两个线程反复争同一 cache line，触发总线嗅探和失效，性能暴跌——这就是伪共享（false sharing）。
队首是“冷区”，原线程几乎不碰，偷线程读取它不会干扰原线程的高速缓存局部性。JDK 实现里这个队首操作是通过 poll() 或 pollFirst() 完成的，底层用的是 sun.misc.Unsafe 的原子操作，不是 synchronized。
- 双端队列不是
ArrayDeque，而是 ForkJoinPool 自研的WorkQueue，支持无锁出队（head 指针 CAS） - 偷失败（对方队列空或正被修改）就立即放弃，转去扫描下一个空闲线程，不自旋等待
- 偷的成功率低？说明任务粒度太粗或线程数远超可用核心数，得调
parallelism参数
ForkJoinPool 提交任务后，线程到底什么时候开始偷
没有固定时机。一个线程执行完自己队列所有任务后，会进入“helpJoin”循环：先检查有没有正在 join 的任务要协助（比如等子任务返回），没有就启动“scan”阶段——随机选几个其他线程的队列，尝试从队首偷一个任务。
注意：invoke() 和 submit() 行为不同：invoke() 是同步阻塞直到结果返回，期间当前线程可能帮着偷；submit() 只是把任务扔进全局队列或随机 worker 队列，提交者线程立刻返回，不参与后续调度。
- 偷不是轮询所有线程，而是用一个简单的哈希位移算法跳着找（避免热点竞争），最多试 64 次就放弃
- 如果所有队列都空了，线程会进入 park 状态，直到新任务提交或被唤醒，不会空转耗电
- 别在
compute()里调Thread.sleep()或Object.wait()，这会让整个 worker 线程挂起，影响偷任务调度节奏
常见报错 RejectionException 和工作窃取有关系吗
没关系。RejectedExecutionException 出现在 ForkJoinPool 已 shutdown 或队列满（比如设置了有限容量且任务爆炸式提交）时，和偷不偷任务无关。真正和工作窃取相关的异常是 RuntimeException 在偷来的任务里抛出——它会顺着原始 join() 调用栈向上冒泡，但堆栈里可能看不到偷线程的痕迹，容易误判为“莫名崩溃”。
- 调试时开启
-Djava.util.concurrent.ForkJoinPool.common.parallelism=2降低并发度，更容易复现偷任务路径 - 不要在
compute()里捕获Throwable后静默吞掉，否则偷线程出错等于任务消失 - 自定义
ForkJoinPool时传入的UncaughtExceptionHandler只对 worker 线程顶层异常生效，偷来的任务异常仍走join()的异常传播机制
事情说清了就结束。双端队列的设计细节藏在 ForkJoinPool.WorkQueue 的注释里，但真正影响行为的，是你拆分任务的边界是否清晰、有没有隐式共享状态、以及是否误把阻塞操作塞进了 compute 流程。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
