一个递归方法如果在返回前只剩下一次调用，看上去不应持续占用更多栈帧。可在 JVM 上，即使这样的 尾调用 也会在每一层创建新帧；递归足够深时，仍可能抛出 StackOverflowError。
而在 Scheme 或 Erlang 中，等价的尾递归可以在不逐层累积栈帧的前提下持续运行。差异不在于谁把递归写得更漂亮，而在于运行时如何处理尾位置的调用。
本文从字节码切入，解释 JVM 执行方法调用时发生了什么、为什么当前机制不支持栈帧重用，以及正确尾调用如何让 Scheme 和 Erlang 做出不同取舍。
尾调用的字节码语义
尾调用是指方法返回前的最后一个操作。调用之后不再有算术运算、日志记录或清理工作。控制权转移给被调用方后，调用者栈帧不再承担后续工作；从原理上说，被调用方可以重用它，而不是继续压入新帧。
在 JVM 中，每个方法调用都通过专用的字节码指令完成，包括 invokestatic、invokespecial、invokevirtual、invokeinterface 和 invokedynamic。无论调用是否位于方法末尾，这些指令都会向线程栈压入一个新帧。方法结束时，返回操作码会弹出当前帧，把返回值交给调用者的操作数栈，并让程序计数器回到原调用之后的位置。
Java 虚拟机规范为这套过程定义了统一语义：调用位于方法第一行还是最后一行，不会改变它创建新帧、返回后再弹出的基本方式。
栈帧为何无法直接复用
JVM 栈帧不仅记录返回位置，还保存局部变量数组、操作数栈、程序计数器以及指向前一帧的链接等状态。尾调用要重用调用者的帧，不能只跳过一次压栈；运行时还必须定义如何把被调用方的帧布局安全地映射到现有帧。当前字节码规范没有提供这种指令。
JVM 不支持栈帧复用的原因
如果尾调用位于方法末尾，为什么 JVM 不增加一个重用此帧的操作码？原因不在于少一条指令，而在于平台长期围绕完整调用栈建立了多项保证。
完整栈追踪依赖真实调用链
Java 对调用栈的依赖不止于控制流。异常抛出时，运行时会遍历当前活动栈帧以生成堆栈跟踪；日志、调试器和监控系统都依赖这份调用历史。若尾调用完成时提前移除帧，这些工具就会失去部分历史。
JVM 的栈遍历 API 提案 JEP 259 也体现了这一点：从 SecurityManager::getClassContext 等 API 开始，平台一直要求虚拟机能按需提供完整、可信的栈视图。尾调用消除会减少可见帧，而完整栈追踪要求保留它们，两者的目标相互牵制。
验证器要求结构化调用
类运行前，字节码验证器会检查控制流是否符合规则：跳转必须留在方法内部，操作数栈在每个分支目标处必须保持一致，栈帧也只能由既定的 invoke 与 return 指令创建和销毁。
假设存在尾调用指令，它实际上要离开一个方法的帧并进入另一个方法的帧。这与验证器试图限制的跨帧控制转移很接近。要让它既安全又不破坏现有验证模型，需要重新审视平台的一部分基础约束，而不是补充一个便捷操作码。
跨语言兼容性约束
JVM 是 Java、Kotlin、Scala、Clojure 等数十种语言的共同目标，字节码行为不能只服务某一种语言。Clojure 曾公开讨论这一限制：解释器较容易做尾调用优化，但在已编译的 JVM 字节码上同时保持较快编译速度和完整栈追踪，难度明显更高。
这也是 Clojure 提供 recur 的原因之一。它把自递归循环写成显式结构，而不是承诺通用的尾调用消除。
尾调用的跨语言取舍
| 方面 | JVM 字节码 | Scheme / Erlang |
|---|---|---|
| 调用指令 | 总是压入新帧，如 invokestatic、invokevirtual
|
尾调用按规范重用当前帧 |
| 栈追踪保证 | 所有活动调用都显示在栈上 | 中间尾调用帧不会保留 |
| 规范要求 | 不保证正确尾调用 | R5RS/R7RS 要求正确尾递归实现 |
| 实际深度限制 | 受线程栈大小限制，通常为 512 KB 至 1 MB | 主要受可用堆内存或进程内存限制 |
Scheme 对此的要求很直接：自 R5RS 起，实现必须支持无限数量的活动尾调用。尾调用的延续与外层过程相同，因此不应再为它占用额外空间。
Erlang 的 BEAM 虚拟机采用了相近思路。Erlang 社区通常把它称为最后调用优化：函数子句最后位置的任何调用，不只自递归调用，都可以重用当前栈帧。长时间运行的消息接收循环因而可以持续停留在尾调用位置，不会随着每次调用继续增加栈帧。
缺少尾调用优化的代价
一个没有局部变量的简单 Java 递归方法，在 64 位 JVM 的默认 HotSpot 栈大小下，调用深度可能达到数万次后抛出 StackOverflowError。Jedis 客户端库的一次生产事故曾记录过这类现象。
等价的 Scheme 或 Erlang 尾递归实现不会逐次累积栈帧，因此不会遇到同一种由线程栈大小决定的深度上限。差异并不在递归本身，而在调用是否保留了每一层的栈帧。
JVM 上如何应对深递归
Java 并非不能使用递归，而是需要开发者主动管理栈深度与可观测性之间的取舍。常见做法如下：
可行的工程应对方式
- 把尾递归改写为显式循环，JIT 已能高效处理这类循环。
- 对相互递归或深层嵌套递归使用跳板模式，通过返回下一步对象替代直接调用。
- 使用 Kotlin 的
tailrec修饰符，让编译器把符合条件的递归调用改写为循环，而不是依赖 JVM 提供尾调用优化。 - 把
-Xss调大只能作为权宜之计。它增加可用深度，却不提供保证，并且会增加每个线程的内存消耗。 - 在 Clojure 中，对自递归循环优先使用
recur，不要假定一般尾调用会被消除。
多年间，JVM 指令集曾出现过支持某种尾调用的非正式提议，但始终没有进入主线规范。堆栈跟踪、字节码验证和长期积累的工具链，都假设实时调用栈能如实反映当前执行状态。Scheme 与 Erlang 从设计之初就选择了相反的取舍，因此尾调用重用是它们运行模型的一部分。
JVM 的取舍与实现选择
JVM 缺少尾调用优化并非疏忽，而是指令集语义的直接结果。每条 invoke 指令都会压入包含局部变量、操作数栈和簿记信息的完整栈帧；每条 return 指令都会弹出栈帧。两者之间没有允许尾调用复用下方栈帧的机制。
这种每次调用都保留一帧的设计，也让异常栈、调试器和性能分析器能够提供可信的调用历史。JVM 选择了这项保证；Scheme 和 Erlang 则在规范层面优先保证正确尾调用，让递归或消息驱动代码能在固定栈空间内长期运行。
因此，JVM 上的实际策略仍然是循环、跳板模式，或 Kotlin tailrec、Clojure recur 等语言级改写。面对深递归时，根据调用深度和可观测性需求选择实现方式，比等待 JVM 自动折叠栈帧更实际。
相关阅读：从冷启动到尾延迟：Go 与 Java 25 怎么选 · JVM C1、C2 编译器 · JVM 关闭前做点什么 · Web3j 异步导致 JVM 无法退出 BUG 分享 · Java 与性能测试 07-线程管理