Java中哪些对象可以作为GC Roots_可达性分析算法深度解析

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 引用的叶子节点。 对象本身（不是线程栈帧里的局部变量）、所有正在执行的 Java 线程的栈帧中的局部变量表项（ ） 已加载的 对象（由 、 、 加载的类本身） JNI 方法栈中引用的 Java 对象（ 持有的全局/弱全局引用） JVM 内部关键对象：如系统类加载器、常量池中指向类/字符串的引用、 子类实例（但注意： 本身是 Roots，其 字段指向的对象不是） 为什么 finalizer 队列里的对象不算 GC Roots？ 这是个高频误解：有人看到 类里有个 静态字段，就以为队列里的对象是 Roots。实际上， 实例本身是 Roots（因为它是 类的静态字段值），但它持有的 是待终结对象——这个 正处于“不可达但尚未 finalize”的中间状态，JVM 明确不把它当作 Roots，否则就永远无法回收了。 一旦对象进入 队列，它已从常规引用链断开，仅靠 实例维持弱关联 如果把 当作 Roots，那所有重写了 的对象都永远活在堆里 JDK 9+ 已废弃 ， 类本身也被标记为 WeakReference / SoftReference / PhantomReference 怎么影响可达性判定？ 它们不是改变 GC Roots，而是改变“从 Roots 出发的引用强度”。JVM 在做可达性分析时，会按引用类型分阶段扫描：先走强引用链，再根据策略决定是否跟进软/弱/虚引用。 立即学习 “ Java免费学习笔记（深入） ”； Eclipse导入Android或其他的JAVA项目的正确方法 WORD版 本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看 下载 ：GC 时只要发现没有强/软引用链可达，就直接清空 并入队，不等下次 GC ：只在内存不足（ 回收后仍不够）时才清空，具体策略由 的 或 算法实现，与 参数相关 ： 被回收后才入队，且 永远返回 ；它本身必须配合 使用，否则毫无意义 注意： 子类实例自身是 GC Roots（因为是 或静态字段持有），但它们的 字段不是。 本地方法栈和 JNI 引用容易漏掉哪些 Roots？ 很多 NIO 直接内存泄漏或 问题，根源在于忽略了 JNI 全局引用（ ）也是 GC Roots。 C/C++ 代码调用 创建的引用，必须配对调用 ，否则该引用永远有效，其指向的 Java 对象永不回收 创建的是弱引用，不阻止回收，但需注意：它在 GC 后可能变成 ，使用前必须判空 JNI 方法退出时，局部引用（ ）自动释放，但若在循环中频繁创建（比如遍历数组每个元素调用 ），可能触发 达到上限，报错 真正难排查的是那些跨线程传递的 JNI 引用——比如一个后台 C 线程持有了 Java 对象的 ，但 Java 层早已认为该对象该死了。这种跨语言生命周期管理，没有自动机制，全靠开发者手动对齐。