【面试专栏｜JVM虚拟机】JVM垃圾回收入门：对象死亡判断的底层逻辑

🍃 予枫：个人主页
📚 个人专栏: 《Java 从入门到起飞》《读研码农的干货日常》《Java 面试刷题指南》

💻 Debug 这个世界，Return 更好的自己！

引言

作为Java程序员，JVM垃圾回收机制是面试绕不开的高频考点，而“如何判断对象死亡”更是基础中的基础。很多人只记结论却不懂底层逻辑，面试时被面试官追问就慌了阵脚。本文将从原理出发，拆解对象死亡的2种核心判断方式，补充面试高频追问，帮你吃透考点、轻松应答，建议收藏备用！

文章目录

• 引言
• 一、为什么要判断对象死亡？
• 二、对象死亡判断的2大核心机制
  • 2.1 引用计数法（已淘汰）
    • 原理
    • 示例（伪代码）
    • 致命缺陷：循环引用问题
  • 2.2 可达性分析算法（主流核心）
    • 原理
    • 第一步：明确GC Roots的组成（面试高频考点）
    • 第二步：可达性分析流程（附流程图）
    • 第三步：对象死亡的最终确认（二次标记）
• 三、面试官追问环节（实战价值拉满）
  • 追问1：JVM为什么不采用引用计数法，而是选择可达性分析算法？
  • 追问2：GC Roots具体包含哪些对象？有没有补充的？
  • 追问3：对象被标记为不可达后，为什么不立即回收？
  • 追问4：finalize()方法能真正让对象“自救”吗？为什么不推荐使用？
• 四、总结

一、为什么要判断对象死亡？

在JVM中，内存资源是有限的，尤其是堆内存（存储对象实例的核心区域）。如果创建的对象不再被使用，却一直占用内存，久而久之会导致内存泄漏，甚至触发OOM（OutOfMemoryError）异常，导致程序崩溃。

因此，JVM垃圾回收的核心前提的是：准确判断哪些对象已经“死亡”（不再被任何地方引用，失去使用价值） ，才能安全地回收其占用的内存，保证程序稳定运行。

简单来说：判断对象死亡，是垃圾回收的“前置操作”，也是避免内存浪费的关键。

二、对象死亡判断的2大核心机制

JVM判断对象死亡，主要依赖两种机制：引用计数法 和 可达性分析算法。其中，可达性分析算法是目前JVM主流采用的核心方式，而引用计数法因自身缺陷被淘汰，我们逐一拆解。

2.1 引用计数法（已淘汰）

原理

给每个对象分配一个“引用计数器”，当对象被引用一次，计数器值加1；当引用失效（比如变量赋值为null），计数器值减1。当计数器值为0时，认为该对象已经死亡，可被回收。

示例（伪代码）

// 创建对象，计数器=1Object obj =newObject();// 新增引用，计数器=2Object obj2 = obj;// 引用失效，计数器=1 obj =null;// 引用失效，计数器=0（对象可被回收） obj2 =null;

致命缺陷：循环引用问题

引用计数法最大的问题的是无法解决“循环引用”场景，这也是它被JVM淘汰的核心原因。

比如两个对象互相引用，但都不再被其他地方引用，此时它们的计数器值都为1，无法被回收，导致内存泄漏：

classA{privateB b;publicvoidsetB(B b){this.b = b;}}classB{privateA a;publicvoidsetA(A a){this.a = a;}}// 循环引用A a =newA();B b =newB(); a.setB(b); b.setA(a);// 引用失效，但计数器都为1，无法回收 a =null; b =null;

正因为这个缺陷，目前主流JVM（如HotSpot）均未采用引用计数法，而是选择了可达性分析算法。

2.2 可达性分析算法（主流核心）

原理

以“GC Roots”（垃圾回收根节点）为起点，向下遍历所有引用链（引用关系）。如果一个对象没有任何一条引用链连接到GC Roots，则认为该对象不可达，标记为“可回收对象”（并非立即死亡，还需经过二次标记）。

简单来说：GC Roots是“不会被回收”的核心对象，从这些对象出发，能找到的对象都是“存活”的，找不到的就是“待回收”的。

第一步：明确GC Roots的组成（面试高频考点）

