ForkJoinPool 任务执行呈深度优先因本地队列使用 LIFO：fork() 入队尾部，执行时从头部取，使最新子任务优先执行；窃取任务从其他队列尾部取，偷的是较早生成的大粒度任务，不干扰当前线程的递归路径。
为什么 ForkJoinPool 的任务执行看起来像深度优先
因为 ForkJoinPool 默认对本地队列采用 LIFO（后进先出）调度：线程调用 fork() 产生的子任务被压入自己队列尾部，而执行时却从队列头部取任务——这导致最后 fork 出的子任务最先被执行，形成「递归拆分 → 立即处理最新子任务」的行为模式，视觉上就是深度优先。
Work-Stealing 的 FIFO 窃取如何不破坏深度优先倾向
窃取只发生在空闲线程主动找活干时，且是从其他线程队列的尾部（top 端）取任务。但注意：这个“尾部”是相对该线程自身 LIFO 入队顺序而言的——它偷的是别人「最早 fork 出但还没来得及执行」的老任务，而非最新任务。所以：
- 主线程或工作线程自己的执行流仍严格遵循 LIFO，维持局部深度优先
- 被窃取的任务往往是较早生成、粒度较大、尚未下沉的中间节点，不会干扰当前线程的递归栈路径
- 窃取动作本身不改变任务的父子依赖关系，
join()仍等待所有已fork()的子任务完成，保证语义正确
如何验证你看到的确实是 LIFO 本地执行 + FIFO 窃取混合效果
最直接的方式是加日志并控制任务粒度，观察执行顺序。例如在 compute() 开头打印线程名和任务标识，在小规模数据（如数组长度 ≤ 16）下禁用窃取（用单线程池），再对比多线程下的日志序列：
class SumTask extends RecursiveTask<Long> {
final long[] arr; final int lo, hi;
SumTask(long[] arr, int lo, int hi) { this.arr = arr; this.lo = lo; this.hi = hi; }
protected Long compute() {
System.out.printf("[%s] enter [%d,%d]%n", Thread.currentThread().getName(), lo, hi);
if (hi - lo <= 4) {
long sum = 0;
for (int i = lo; i < hi; i++) sum += arr[i];
return sum;
}
int mid = (lo + hi) / 2;
SumTask left = new SumTask(arr, lo, mid);
SumTask right = new SumTask(arr, mid, hi);
left.fork(); // 先 fork left
long r = right.compute(); // 立即 compute right → 体现 LIFO 偏好
long l = left.join();
return l + r;
}
}你会看到类似 [FJ-pool-1-worker-1] enter [0,8] → [FJ-pool-1-worker-1] enter [4,8] → [FJ-pool-1-worker-1] enter [6,8] 的嵌套输出，而非先展开所有左支。
容易被忽略的关键约束：深度优先不等于栈深度可控
递归调用 compute() 本身仍在当前线程栈上，如果拆分阈值设得太小（比如 hi-lo < 1），或者任务结构天然极深（如平衡树高度达万级），仍可能触发 StackOverflowError。ForkJoinPool 不会自动将深层递归转为循环或协程——它只是让「谁来执行哪段递归」更高效，而不是消除递归本身。因此必须配合合理的阈值控制与非阻塞设计，否则 LIFO 偏好反而会加速栈溢出。
