21-对象存活判定引用计数与可达性分析垃圾回收的第一步是判断对象是否存活。看似简单的问题背后却藏着两种截然不同的思路一种是为每个对象维护一个计数器另一种是从一组确定的根出发去遍历整张对象图。前者直观但存在致命缺陷后者则是 HotSpot 等主流 JVM 的实际选择。本篇将深入剖析这两种算法的原理、陷阱与实现细节。引用计数法引用计数法Reference Counting的思路非常朴素给每个对象配一个引用计数器每有一个引用指向它计数器加一引用失效时计数器减一计数器为零的对象就是可回收的。它的优点是实时性好——对象一旦不再被引用就能立即被回收不需要等待 GC 周期。Python 的 CPython 实现就采用了引用计数为主、分代回收为辅的策略。但这个算法有一个无法回避的硬伤循环引用。循环引用问题演示/** * 演示循环引用导致引用计数法失效 * 适用 JDK 8/11/17 */publicclassReferenceCountingGC{publicObjectinstancenull;privatestaticfinalint_1MB1024*1024;// 占用内存便于观察 GCprivatebyte[]bigSizenewbyte[2*_1MB];publicstaticvoidmain(String[]args){ReferenceCountingGCobjAnewReferenceCountingGC();ReferenceCountingGCobjBnewReferenceCountingGC();// 互相引用形成循环objA.instanceobjB;objB.instanceobjA;// 断开外部引用objAnull;objBnull;// 如果使用引用计数法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 的解决方案是OopMapOrdinary Object Pointer Map。编译器在编译过程中会记录下哪些寄存器/栈槽存放的是对象指针。这样 GC 时就不必扫描整个栈直接查 OopMap 就能定位所有引用。下面是一段简化的代码与其对应的 OopMap 示意publicvoidfoo(){ObjectanewObject();// 局部变量 a 存于 slot 1intb42;// 局部变量 b 存于 slot 2ObjectcnewObject();// 局部变量 c 存于 slot 3// ...}对应的 OopMap 可能记录在字节码偏移pcxxx处slot 1 和 slot 3 是 oopslot 2 是 int。GC 只需扫描这两个槽位即可。为什么不是每条指令都生成 OopMap如果每条字节码指令都维护一份 OopMap空间膨胀会非常严重。HotSpot 采取了折中只在特定位置记录 OopMap这些位置就是所谓的安全点Safepoint。安全点与安全区域安全点Safepoint安全点是程序执行流中可以安全进行 GC的位置。HotSpot 在这些位置生成 OopMap保证 GC 能正确枚举根集合。典型的安全点包括方法返回处循环回边loop back-edge方法调用的入口GC 发生时JVM 会设置一个GC 正在进行的标志各个应用线程在到达下一个安全点时会主动轮询该标志若为真则主动挂起自己这种模式称为协作式或自愿挂起。为什么要在循环回边设置安全点因为一段没有方法调用的大循环可能长时间不进入安全点导致 GC 等待时间过长。这种GC 等待应用线程到达安全点的停顿称为Time To SafepointTTSP是性能调优中需要关注的指标。# 查看安全点相关统计JDK 11java-Xlog:safepointinfo-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:safepointdebug-cpMyApp com.example.Main2. 避免 JNI 中长时间持有引用本地代码JNI不在安全点机制覆盖范围内如果长时间执行不返回会拖长 TTSP。关键本地方法应定期调用AttachCurrentThread相关接口或主动检查。3. JIT 与 OopMap 的关系OopMap 由 JIT 编译器生成所以只有被 JIT 编译过的方法才有精确的 OopMap。解释执行的方法靠解释器自身维护栈映射。理解这一点有助于分析为什么预热阶段和稳态阶段的 GC 表现差异较大。4. 安全点_bias_的参数-XX:UseCountedLoopSafepointsJDK 10 起默认开启会在计数循环中也插入安全点检查避免大整数循环阻塞 GC。如果你的应用仍运行在 JDK 8 上且存在长循环场景建议关注相关参数。小结引用计数法实现简单、实时性好但无法解决循环引用Java 弃用了它。可达性分析从 GC Roots 出发遍历对象图是 HotSpot 判存活的实际算法。HotSpot 通过OopMap精确记录引用位置避免全栈扫描。安全点是生成 OopMap 的位置运行中线程在此主动挂起安全区域覆盖阻塞线程二者共同保证 GC 期间引用关系不变。TTSP 是性能调优中容易被忽视的环节应通过 GC 日志单独关注。下一篇我们将把镜头对准GC Roots 到底包括哪些对象这是理解可达性分析的关键一环。
