Java不支持尾调用优化，因JVM规范未定义TCO机制且HotSpot未实现；javac不识别尾位置，字节码无跳转清栈指令；唯一可靠解法是手动转为循环。
Java根本不支持尾调用优化（TCO）
结论很直接：JVM 规范没有定义尾调用消除机制，HotSpot 虚拟机也从未实现它。哪怕你把递归写得再“尾”，factorialHelper(n - 1, acc) 这样的调用在 Java 中依然会压栈——每个调用都新建一个 StackFrame，不会复用。这不是编译器偷懒，而是 JVM 栈模型和安全机制（比如 SecurityManager 校验调用链）根本没留出自动优化的空间。
为什么写成尾递归也没用？
Java 编译器（javac）不识别尾位置，JVM 字节码（如 invokestatic）也没有“跳转并清栈”这类指令。所谓“尾递归写法”，只是让逻辑更易人工转换为循环，对运行时零优化效果。
- 现象：
StackOverflowError在n ≈ 10000左右就触发，和是否尾递归无关 - 根源：JVM 必须保留完整调用栈，用于异常堆栈追踪、调试、安全管理器权限检查
- 对比：Scala 编译器会在编译期把带
@tailrec的方法重写为while循环字节码；Java 没这个环节
真想避免爆栈，只能手动转成循环
这是目前唯一可靠、零依赖、全 JDK 版本兼容的解法。核心是把递归参数和中间状态提取为局部变量，在 while 中更新。
比如阶乘：
立即学习“Java免费学习笔记（深入）”；
public static int factorial(int n) {
int result = 1;
while (n > 1) {
result *= n;
n--;
}
return result;
}- 别试图用
ThreadLocal或栈模拟来“绕过”——反而更慢、更难维护 - 递归深度极大（如树遍历）时，若逻辑复杂，建议改用显式
Deque<State>模拟调用栈，而非强行尾递归 - Lambda +
Trampoline（弹跳床）模式虽可延迟执行，但本质仍是递归调用，仅推迟爆栈，不消除风险
未来有希望吗？短期别等
Project Loom 带来的虚拟线程和延续（continuation）能力，理论上为尾调用铺了路，但目标不是 TCO，而是协程调度。JVM 团队明确表示：尾调用优化不在近期路线图上，优先级远低于值类型、泛型特化等特性。
真正要注意的是：有人把 Scala 写的尾递归函数打包成 jar 给 Java 调用，误以为“用了 Scala 就等于 JVM 支持 TCO”——其实只是 Scala 编译器提前做了转换，Java 层面看到的已是纯循环字节码。别混淆语言层优化和 JVM 层能力。
