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