企业官网建设流程全解析

21-对象存活判定：引用计数与可达性分析

垃圾回收的第一步是判断对象是否"存活"。看似简单的问题，背后却藏着两种截然不同的思路：一种是为每个对象维护一个计数器，另一种是从一组确定的根出发去遍历整张对象图。前者直观但存在致命缺陷，后者则是 HotSpot 等主流 JVM 的实际选择。本篇将深入剖析这两种算法的原理、陷阱与实现细节。

引用计数法

引用计数法（Reference Counting）的思路非常朴素：给每个对象配一个引用计数器，每有一个引用指向它，计数器加一；引用失效时计数器减一；计数器为零的对象就是"可回收"的。

它的优点是实时性好——对象一旦不再被引用就能立即被回收，不需要等待 GC 周期。Python 的 CPython 实现就采用了引用计数为主、分代回收为辅的策略。

但这个算法有一个无法回避的硬伤：循环引用。

循环引用问题演示

/** * 演示循环引用导致引用计数法失效 * 适用 JDK 8/11/17 */publicclassReferenceCountingGC{publicObjectinstance=null;privatestaticfinalint_1MB=1024*1024;// 占用内存，便于观察 GCprivatebyte[]bigSize=newbyte[2*_1MB];publicstaticvoidmain(String[]args){ReferenceCountingGCobjA=newReferenceCountingGC();ReferenceCountingGCobjB=newReferenceCountingGC();// 互相引用，形成循环objA.instance=objB;objB.instance=objA;// 断开外部引用objA=null;objB=null;// 如果使用引用计数法，objA 和 objB 的计数器仍为 1，无法回收// 但 HotSpot 的可达性分析能正确识别它们为可回收对象System.gc();}}

上例中，objA和objB互相引用，它们的引用计数都不为零，但实际上从main方法的栈帧已经无法到达这两个对象。引用计数法在这种情况下会内存泄漏。这就是 Java 不采用引用计数法的根本原因。

虽然可以通过"弱引用"或"手工断环"等手段缓解，但要让编译器自动识别所有循环结构在工程上几乎不可行。因此主流 JVM 转向了另一种思路：可达性分析。

可达性分析算法

可达性分析（Reachability Analysis）的核心思想是：从一组确定活跃的根对象（GC Roots）出发，顺着引用链向下搜索。如果某个对象到 GC Roots 没有任何可达路径，就说明它已经"死亡"。

GC Roots / \ v v A B ---> C \ v D (不可达，可回收)

上图中 A、B、C 都在引用链上，是存活的；D 虽然曾被引用，但路径已断开，判定为可回收。

可达性分析天然解决了循环引用问题——因为环上的对象如果无法从 GC Roots 到达，整条环都会被判定为不可达。这也是 Java、.NET 等主流托管语言运行时的共同选择。

可达性的"三色"视角

虽然可达性分析本身不要求染色，但理解后续并发收集器时常常用到三色标记的概念：

• 白色：尚未被访问的对象。
• 灰色：自身已访问，但其引用还未全部扫描。
• 黑色：自身及引用均已扫描完毕。

初始时所有对象为白色，GC Roots 直接引用的对象被标灰，然后不断取出灰色对象、将其引用的对象标灰、自身标黑，直到灰色集合为空。最终剩下的白色对象即为可回收对象。这一过程本质上就是图的广度优先遍历。

HotSpot 的实现：OopMap

可达性分析听上去简单，但在 HotSpot 里要高效实现却面临一个棘手问题：运行时栈帧里哪些位置存放的是对象引用？如果逐个槽位扫描、还要区分引用类型与非引用类型，开销将非常惊人。

HotSpot 的解决方案是OopMap（Ordinary Object Pointer Map）。编译器在编译过程中会记录下"哪些寄存器/栈槽存放的是对象指针"。这样 GC 时就不必扫描整个栈，直接查 OopMap 就能定位所有引用。

下面是一段简化的代码与其对应的 OopMap 示意：

publicvoidfoo(){Objecta=newObject();// 局部变量 a 存于 slot 1intb=42;// 局部变量 b 存于 slot 2Objectc=newObject();// 局部变量 c 存于 slot 3// ...}

对应的 OopMap 可能记录：在字节码偏移pc=xxx处，slot 1 和 slot 3 是 oop，slot 2 是 int。GC 只需扫描这两个槽位即可。

为什么不是每条指令都生成 OopMap

如果每条字节码指令都维护一份 OopMap，空间膨胀会非常严重。HotSpot 采取了折中：只在特定位置记录 OopMap，这些位置就是所谓的安全点（Safepoint）。

安全点与安全区域

安全点（Safepoint）

安全点是程序执行流中"可以安全进行 GC"的位置。HotSpot 在这些位置生成 OopMap，保证 GC 能正确枚举根集合。典型的安全点包括：

• 方法返回处
• 循环回边（loop back-edge）
• 方法调用的入口

GC 发生时，JVM 会设置一个"GC 正在进行"的标志，各个应用线程在到达下一个安全点时会主动轮询该标志，若为真则主动挂起自己（这种模式称为"协作式"或"自愿挂起"）。

为什么要在循环回边设置安全点？因为一段没有方法调用的大循环可能长时间不进入安全点，导致 GC 等待时间过长。这种"GC 等待应用线程到达安全点"的停顿称为Time To Safepoint（TTSP），是性能调优中需要关注的指标。

# 查看安全点相关统计（JDK 11+）java-Xlog:safepoint=info-cpMyApp com.example.Main# 输出示例：# [info][safepoint] Total time for which application threads were stopped: 0.0001234s# [info][safepoint] Stopping threads took: 0.0000891s

安全区域（Safe Region）

安全点解决了"正在执行 JIT 编译代码"的线程问题，但如果线程处于Sleep或Blocked状态，它根本不会主动向前执行，也就永远到不了下一个安全点。为此 HotSpot 引入了安全区域的概念。

安全区域是指一段代码区间：在该区间内，引用关系不会发生变化。典型的安全区域包括：

• 线程调用Thread.sleep()期间
• 线程在等待监视器锁（BLOCKED 状态）
• 线程在等待 I/O 完成（如阻塞式 socket read）

线程进入安全区域时会标记自己，离开时需要检查"GC 是否完成"，如果未完成则必须等待直到 GC 结束才能离开。这样就保证了 GC 期间任何线程都不会让引用关系发生变化。

安全点与安全区域的关系

线程执行流 ───[运行]──>[安全点]───[运行]───[安全区域(sleep/IO)]───[运行]───> | | 生成 OopMap 离开时检查 GC 状态

二者配合覆盖了所有线程状态：运行中的线程在安全点挂起，阻塞中的线程在安全区域内被自然"冻结"。

实践要点

1. 关注 TTSP 抖动

生产中如果发现 GC 日志里"Stopping threads took"的时间很长，但堆本身不大、实际 GC 落盘时间短，通常是 TTSP 问题。常见原因是大循环没有方法调用、JNI 代码内长时间未返回等。

JDK 12+ 提供了更细粒度的安全点日志：

java-Xlog:safepoint=debug-cpMyApp com.example.Main

2. 避免 JNI 中长时间持有引用

本地代码（JNI）不在安全点机制覆盖范围内，如果长时间执行不返回，会拖长 TTSP。关键本地方法应定期调用AttachCurrentThread相关接口或主动检查。

3. JIT 与 OopMap 的关系

OopMap 由 JIT 编译器生成，所以只有被 JIT 编译过的方法才有精确的 OopMap。解释执行的方法靠解释器自身维护栈映射。理解这一点有助于分析为什么预热阶段和稳态阶段的 GC 表现差异较大。

4. 安全点_bias_的参数

-XX:+UseCountedLoopSafepoints（JDK 10 起默认开启）会在计数循环中也插入安全点检查，避免大整数循环阻塞 GC。如果你的应用仍运行在 JDK 8 上且存在长循环场景，建议关注相关参数。

小结

• 引用计数法实现简单、实时性好，但无法解决循环引用，Java 弃用了它。
• 可达性分析从 GC Roots 出发遍历对象图，是 HotSpot 判存活的实际算法。
• HotSpot 通过OopMap精确记录引用位置，避免全栈扫描。
• 安全点是生成 OopMap 的位置，运行中线程在此主动挂起；安全区域覆盖阻塞线程，二者共同保证 GC 期间引用关系不变。
• TTSP 是性能调优中容易被忽视的环节，应通过 GC 日志单独关注。

下一篇我们将把镜头对准"GC Roots 到底包括哪些对象"，这是理解可达性分析的关键一环。