栈帧的局部变量表存储方法所有需访问的变量槽，包括参数、显式局部变量及编译器插入的临时变量；每个slot为32位，long/double占两个；final编译期常量可能被内联而不出现在表中。
栈帧里局部变量表到底存什么
局部变量表不是只存“局部变量”，它存的是当前方法所有需要访问的变量槽（slot），包括方法参数、显式声明的局部变量，甚至编译器插入的临时变量（比如 for 循环里的索引变量、synchronized 的锁对象引用）。每个 slot 是 32 位，long 和 double 占两个连续 slot，其余类型占一个。
容易踩的坑：
-
final变量如果在编译期能确定值（如final int x = 5;），可能被内联优化，根本不会出现在局部变量表里 - 局部变量作用域结束（比如出了
{}块）后，slot 不会自动清空，只是后续可能被复用——所以调试时能看到“已出作用域但还能读到值”的现象 - Java 8+ 默认不保留局部变量名（
LocalVariableTable属性），用javac -g编译才能在调试器里看到变量名，否则只有slot0、slot1这种编号
操作数栈为什么总在“压”和“弹”之间反复横跳
操作数栈是 JVM 执行引擎真正干活的地方：字节码指令（如 iload_0、iadd、invokestatic）几乎全靠它传参、暂存中间结果、接收返回值。它不是固定大小，而是在方法执行中动态伸缩；栈顶永远是下一个操作的目标位置。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 抛
java.lang.VerifyError: Operand stack overflow：通常是字节码生成工具（如 ASM、Javassist）写错了指令顺序，导致压栈次数远超预期深度 - 调用
invokeinterface前没把接口引用和参数按顺序压栈，运行时报VerifyError: Inconsistent stack height - 操作数栈和局部变量表混用：比如误以为
istore_0是把值“存进栈”，其实它是从栈顶弹出一个int存进局部变量表的 slot 0
栈帧结构在不同 JDK 版本间有啥实际差异
栈帧本身结构（局部变量表 + 操作数栈 + 动态连接 + 返回地址）从 Java 6 到 Java 21 没变，但底层行为受 JVM 实现和默认配置影响明显：
- JDK 7+ 默认启用栈帧压缩（
-XX:+UseCompressedOops影响对象引用大小，间接影响 slot 占用） - JDK 10 引入 JEP 270：提升栈帧元数据访问效率，但对开发者透明；不过开启
-XX:+PrintGCDetails时，GC 日志里 “stack processing” 时间变短了 - JDK 17+ 使用 ZGC 或 Shenandoah 时，栈帧中的对象引用需配合读屏障（read barrier）处理，局部变量表里存的不再是裸指针，而是可安全并发访问的句柄形式
性能提示：操作数栈最大深度由编译器在 Code 属性中写死（max_stack 字段），JVM 启动时不校验该值是否够用——不够就直接崩溃，不会扩容。
怎么用 javap 看清真实栈帧布局
javap -v 是唯一能直接看到局部变量表槽位分配和操作数栈深度的工具，但它输出的是编译后的字节码视角，不是运行时快照。
实操建议：
- 写个极简方法：
public static int add(int a, int b) { return a + b; }，然后javap -v MyClass.class | grep -A 20 "add" - 关注输出里的
LocalVariableTable（列出每个 slot 对应的变量名、范围、描述符）和StackMapTable（验证型栈帧信息，JDK 7+ 必须存在） - 注意
max_stack = 2：因为iload_0和iload_1各压一个int，iadd弹两个、压一个，全程栈高最多为 2 - 如果方法含异常处理器（
try-catch），StackMapTable条目会暴增——那是为了验证每个跳转目标处的操作数栈和局部变量表状态是否合法
真正难的不是看懂字段含义，而是理解“局部变量表索引”和“字节码里 iload_n 的 n”并不总是一一对应：当方法有实例方法调用时，slot 0 固定是 this，参数从 slot 1 开始；静态方法则参数从 slot 0 开始。这点稍不留神就会数错。
