局部变量销毁发生在方法执行完毕栈帧出栈时，其栈空间立即释放；但堆中对象是否回收取决于引用是否全部断开，与方法结束无关。

局部变量销毁发生在栈帧出栈时

方法执行完毕，对应栈帧立刻从虚拟机栈中弹出，其中所有局部变量（包括基本类型和对象引用）所占的栈空间同步释放。这不是 GC 的工作，而是 JVM 执行模型天然保障的行为。

• int、boolean、double 等基本类型变量直接存于栈帧的局部变量表，方法结束即消失，不参与 GC
• 引用类型变量（如 String、ArrayList）在栈中只存一个地址值，该地址随栈帧一起被清空
• 堆中的实际对象不会因此立即销毁，仅当所有栈/静态引用都断开后，才可能被 GC 回收

为什么不能靠“方法结束”判断对象是否被回收

常见误解是“add() 方法执行完，new ArrayList() 就没了”，其实只是栈里那个 list 变量消失了，而堆里的 ArrayList 实例是否存活，取决于它是否还被其他变量引用。

• 若该引用被返回、赋给静态字段、放入集合或作为参数传入长生命周期对象，对象会继续存活
• 即使方法已返回，只要还有强引用指向堆中对象，GC 就不会回收它
• 可通过 System.gc() 触发尝试回收，但无法保证立即执行，也不影响栈变量的释放时机

如何验证局部变量是否真的“即时销毁”

用 jstack 或调试器观察线程栈，能直观看到方法退出后栈帧消失；但堆对象需借助 jmap -histo 或 VisualVM 查看存活实例数变化。

• 在方法末尾加 Thread.sleep(5000)，用 jstack <pid></pid> 查看该方法是否仍在栈中 —— 通常已不见踪影
• 在方法内创建大数组（如 new byte[1024 * 1024 * 10]），方法结束后观察堆内存是否下降 —— 一般不会，除非无任何引用残留
• 注意：JIT 编译可能优化掉未使用的局部变量，导致栈帧中根本没分配对应槽位

容易忽略的关键点：局部变量表大小在编译期就固定了

JVM 在类加载阶段就确定了每个方法的局部变量表容量，运行时不会动态增减。哪怕你用 if 块声明变量，只要它出现在方法体中，就占用固定槽位，直到整个栈帧被销毁。

• 例如 int x = 1; if (false) { int y = 2; } 中，y 的槽位仍存在，只是未被写入值
• 这解释了为何局部变量作用域不影响栈空间释放时机 —— 它们本就是按帧整体管理的
• 真正影响内存压力的是堆中对象的引用链长度和生命周期，不是局部变量声明本身