槽位复用是编译期确定容量、运行期按作用域动态“释放+再分配”的内存优化机制；它不改变局部变量表总长度，但允许多个变量在不同时段共享同一组槽位，前提是作用域不重叠，且long/double必须整对复用。
局部变量表的槽位复用，本质是编译期确定容量、运行期按作用域动态“释放+再分配”的内存优化机制。它不改变局部变量表总长度，但能让多个变量在不同时段共享同一组槽位，从而压低单个栈帧的内存开销。
槽位复用的前提：作用域不重叠
JVM 不是凭空复用，而是严格依据变量的生命周期范围。只要两个变量的作用域没有交集（比如一个在 if 块内，另一个在该块之后声明），后声明的变量就可能复用前者的槽位。
- 作用域信息来自编译生成的 LocalVariableTable 属性，包含每个变量的起始和结束字节码偏移量
- 运行时，JVM 根据当前程序计数器（PC）的位置，判断哪些变量已“失效”
- 只有失效槽位才会被标记为可复用；若两个变量作用域重叠（如都在同一个方法体顶层），即使先后声明，也不能复用
复用的具体表现：不是共存，而是接力占用
复用不是多个变量同时写进同一个槽——这会导致数据覆盖。它指的是：前一个变量的作用域一结束，它的槽位就空出来，下一个新变量声明时，JVM 优先把它安排进这个空闲位置。
- 例如：先声明 int a = 1（占 Slot 1），再在 try 块中声明 String s = "hello"（也占 Slot 1），只要 s 的作用域在 a 之后且不重叠，Slot 1 就会被复用
- long/double 占两个连续槽位，复用时也必须整对释放和整对分配，不可拆开使用
- 实例方法的第 0 号槽固定给 this，永不参与复用
为什么编译期定总数，运行时还能“省空间”？
局部变量表总槽数在编译完成时就锁死了，不会因复用而减少。但复用降低了所需的最大槽数——也就是说，如果没有复用机制，编译器就得为所有变量分配独立槽位（包括那些只短暂存在的临时变量），导致栈帧更大；有了复用，编译器只需按“同一时刻活跃变量的最大数量”来规划槽位总数。
- 比如方法里依次声明了 a、b、c、d 四个 int，但 b 和 c 的作用域完全嵌套在 a 和 d 之间，那么实际最大并发变量数可能是 3，而非 4
- 这个“3”就是编译器最终写入 class 文件的局部变量表容量，背后正是槽位复用逻辑在驱动
对开发的实际影响：间接但真实
你写代码时不用手动管理槽位，但理解复用逻辑有助于解释一些现象：
- GC 行为差异：一个大对象引用如果被后续变量复用了槽位，原引用就断开了，对象更早进入可回收状态
- 调试体验：在作用域外尝试访问局部变量会编译失败；但某些 IDE 调试时仍能看到“残留值”，那是因为槽位内容未被立即清零，不代表变量还有效
- 栈溢出风险：大量长生命周期或作用域宽泛的局部变量（尤其是大对象引用）会推高槽位需求，间接增加单次方法调用的栈深度压力