GC Roots必须是“绝对不会被垃圾回收”的对象，主要包括以下4类（记牢，面试常问）：

1. 虚拟机栈（栈帧中的局部变量表）中引用的对象（比如方法内定义的局部变量）；
2. 方法区中类静态属性引用的对象（比如static修饰的变量）；
3. 方法区中常量引用的对象（比如final修饰的常量）；
4. 本地方法栈中JNI（Native方法）引用的对象。

第二步：可达性分析流程（附流程图）

GC Roots

对象1

对象2

对象3

对象4

对象5

对象6

对象5、6无引用链连接到GC Roots，标记为可回收

流程拆解：

1. 确定GC Roots集合（上述4类对象）；
2. 从GC Roots出发，遍历所有引用关系，形成“存活对象引用链”；
3. 未被引用链覆盖的对象，标记为“不可达对象”，进入待回收队列。

第三步：对象死亡的最终确认（二次标记）

不可达对象并非立即死亡，还需经过“二次标记”才能确认死亡：

1. 第一次标记：通过可达性分析，标记为不可达对象；
2. 筛选判断：检查该对象是否重写了finalize()方法，且该方法未被执行过；
   • 若未重写finalize()，或已执行过，则直接标记为“死亡对象”；
   • 若重写了且未执行，则将对象放入“F-Queue”队列，由虚拟机自动执行finalize()方法；
3. 二次标记：执行完finalize()方法后，再次判断对象是否可达。若仍不可达，则正式标记为死亡对象；若重新变得可达（比如在finalize()中重新建立引用），则移除待回收队列，继续存活。

⚠️ 注意：finalize()方法是对象“最后的自救机会”，但实际开发中不建议使用（执行时机不确定、效率低，还可能导致内存泄漏），JDK9已标记为过时方法。

三、面试官追问环节（实战价值拉满）

这部分是面试加分项，帮你提前应对面试官的连环追问，比纯记八股更有用！

追问1：JVM为什么不采用引用计数法，而是选择可达性分析算法？

答：核心原因是引用计数法无法解决“循环引用”问题，会导致内存泄漏；而可达性分析算法通过GC Roots为起点，能完美避开循环引用的坑（循环引用的对象无法连接到GC Roots，会被标记为不可达）。此外，可达性分析算法的判断逻辑更严谨，能更准确地识别存活对象。

追问2：GC Roots具体包含哪些对象？有没有补充的？

答：核心是4类（虚拟机栈局部变量、方法区静态属性、方法区常量、本地方法栈JNI引用），补充2类特殊情况：

• 被同步锁（synchronized）持有的对象；
• JVM内部的对象（比如类加载器、系统类、常驻内存的对象）。

追问3：对象被标记为不可达后，为什么不立即回收？

答：为了给对象一次“自救”的机会，即通过finalize()方法重新建立引用，避免误回收（虽然实际开发中很少用，但JVM设计时保留了这个机制）。同时，批量回收不可达对象能提高垃圾回收的效率，避免频繁触发回收操作。

追问4：finalize()方法能真正让对象“自救”吗？为什么不推荐使用？

答：理论上可以（在finalize()中给对象重新赋值，建立到GC Roots的引用），但实际不推荐，原因有3点：

1. 执行时机不确定：finalize()由JVM的Finalizer线程执行，线程优先级低，无法保证及时执行；
2. 效率低：Finalizer线程执行速度慢，大量使用会拖慢垃圾回收效率；
3. 易导致内存泄漏：若finalize()中出现异常，对象无法被回收，长期积累会导致内存泄漏。

四、总结

本文核心讲解了JVM判断对象死亡的2种机制，重点掌握可达性分析算法（GC Roots、引用链遍历、二次标记），这是面试的核心考点。

核心要点总结：

1. 判断对象死亡是垃圾回收的前提，避免内存泄漏和OOM；
2. 引用计数法因循环引用缺陷被淘汰；
3. 可达性分析算法是主流，核心是GC Roots和引用链遍历；
4. 不可达对象需经过二次标记，finalize()可自救但不推荐使用。

建议结合本文的面试追问，反复梳理原理，面试时才能从容应答。觉得有用的话，点赞+收藏，后续持续更新JVM面试干货！