ForkJoinPool 默认用 LIFO 是因递归分治任务具有缓存局部性：最新 fork 的子任务复用刚计算的中间结果、栈帧和缓存行；FIFO 会导致缓存失效、栈跳跃和 NUMA 跨节点访问，降低吞吐。
为什么 ForkJoinPool 默认用 LIFO 而不是 FIFO？
ForkJoinPool 中每个线程的 deque 默认按 LIFO（后进先出）消费自身任务，是因为它能天然适配递归分治任务的局部性引用特征：最新拆分出的子任务往往复用刚计算完的中间结果、缓存行或栈帧。若用 FIFO，线程会先处理最早入队的老任务，导致 CPU 缓存失效、栈跳跃、甚至跨 NUMA 节点访问，拖慢整体吞吐。
在 RecursiveTask.compute() 中显式控制 fork() 顺序
递归任务的拆分顺序直接影响 LIFO 效果是否被真正利用。比如归并排序中，若先 fork() 左半边、再 fork() 右半边，则右半边任务会压在 deque 尾部，被当前线程优先取出执行——而它依赖的父数组切片和临时缓冲区大概率还在 L1/L2 缓存中。
- ✅ 正确做法：把“最可能复用当前上下文”的子任务放在
fork()调用链最后 - ❌ 错误写法：
left.fork(); right.fork(); return left.join() + right.join();→ left 先入队、后执行，缓存早已被挤出 - ✅ 推荐写法：
right.fork(); left.compute(); return right.join() + resultOfLeft;（左子任务直接 compute，右子任务 fork 并等待）
避免 threshold 过小导致 LIFO 优势被稀释
当 threshold 设得太低（如 1 或 2），任务拆分过细，deque 中堆积大量微小任务，LIFO 局部性被高频上下文切换覆盖；但设得太大（如 > array.length / 4），又失去并行度。实测表明，对数组类分治，threshold ≈ 1024 ~ 8192 是较优区间，既保留足够粒度触发窃取，又让每个 compute() 的局部数据保留在缓存中。
- 实际调试时可加 JVM 参数：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps观察 GC 频率变化，cache miss 突增常伴随 minor GC 上升 - 不要盲目套用“CPU 核心数”作为 threshold，那是线程数配置逻辑，和缓存局部性无关
警惕 join() 阻塞破坏 LIFO 流水线
join() 是同步阻塞调用，若在 compute() 中连续 left.join(); right.join();，当前线程会卡在第一个 join()，无法继续消费自己 deque 尾部的新任务，等于主动放弃 LIFO 流水线。更糟的是，其他线程可能因此窃走本该由你本地高效处理的任务。
- ✅ 推荐模式：先
fork()所有可并行子任务，再统一join()，保持 deque 消费节奏 - ✅ 进阶技巧：对非对称子任务（如左子树深、右子树浅），用
invoke()替代fork()+join()处理深分支，避免阻塞 - ⚠️ 注意：
invoke()是同步且不入队的，只适合确定不会触发进一步 fork 的叶子任务
compute() 后，不妨用 perf record -e cache-misses,instructions 实测下 miss rate 变化。 
