栈帧由JVM在执行invokestatic等字节码时自动创建并压入线程栈，与方法一一对应，生命周期由JVM控制；其结构（如局部变量表大小、操作数栈深度）在编译期确定并写入class文件的Code属性中。
Java方法调用时，栈帧是怎么被创建出来的
栈帧不是手动创建的，是每次 invokestatic、invokevirtual 等字节码执行时，JVM 自动压入当前线程栈的。它和 Java 方法一一对应，一个方法开始执行就生成帧，结束就弹出——所以递归过深会触发 StackOverflowError。
关键点在于：栈帧生命周期完全由 JVM 控制，但它的结构（局部变量表、操作数栈等）在编译期就基本确定了。javac 会根据方法签名、局部变量声明、表达式复杂度等，计算出局部变量表大小和最大操作数栈深度，并写进 class 文件的 Code 属性里。
- 局部变量表槽位（slot）按变量类型占位：
int/reference占 1 个，long/double占 2 个 - 哪怕变量作用域结束（比如 if 块内定义），只要没被复用，槽位也不会自动释放——这是很多“内存没及时回收”误解的来源
- 构造方法的第 0 号槽位固定存
this（非 static 方法），静态方法则没有
局部变量表里到底存什么，为什么有时候看不到变量
它存的是方法参数 + 方法体内显式声明的局部变量，但仅限于**编译期可确定生命周期的引用或值**。像 lambda 表达式捕获的外部变量、匿名内部类持有的外部引用，其实是以隐式参数形式传入，并占用局部变量表槽位——所以反编译时能看到额外的 val$xxx 参数。
容易踩的坑：IDE 调试时看到的“变量”不等于局部变量表里的内容。调试信息（LocalVariableTable）是可选的编译选项（-g:vars），没开的话 jdb 或某些 profiler 就查不到变量名，只显示 slot_0、slot_1 这种。
立即学习“Java免费学习笔记（深入）”；
- 基本类型直接存值；对象引用存的是堆中对象的地址，不是对象本身
- 局部变量表不保存临时计算结果（比如
a + b的中间值），那些全靠操作数栈周转 - final 修饰的局部变量不一定更省空间——JVM 不会因为 final 就跳过为其分配 slot
操作数栈不是真的“栈”，而是一块可随机访问的数组
JVM 规范里说它是“后进先出”，但 HotSpot 实际实现中，操作数栈本质是线性数组，通过栈顶指针（stack pointer）偏移访问。字节码如 iload_0、istore_1 看似简单，背后是把局部变量表第 0 个槽的值复制到操作数栈顶，再把栈顶值存回第 1 个槽——所有计算都在这个“暂存区”完成。
性能影响很实在：操作数栈深度越大，方法栈帧越大，GC Roots 扫描压力略增；极端情况（比如超长表达式链）可能让栈帧突破默认线程栈大小（-Xss，默认 1MB），导致提前溢出。
- 每个字节码指令对操作数栈的读写次数是固定的，比如
iadd弹出两个 int、压入一个 int - 没有“查看栈底”或“清空栈”的字节码指令——栈状态完全由指令序列决定
- 即时编译（JIT）时，HotSpot 会把频繁访问的操作数栈位置优化成寄存器，此时“栈”只是逻辑概念
方法出口不止 return，还有异常处理和 finally 的干扰
栈帧弹出的时机，不只看有没有 return 语句。遇到未捕获异常、athrow 指令，或者 finally 块里的控制流，JVM 都要确保方法出口处能正确恢复调用者栈帧——这也是为什么 finally 中的 return 会覆盖 try/catch 里的返回值。
真正容易被忽略的是：方法出口处的“清理”不包括局部变量表清零。槽位里的旧值可能残留（尤其对象引用），如果线程被复用（比如线程池），且没被新值覆盖，就可能引发意料外的 GC 延迟或内存泄漏假象。
- 正常 return 对应
ireturn/areturn/return字节码；异常出口走athrow - 每个
try块在 class 文件里对应一个exception_table条目，告诉 JVM 异常发生时该跳转到哪段字节码（通常是 finally 或 catch） - 方法出口的“恢复现场”，主要是把操作数栈清空、把返回值放到调用者操作数栈顶——局部变量表内容不会被擦除
