Java GC Roots有哪些？深度解析可达性分析

GC Roots 是 JVM 进行可达性分析时不可回收的“锚点”，其本质并非取决于对象“有多重要”，而是由 JVM 严格定义的、在任意时刻都必须存活的强引用起点——包括正在运行的线程对象、栈帧中的局部变量、已加载的 Class 对象、JNI 全局引用以及 Reference 子类实例本身（但注意：它们所指向的 referent 并非 Roots）；文章深入破除“static 字段=Roots”“new 对象可能是 Roots”等常见误解，厘清 Finalizer 队列中对象不构成 Roots 的根本原因，并详解 Weak/Soft/Phantom 引用如何分阶段影响可达性判定，更直击 JNI 全局引用管理不当引发的直接内存泄漏这一高危痛点，为理解 Java 垃圾回收底层逻辑与实战调优提供关键认知支点。

哪些对象能当 GC Roots？不是“谁重要”而是“谁不能被回收”

GC Roots 是 JVM 判断对象是否存活的起点，不是靠“身份”决定的，而是看它是否天然具备强引用锚点。只要这个对象在当前时刻必须存在、无法被垃圾回收器主动清理，它就可能成为 GC Root。

常见误区是以为“new 出来的对象”或“static 字段”自动就是 Roots——其实 static 字段指向的对象只是**通过 Roots 可达**，字段本身（即类的静态变量槽）才是 Roots；而 new 出来的对象绝大多数时候反而是被 Roots 引用的叶子节点。

• JavaThread 对象本身（不是线程栈帧里的局部变量）、所有正在执行的 Java 线程的栈帧中的局部变量表项（LocalVariableTable）
• 已加载的 Class 对象（由 BootstrapClassLoader、PlatformClassLoader、AppClassLoader 加载的类本身）
• JNI 方法栈中引用的 Java 对象（JNIEnv* 持有的全局/弱全局引用）
• JVM 内部关键对象：如系统类加载器、常量池中指向类/字符串的引用、java.lang.ref.Reference 子类实例（但注意：Reference 本身是 Roots，其 referent 字段指向的对象不是）

为什么 finalizer 队列里的对象不算 GC Roots？

这是个高频误解：有人看到 Finalizer 类里有个 queue 静态字段，就以为队列里的对象是 Roots。实际上，Finalizer 实例本身是 Roots（因为它是 java.lang.ref.Finalizer 类的静态字段值），但它持有的 referent 是待终结对象——这个 referent 正处于“不可达但尚未 finalize”的中间状态，JVM 明确不把它当作 Roots，否则就永远无法回收了。

• 一旦对象进入 Finalizer 队列，它已从常规引用链断开，仅靠 Finalizer 实例维持弱关联
• 如果把 referent 当作 Roots，那所有重写了 finalize() 的对象都永远活在堆里
• JDK 9+ 已废弃 finalize()，Finalizer 类本身也被标记为 @Deprecated(since="9", forRemoval=true)

WeakReference / SoftReference / PhantomReference 怎么影响可达性判定？

它们不是改变 GC Roots，而是改变“从 Roots 出发的引用强度”。JVM 在做可达性分析时，会按引用类型分阶段扫描：先走强引用链，再根据策略决定是否跟进软/弱/虚引用。

• WeakReference：GC 时只要发现没有强/软引用链可达，就直接清空 referent 并入队，不等下次 GC
• SoftReference：只在内存不足（HeapSpace 回收后仍不够）时才清空，具体策略由 HotSpot 的 LRU 或 clock 算法实现，与 -XX:SoftRefLRUPolicyMSPerMB 参数相关
• PhantomReference：referent 被回收后才入队，且 get() 永远返回 null；它本身必须配合 ReferenceQueue 使用，否则毫无意义

注意：Reference 子类实例自身是 GC Roots（因为是 ReferenceQueue 或静态字段持有），但它们的 referent 字段不是。

本地方法栈和 JNI 引用容易漏掉哪些 Roots？

很多 NIO 直接内存泄漏或 OutOfMemoryError: Direct buffer memory 问题，根源在于忽略了 JNI 全局引用（jobject）也是 GC Roots。

• C/C++ 代码调用 NewGlobalRef() 创建的引用，必须配对调用 DeleteGlobalRef()，否则该引用永远有效，其指向的 Java 对象永不回收
• NewWeakGlobalRef() 创建的是弱引用，不阻止回收，但需注意：它在 GC 后可能变成 NULL，使用前必须判空
• JNI 方法退出时，局部引用（LocalRef）自动释放，但若在循环中频繁创建（比如遍历数组每个元素调用 NewLocalRef），可能触发 PushLocalFrame/PopLocalFrame 达到上限，报错 java.lang.OutOfMemoryError: Cannot allocate new local reference

真正难排查的是那些跨线程传递的 JNI 引用——比如一个后台 C 线程持有了 Java 对象的 GlobalRef，但 Java 层早已认为该对象该死了。这种跨语言生命周期管理，没有自动机制，全靠开发者手动对齐。

理论要掌握，实操不能落！以上关于《Java GC Roots有哪些？深度解析可达性分析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！