变量失效本身不会触发GC，真正决定对象是否可回收的是其是否被任何强引用指向；局部变量离开作用域仅释放栈空间，堆中对象能否回收取决于是否存在其他强引用。
Java中哪些变量失效会触发GC？
变量本身不会触发GC，真正影响的是对象的可达性。只要一个对象不再被任何活跃的强引用指向，它就可能在下次GC周期中被回收——和变量名是否“失效”无关，只和引用链是否断开有关。
常见错误现象：NullPointerException 前以为对象已被回收，其实只是变量被置为 null，而其他地方还持有着引用；或者方法返回后局部变量消失，但若该变量曾把对象发布到静态集合里，对象依然存活。
- 局部变量离开作用域 ≠ 对象可回收（比如它被赋给了
static List） -
null掉一个引用只是断开一条路径，得确认没有其他强引用残留 - 匿名内部类/lambda 持有外部类引用，容易造成意料外的强引用延长生命周期
作用域结束时局部变量怎么影响对象生命周期？
局部变量存储在栈上，作用域结束时变量空间自动释放，但它指向的堆上对象是否能回收，取决于是否还有其他强引用存在。
使用场景：常见于工具方法中创建临时对象（如 new SimpleDateFormat()），如果没被逃逸出去，方法结束即失去所有引用，对象可回收。
立即学习“Java免费学习笔记（深入）”；
- 方法内新建对象且未赋值给成员变量、静态变量或传入其他方法 → 通常可立即回收
- 用了
ThreadLocal或缓存容器（如ConcurrentHashMap）→ 即使局部变量失效，对象仍被持有 - 调试时用 IDE 的“Evaluate Expression”查看变量，可能意外创建强引用，干扰 GC 判断
System.gc() 和 finalize() 还值得依赖吗？
不值得。它们既不可靠，也不可控，现代 JVM 几乎忽略 System.gc() 调用，而 finalize() 已在 Java 9 标记为废弃，Java 18 彻底移除。
性能影响明显：finalize() 会让对象至少经历两次 GC 才能回收，严重拖慢吞吐；System.gc() 可能触发 Full GC，造成 STW 时间飙升。
- 替代方案用
Cleaner（Java 9+）或PhantomReference+ 引用队列做资源清理 - 避免在
try-finally外依赖任何“自动清理”机制，显式关闭才是安全的 - JVM 参数如
-XX:+DisableExplicitGC会直接屏蔽System.gc()，别假设它一定生效
为什么有时候对象明明没引用了却不被回收？
最常见原因是“隐式强引用”没被发现：静态集合、监听器注册未反注册、缓存未清理、线程未终止导致 ThreadLocal 泄漏。
排查关键点不在变量作用域，而在对象图分析。JVM 不知道你“以为”它该被回收，只认实际引用链。
- 用
jmap -histo或jcmd <pid> VM.native_memory</pid>看对象堆积趋势 - 用
jstack查看线程状态，确认是否有长期运行线程持有了不该持有的对象 - 注意 JNI 全局引用（
NewGlobalRef）不会被 Java 层 GC 管理，必须手动释放
GC 的触发时机由 JVM 自主决定，变量作用域只是表象；真正要盯住的，是引用是否真实断开、有没有被谁悄悄“拽着”。写代码时少想“这个变量结束了”，多问“这个对象还有谁认识它”。
