对象的持久性，本质上取决于它在堆内存中是否被保留——而成员变量正是决定这种保留关系的关键线索。理解这一点，不需要深入 JVM 底层源码，只需抓住“谁持有引用”和“引用何时消失”这两个核心。
成员变量是对象存活的“锚点”
当一个对象被创建（如 new Person()），它分配在堆上；只要至少有一个强引用指向它，JVM 就不会回收它。而这个强引用，常常就藏在另一个对象的成员变量里。
例如：Order order = new Order(); 中的 order 是局部变量，存于栈，生命周期短；但若把它赋给 User user = new User(); user.currentOrder = order;，那么 user.currentOrder 这个成员变量就成了 order 对象在堆上的“锚” 只要 user 对象本身还活着（比如被某个静态容器持有着），order 就不会被 GC 回收，哪怕创建它的方法早已执行完毕
生命周期由引用链决定，而非“new 出来”的时间
很多人误以为“new 出来的对象活多久，看它自己有没有被显式销毁”。其实 Java 没有显式销毁，只看引用链是否可达。成员变量正是这条链中最常见的一环。
如果一个对象仅被局部变量引用，方法结束 → 栈帧弹出 → 引用消失 → 对象变“不可达”，很快被回收 如果它被另一个对象的成员变量引用，而那个对象又被静态字段、活跃线程、缓存容器等长期持有，那它就能“活很久”，甚至贯穿整个应用生命周期 注意：成员变量本身如果是 null，或被重新赋值为其他对象，旧对象就失去这根引用，可能立即变为可回收状态
小心“隐式延长”的生命周期
有些成员变量看似普通，却会意外拖住大量资源。这不是对象本身的问题，而是引用关系没被意识到。
比如：一个工具类持有 private static Map<String, Object> cache;，而 map 的 value 是某个含大数组的业务对象 —— 那么这个业务对象的生命周期，就被 cache 这个静态成员变量锁死了 再如：监听器注册时，把当前对象（如 Activity）作为 listener 传入外部服务，并被其成员变量（如 private Listener mCallback;）持有 → 若忘记反注册，Activity 就无法释放，引发内存泄漏
验证对象是否还在堆上？看 GC Roots 是否连得上
判断一个对象是否还具备持久性，本质是检查它能否从 GC Roots（如主线程栈帧、静态字段、JNI 引用等）出发，通过成员变量等引用路径到达。
用 jvisualvm 或 jconsole 抓堆快照，筛选对象后“右键 → Show Nearest GC Root”，就能看到是哪个类的哪个成员变量在维持它 代码中可通过弱引用辅助观察：WeakReference<MyObj> wr = new WeakReference<>(obj); obj = null;，之后调用 System.gc()，再看 wr.get() 是否为 null —— 如果不为 null，说明还有强引用（极可能来自某成员变量）
评论(0)