当前位置：首页 > news >正文

JVM--面试题6：如何判断对象可以被垃圾回收？

news 2026/5/11 20:37:48

JVM 面试题：如何判断一个对象可以被垃圾回收？（2026 年最新主流回答）

目前HotSpot JVM（以及几乎所有现代商用 JVM）统一采用可达性分析算法（Reachability Analysis）来判断对象是否“存活”，进而决定是否可以被垃圾回收。

1. 两种主要判断方式对比（面试常问第一层）

算法	核心思想	优点	致命缺点	HotSpot 是否采用
引用计数法	对象被引用一次，计数器 +1；引用失效 -1；计数为 0 即回收	实现简单，回收及时	循环引用导致内存泄漏	不采用
可达性分析法	以GC Roots为起点，沿着引用链搜索；不可达 → 可回收	能很好解决循环引用问题	需要暂停用户线程（STW）	采用（主流）

一句话总结：
因为引用计数法存在循环引用无法回收的致命缺陷，所以Java 从诞生起就选择了可达性分析算法。

2. 可达性分析算法核心流程（最常考点）

选定一组GC Roots（根对象集合）
从这些根对象开始，沿着强引用向下搜索（深度优先 / 广度优先均可）
所有被搜索到的对象标记为可达（活的）
搜索结束后，堆中所有未被标记的对象→ 判定为垃圾，可以被回收

用图论表述：
如果从 GC Roots 到某个对象不存在任何路径（即不可达），则该对象可以被回收。

3. 哪些对象可以作为 GC Roots？（高频背诵点）

HotSpot JVM 中常见的 GC Roots（2026 年仍然是这几类，顺序基本按重要性排列）：

序号	GC Roots 类型	典型例子	是否跨代引用常见
1	虚拟机栈（栈帧）中引用的对象	方法中的局部变量、方法参数、临时变量	非常常见
2	方法区中类静态属性引用的对象	`public static User user;`	常见
3	方法区中常量引用的对象	字符串常量池中的字符串字面量（String Table）	常见
4	本地方法栈中 JNI（Native 方法）引用的对象	native 方法中使用的对象	较少见
5	JVM 内部的引用	Class 对象、系统类加载器、常驻异常对象（如 NullPointerException）	了解即可
6	所有被同步锁（synchronized）持有的对象	`synchronized(obj)`中的 obj	了解即可
7	JMX、JVMTI 中用于实现调试、监控的引用	一些监控工具的回调对象	了解即可

面试最常问的前 4 条，背熟即可。

4. “可达性分析不可达” ≠ “马上死亡”（第二次筛选）

即使可达性分析判定为不可达，对象也不一定马上被回收，要经历两次标记过程（经典的“缓刑”机制）：

第一次标记+ 可选的 finalize() 筛选
- 如果对象没有覆盖 finalize()方法，或者 finalize() 已经被执行过 → 直接进入死亡队列
- 如果覆盖了 finalize() 且没执行过 → 放入F-Queue 队列，由 Finalizer 线程低优先级执行
第二次标记
- 在 finalize() 中重新建立引用链（比如把自己 this 赋值给某个静态变量或成员变量）→ 对象复活，从死亡队列移除
- 没有复活 → 第二次标记 →真正死亡，下次 GC 真正回收

注意：

finalize() 是对象逃亡的最后机会，但极不推荐使用（性能差、时机不确定、不安全）
从 JDK 9 开始，finalize() 已被标记为 deprecated，未来版本可能会移除

5. 简洁版标准回答（推荐背诵 30 秒版本）

面试官：JVM 如何判断对象可以被垃圾回收？
答：HotSpot JVM 使用可达性分析算法来判断。
以一组 GC Roots 为起点，沿着引用链进行搜索，从 GC Roots 不可达的对象就被判定为垃圾，可以被回收。
常见的 GC Roots 包括：
虚拟机栈中局部变量引用的对象
方法区中静态属性引用的对象
方法区常量引用的对象
本地方法栈中 JNI 引用的对象
即使不可达，也要经历两次标记（包括 finalize() 逃逸机会），才会真正被回收。