成员变量生命周期始于对象创建完成、终于对象不可达；它依附于对象存在，不随引用增减而生灭，也不受gc时机影响。
成员变量的生命周期完全绑定于它所属的对象，不是从“被引用”开始，也不是到“被回收”结束——而是始于对象创建完成，终于对象不可达。
成员变量何时真正诞生
只要 new 表达式执行成功、构造器完成初始化，成员变量就已分配在堆内存中，并完成默认或显式赋值。此时哪怕没有变量名指向它（比如匿名对象），它也真实存在。
- 例如：
new Person().name = "Alice";中的name已被创建并赋值，尽管没有局部变量保存该对象 - 成员变量不是“随引用而生”，引用变量（如
Person p）只是栈上的访问通道，不影响成员变量是否存在 - 对象在堆中诞生那一刻，所有实例字段同步初始化：基本类型取默认值（
0、false等），引用类型为null
成员变量何时逻辑上终结
当对象彻底失去所有强引用链，变成不可达状态时，它的成员变量就已退出生命周期。这不是 GC 执行的时刻，而是程序逻辑上“再也无法访问”的节点。
-
p = null;或方法返回后局部引用消失，仅表示移除一个引用路径，不等于对象立即失效 - 静态字段、集合容器、ThreadLocal、监听器注册等都可能隐式持有强引用，延长对象存活时间
- GC 是否运行、何时回收、是否真释放内存，均由 JVM 决定，开发者无法控制或感知
与局部变量、静态变量的关键区别
三类变量的生命周期锚点完全不同，混淆容易导致内存误判或空指针异常。
- 局部变量：存在于栈帧中，方法调用开始时分配，方法返回时销毁，作用域外即不可见
- 静态变量：随类加载而初始化，存于方法区，整个程序运行期间始终存在，所有实例共享
- 成员变量：每个对象独有一份，严格依附于该对象的可达性，既不随局部引用消亡，也不因 GC 延迟而“多活一会儿”
常见误区与实践提醒
理解生命周期本质，有助于写出更健壮、低风险的代码。
- 不要依赖
System.gc()或 finalize() 判断成员变量是否还可用——它们不可靠且已被弃用 - 避免在对象可能被提前释放的场景中缓存成员变量的副本（如把
obj.field提前赋给局部变量再用），以防字段值陈旧或对象已不可达 - 监听器、回调、线程任务中持有对象引用时，需主动清理，否则易造成内存泄漏——因为成员变量会随着对象持续存在
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
