ForkJoinPool工作窃取算法通过LIFO本地执行与FIFO远程窃取的双端队列策略，主动利用CPU缓存局部性：本地任务从尾部执行复用热点数据，窃取任务从头部取冷任务，既减少缓存未命中与伪共享，又降低跨核迁移开销。
任务窃取不是单纯为了“不让线程闲着”，而是围绕 CPU 缓存行为精心设计的——ForkJoinPool 通过 LIFO 本地执行 + FIFO 远程窃取的双端队列策略，主动维持和利用缓存热点，显著减少缓存未命中。
本地任务优先从队尾执行（LIFO），紧贴数据局部性
当一个线程 fork 出子任务时，该任务被压入自身 Deque 的尾部；线程随后也从尾部弹出任务执行。这种后进先出顺序，让刚分解出的子任务能立即复用父任务留在 CPU 缓存（尤其是 L1/L2）中的数据结构、中间变量或热点对象。
例如归并排序中，父任务刚完成对某段数组的分区操作，其指针、边界索引、临时缓冲区大概率还在缓存里；紧接着执行的子任务若处理同一段数据的左半部分，就能直接命中缓存，避免重新加载。
- 避免跨核心迁移数据：本地执行减少了任务在不同 CPU 核心间切换的需要
- 提升指令缓存效率：连续执行同源任务，分支预测和流水线更稳定
- 降低伪共享风险：线程只读写自己队列的尾部（top 指针），与窃取者访问头部（base 指针）物理隔离
窃取任务从队首拿（FIFO），避开缓存冷区，降低干扰
空闲线程去“偷”任务时，并不碰对方队尾——那里是刚生成、可能还热着的任务；而是从队首取最老的那个任务。这个任务往往已等待较久，其关联数据大概率已逐出缓存，变成“冷任务”。
这样设计既避免了窃取者抢走原线程即将使用的热点任务，又让被窃取的线程无需为缓存一致性做额外同步——因为双方操作的是队列中相距较远、缓存行不重叠的区域（top 和 base 分别指向不同 cache line）。
- 窃取动作本身开销小：只需一次原子读取队首元素，无锁竞争
- 被窃任务通常粒度更大：执行时间长，摊薄窃取带来的调度成本
- 天然规避 false sharing：top 和 base 指针更新落在不同缓存行
任务粒度与阈值设置，决定缓存优化能否落地
再精巧的局部性设计，也依赖合理拆分。如果 THRESHOLD 设得过大（比如 10 万元素才 fork），大部分计算都在单线程内串行完成，根本没机会触发窃取，缓存优势仅限于单线程内部；如果设得太小（如每次只处理 10 个元素），任务创建/调度开销反超缓存收益，还会频繁触发 GC 和上下文切换，冲刷缓存。
- 推荐阈值参考：CPU 缓存行大小（64 字节）× 数据访问密度，例如对 int 数组可设为 1024–8192 元素
- 黄金分割拆分（0.618 比例）比对半拆更易保持子任务数据访问范围重叠，进一步延长热点驻留时间
- 避免在 compute() 中混用阻塞 I/O 或锁：这类操作会清空当前线程的缓存热度，使后续任务失去局部性基础
它把缓存意识嵌进了任务调度逻辑里——不是等缓存失效后再补救，而是在任务诞生那一刻，就决定了它该在哪执行、何时执行、由谁执行。
