局部变量表slot复用是编译期优化，由javac依据作用域和生命周期决定，运行时不可控；可通过收缩作用域、避免long阻塞、及时置null等编码方式引导JVM自动复用。
局部变量区间的物理重合（即复用同一组 slot）是编译期优化手段，不是运行时可控行为；它不能被“主动利用”来极限压缩栈帧，但可通过编码约束引导 JVM 自动触发该优化。
理解局部变量表 slot 的复用机制
局部变量表本质是固定长度的数组，每个 slot 占 4 字节（32 位），long/double 占两个连续 slot。JVM 允许**作用域不重叠的变量共享 slot**——例如方法前半段定义的 int a 和后半段定义的 int b，若它们生命周期无交集，字节码中可能都映射到 slot 0。
- 这种复用由编译器（javac）在生成字节码时决定，依据是变量的作用域（Scope）和生命周期（Live Range）
- 运行时无法干预；-XX:+OptimizeLocalVariables 等 JVM 参数在主流 HotSpot 中已移除或无效
- ART（Android）和 GraalVM 有更积极的 slot 复用策略，但仍是编译/即时编译阶段隐式完成
能做的实际操作：让编译器更容易复用 slot
关键不是“怎么压”，而是“怎么写才能让 JVM 愿意压”。重点在于收缩变量作用域、避免跨块持有、及时置 null（对引用类型有效）：
- 把大对象声明尽量靠近使用位置，用完立即脱离作用域（比如放在 if 块或 for 循环内，而非方法开头）
- 避免在 long 生命周期变量之后再声明其他变量（long 占 2 slot，且会阻塞后续 slot 的紧凑排布）
- 对引用类型，在明确不再使用后赋值为 null（帮助 JIT 判定死亡点，提升 slot 复用概率）
- 慎用 try-with-resources 以外的 try-catch：异常处理块会延长局部变量的可见范围，干扰 slot 回收
配合栈帧整体瘦身的协同策略
单靠 slot 复用收益有限（通常节省几字节），必须结合其他确定性手段：
- 将 4+ 个参数封装为 record 或静态内部类，直接减少 max_locals 值（参数槽位在局部变量表头部连续分配）
- 拆分超长方法：方法越短，控制流越简单，JVM 越容易精确推导变量死亡点
- 禁用调试信息（-g:none）：减少 LocalVariableTable 属性体积，虽不影响运行时栈帧大小，但降低 class 文件加载压力，间接利于 JIT 内联决策
- 确认 -Xss 设置合理：过大的线程栈会稀释 cache line 利用率；对高并发低深度场景，可设为 256k 或更低
验证是否生效的方法
不要依赖直觉，用工具观测真实字节码：
- 用 javap -v 查看目标方法的 max_locals 和 LocalVariableTable，对比改写前后 slot 分配变化
- 用 JFR（Java Flight Recorder）开启 stacktrace 和 memory profiling，观察热点方法的栈帧分配频率与大小分布
- 在 Android 上可用 perfetto + ART 的 debug build 查看实际 slot 使用密度（需启用 -XX:+TraceClassLoading）
