尾递归优化在java中不原生支持，forkjointask的compute()若写成同步递归（如直接调用left.compute()和right.compute()）会持续压栈导致stackoverflowerror；正确做法是用fork()异步提交子任务，主路径只同步执行一个分支（如return left.compute()），或彻底改用循环+显式队列模拟单路径推进。
尾递归优化本身在 Java 中并不原生支持，ForkJoinTask 的 compute() 方法也不是传统意义上的递归函数——它通过 fork/join 实现任务分治，并不依赖调用栈深度来控制逻辑。所谓“用尾递归思想重构 compute 以消灭栈溢出”，本质是**避免深度嵌套的同步递归调用，改用循环+任务队列或显式状态管理来模拟分治过程**，从而规避 StackOverflowError。
为什么 ForkJoinTask 的 compute 容易栈溢出？
常见误区是把“分而治之”写成同步递归：
- 在
compute()中直接调用left.compute()和right.compute()（而非fork()），导致每层调用都压栈； - 数据规模大、分割粒度细、递归过深时，JVM 栈空间耗尽；
- ForkJoinPool 虽优化了线程栈复用，但无法拯救错误的同步递归写法。
用“尾递归思想”改造的核心原则
尾递归的关键是：**当前步骤的最后动作是调用自身（且无待执行的后续逻辑）**。迁移到 ForkJoinTask，就是让任务处理变成“一次只推进一个子任务，其余入队/挂起”，避免多路同步等待。
- 不写 if (small) return ... else { left.compute(); right.compute(); } —— 这是普通递归，非尾递归，必栈溢出；
- 改成：if (small) return ... else { fork(right); return left.compute(); } —— 让右子任务异步执行，左子任务“尾调用”（实际是同步执行，但逻辑上只留一个活跃分支）；
- 更稳妥的做法是彻底剥离递归：用 while 循环 + Deque 或 List 维护待处理区间，每次 pop 一个，split 后 push 子区间，模拟尾递归的“单路径展开”。
实操：将归并排序的 compute 改为“类尾递归”风格
假设你有一个 SortTask extends RecursiveAction，原始写法：
protected void compute() {
if (end - start 改为“尾递归友好”版本：
protected void compute() {
while (end - start > 1) {
int mid = (start + end) / 2;
if (mid - start 注意：真实场景中还需处理合并时机（比如用 RecursiveTask<int></int> 返回排序后数组，或引入外部归并缓冲区）。
比“模拟尾递归”更推荐的解法
对绝大多数场景，与其费力模拟，不如直接采用更健壮的模式：
- 设置合理阈值（threshold）：让小任务走串行逻辑，避免过度分割；
-
优先用 fork() + join()，而非 compute()：例如
left.fork(); right.compute(); left.join();，保证至多一层同步等待； -
改用迭代式分治（如堆栈模拟递归）：用
ArrayDeque<range></range>替代方法调用栈，完全规避 JVM 栈限制； - 必要时换算法：比如外排、迭代归并、TimSort 等天然低栈深的替代方案。
