slot复用不改变逻辑但影响gc，因局部变量表是gc roots；只要slot存有引用，对象就不可回收。典型时机：作用域结束或变量后续未读写。未复用则引用残留，需新变量赋值或置null才能释放。
Slot复用本身不改变程序逻辑，但会直接影响局部变量表是否还持有对象引用——而这个引用关系，正是GC Roots的一部分。只要槽位里还存着对象的引用，哪怕变量早已“用完”，GC也不敢回收它。
Slot复用发生的两个典型时机
局部变量表的槽（Slot）不是按方法体长度静态分配的，而是动态复用的。关键看字节码指令中程序计数器（PC）当前所处的位置：
- 变量作用域显式结束：比如用 { } 包裹的代码块，块结束后该变量在字节码层面就“不可见”了
- 变量虽未出作用域，但后续代码再未读写它：JVM可能提前判定其“死亡”，腾出对应Slot供新变量使用
为什么Slot没被复用，大对象就收不回来？
局部变量表是GC Roots之一。只要某个Slot仍存有对堆中对象的引用，该对象就被视为“可达”，无法进入回收队列：
- 示例中 byte[] placeholder = new byte[64MB] 定义在块内，块结束后逻辑上已不可访问
- 但如果块后没新变量声明，placeholder 占用的 Slot 一直空闲但未被覆盖，引用依然存在
- 此时调用 System.gc()，GC发现该引用还在Roots中，跳过回收
怎么让Slot真正“释放”引用？
不是靠删变量、也不是靠加注释，而是靠“写入新值”来覆盖旧Slot：
- 在块后声明一个新变量（如 int a = 0;），它很可能复用 placeholder 的 Slot，原引用被覆盖
- 手动置 placeholder = null; 同样有效——这是显式写入 null 值，等效于切断引用
- 注意：仅靠作用域结束或编译期优化（如 -XX:+DoEscapeAnalysis）不能保证即时生效，尤其在未开启JIT或调试模式下
实际开发中需要注意什么？
这个问题在普通业务代码中极少暴露，但在以下场景需留心：
- 处理超大临时对象（如百万级List、大文件缓冲区）时，建议显式置 null 或控制作用域+紧接声明新变量
- 单元测试中频繁调用含大对象的方法，若复用同一栈帧且未触发Slot复用，可能引发内存堆积
- 使用 javap -v 查看 LocalVariableTable 和 Code 属性，能直观确认变量作用域（Start + Length）和Slot分配情况
