栈帧压栈与弹栈不产生变量表快照开销，局部变量表是编译期确定的固定内存区域，随栈帧整体分配或释放；压栈时仅按max_locals一次性分配Slot，不复制、不快照、不为作用域单独建表；弹栈时整个栈帧（含局部变量表）立即回收，引用失效即止，无历史值保留或恢复机制。
方法嵌套调用时，栈帧的压栈与弹栈本身不产生“变量表快照”的额外开销——局部变量表没有运行时快照机制，它只是编译期确定的一段固定内存区域，随栈帧整体分配或释放。
压栈：只分配，不拷贝，不快照
每次方法调用（如 main → foo → bar），JVM 在栈顶创建新栈帧，其中局部变量表按 max_locals 字段一次性分配连续 Slot 空间。这个过程不含以下行为：
- 不复制上层方法的局部变量表内容
- 不保存上层变量当前值的“快照”
- 不为作用域内每个代码块单独建表（比如 if 或 for 块内声明的变量，仍复用已有 Slot）
例如：foo() 调用 bar(int x) 时，bar 的局部变量表仅含参数 x（索引 0），它和 foo 的变量完全隔离，彼此 Slot 地址互不重叠。
弹栈：整体回收，引用失效即止
方法返回时，整个栈帧（含局部变量表、操作数栈等）从栈顶移除，其占用内存立即归还给线程栈。关键点在于：
- 局部变量表中存储的只是基本类型值或对象引用，不是对象本身
- 一旦栈帧弹出，其中所有引用消失；若这些引用是某对象的唯一强引用，该对象在下次 GC 时可能被回收
- 不存在“恢复上一帧变量快照”的动作——上层方法的栈帧早已存在，它的局部变量表一直保留在原位置，未被覆盖或修改
为什么有人误以为有“快照”开销？
常见误解来源：
-
混淆作用域与存储结构：看到
{ int a = 1; }和外层同名变量，误以为 JVM 需要保存旧值；实际是 Slot 复用，旧值早已被新值覆盖，无历史保留 - 类比调试器行为：IDE 调试时可查看各栈帧变量，那是调试信息（LineNumberTable、LocalVariableTable）配合运行时状态的呈现，并非 JVM 执行所依赖的快照机制
-
误读递归耗尽栈空间：栈溢出（
StackOverflowError）源于栈帧数量过多导致栈内存耗尽，而非每个帧存了多份变量副本
真实开销在哪？
真正影响性能的是：
- 栈帧创建/销毁本身的指针调整（
esp/ebp更新），成本极低（单条汇编指令量级） - 频繁短生命周期方法调用带来的间接成本：如 JIT 编译决策、内联失败、寄存器压力上升
- 局部变量表过大（
max_locals值高）会略微增加单帧体积，但通常微乎其微（几十字节）
只要不触发栈深度限制或引发深度递归，压栈与弹栈对局部变量表的操作几乎无感知。
