GC Roots是JVM判断对象存活的起点，包括Java线程对象、栈帧局部变量、已加载Class对象、JNI全局引用及JVM内部关键对象；Reference子类实例自身是Roots，但其referent不是。
哪些对象能当 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 在做可达性分析时，会按引用类型分阶段扫描：先走强引用链，再根据策略决定是否跟进软/弱/虚引用。
立即学习“Java免费学习笔记（深入）”；
-
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 层早已认为该对象该死了。这种跨语言生命周期管理，没有自动机制，全靠开发者手动对齐。
