java变量生命周期决定对象可达性：局部变量随方法结束失效，成员变量与对象共存亡，静态变量长期持有引用易致内存泄漏；gc依据可达性分析，从gc roots出发判定对象是否可回收。
Java 变量的生命周期直接决定对象何时可能被垃圾回收（GC），但变量本身不被GC——真正被回收的是它所指向的堆中对象。关键不在“变量什么时候死”，而在“对象什么时候不再可达”。
局部变量：方法结束即失效
在方法、代码块或构造器内声明的变量，从声明开始存在，到所在作用域执行完毕自动消失。此时栈帧弹出，所有局部引用同时失效。
- 即使提前写
obj = null，只是断开当前引用，不加速栈帧清理；真正起效节点是方法返回那一刻 - 递归调用时，外层方法的栈帧仍保留，其局部变量持续有效，所指对象不会因内层返回而变不可达
- 编译器可能做逃逸分析，把未逃逸对象分配在栈上（标量替换），这类对象随方法结束自然消亡，不走GC流程
成员变量：与宿主对象共存亡
定义在类中、非静态的字段，其生命周期绑定于所属实例。只要该对象还被强引用着，它的所有成员变量就保持有效。
- 对象本身被回收前，成员变量所引用的其他对象，只要没有额外强引用，也会一同进入不可达状态
- 若成员变量持有外部资源（如文件句柄、数据库连接），需显式关闭，不能依赖GC——因为GC时机不确定
- 避免将大对象赋值给长期存活的成员变量，否则会延长其内存驻留时间，增加老年代压力
静态变量：程序运行期间始终有效
用 static 声明的变量属于类，随类加载而初始化，类卸载时才销毁。JVM 中绝大多数类几乎永不卸载，因此静态变量引用的对象极难被回收。
- 这是内存泄漏的高发场景：比如静态集合不断
add对象，又不清理，对象永远可达 - 若必须缓存，优先考虑
WeakReference或SoftReference，让GC能在必要时回收 - 使用
ClassLoader加载的动态类，其静态变量在类卸载后才释放——但普通应用极少触发类卸载
GC 判断的核心：是否还能从根集到达
垃圾回收器不看变量声明在哪，而是从 GC Roots（如线程栈帧中的局部变量、静态字段、JNI 引用等）出发，遍历所有强引用链。任何无法抵达的对象，即刻成为回收候选。
- 局部变量出作用域 → 栈帧中引用消失 → 若无其他路径，对象立即不可达
- 成员变量设为
null→ 断开一条引用链，但不影响其他引用存在的对象 -
System.gc()仅建议，不强制触发；现代 JVM 多数忽略该调用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
