芙蓉塘外有轻雷1. 从一次线上告警说起：为什么你绕不开可达性分析
做Java开发的人，基本都遇到过这类场景：一台4核8G的机器，部署的应用刚上线时GC表现还很正常，结果跑了两个星期，老年代占用一路走高，Full GC越来越频繁，接口响应时间从几十毫秒飙到几秒，CPU还时不时打满。你查了堆栈、查了SQL、查了缓存，最后发现是某个静态Map把不该放的对象一直引用着，GC怎么回收都回收不掉。这时候你才想起来，JVM判断一个对象“该不该回收”，靠的正是可达性分析算法（Reachability Analysis）。
我第一次完整搞懂这个概念，也是因为一次线上事故。当时排查了很久，内存泄漏的根源是一个单例对象里存了用户Session，而Session里又挂着大对象，导致整个引用链上的对象全部成了GCRoot的“亲戚”，永远清理不掉。从那以后我就意识到，搞懂可达性分析，不只是面试背题，而是每个Java开发者排查内存问题、优化GC参数、甚至设计缓存和连接池时，都必须具备的基础功。
这篇文章想做的事很简单：把可达性分析算法从头到尾讲透。包括它是怎么诞生的、GC Roots到底是什么、三色标记怎么工作、CMS和G1在处理并发标记时各自用了什么黑科技，以及我在实际排查问题中总结的一些经验。全程尽量说人话，能用例子讲清楚的地方绝不放公式糊弄。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 可达性分析的来龙去脉：为什么不用引用计数法
2.1 引用计数法的“阿喀琉斯之踵”
在可达性分析之前，JVM早期方案和不少脚本语言（比如Python早期版本、PHP）用的是引用计数法（Reference Counting）。原理非常直观：每个对象维护一个计数器，被引用时加1，引用失效时减1，计数器归零就回收。这方案实现简单、执行高效，看起来Perfect。
但它的致命缺陷在对象循环引用时彻底暴露。举个例子：
java复制public class Node {
private Node next;
}
Node a = new Node();
Node b = new Node();
a.next = b;
b.next = a;
a = null;
b = null;
现在a和b都被置空了，但a的next还指着b，b的next也指着a，两个对象的引用计数都不是0。引用计数法直接傻眼，这两个对象就成了永远回收不掉的“僵尸对象”，只能等进程退出。如果这种环状引用出现在大型业务系统里，内存泄漏就是必然。
题外话：Python后来用gc模块做辅助回收，本质就是因为纯引用计数没法解决循环引用。Java从设计之初就抛弃了这条路，选择了更彻底的可达性分析。
2.2 可达性分析的核心思想：从“根”出发的图遍历
可达性分析的核心思路非常朴素——从一组称为GC Roots的根对象出发，沿着引用链向下搜索，所有能被遍历到的对象标记为“存活”，遍历不到的对象就是“可回收”。
说人话：JVM把整个堆内存看成一张有向图，对象是图的节点，引用关系是图的边。每次GC时，JVM从一个固定的入口集合出发，做一次图的遍历。遍历到的对象都活着，没遍历到的就是垃圾。
这里有个和引用计数法完全不同的思维转变：引用计数法是“统计每个对象有多少人指着它”，可达性分析是“从源头出发看哪些对象能被找到”。前者是局部视角，后者是全局视角。全局视角天然免疫循环引用——两个互相引用的对象，只要没有外部根引用它们，在图上就是孤岛，照样被回收。
2.3 “可达”的判定标准远比想象中严格
很多人以为“可达”只是一个非黑即白的布尔值，其实JVM对可达状态的定义相当细腻。按《Java虚拟机规范》和HotSpot的实现，对象大体分五种状态：
- 强可达（Strongly Reachable）：从GC Roots出发，不经过任何引用类型就能访问到。普通变量赋值就是这种情况，GC死活不会回收。
- 软可达（Softly Reachable）：从GC Roots出发，必须经过SoftReference才能访问到。内存充足时留着，内存紧张时优先回收，适合做缓存。
- 弱可达（Weakly Reachable）：从GC Roots出发，必须经过WeakReference才能访问到。下一次GC必然被回收，适合做防止内存泄漏的辅助结构。
- 虚可达（Phantomly Reachable）：仅能通过PhantomReference访问到，等于告诉你“这个对象马上就要被回收了”，可以在回收前做资源清理。
- 不可达（Unreachable）：从任何GC Roots出发都访问不到，真正意义上的垃圾。
这些状态不是可达性分析算法本身直接输出的，而是JVM在标记过程中结合引用类型综合判定的。搞懂这层，你才能理解为什么WeakHashMap能在内存紧张时自动释放，为什么软引用缓存会有“用着用着key还在value没了”的现象。
3. GC Roots的选取：哪些对象能当“根”
3.1 虚拟机栈和本地方法栈中的引用
可达性分析的第一步是确定GC Roots集合。HotSpot里的GC Roots来源很多，我按实际重要性逐个说。
第一个来源是虚拟机栈（Java方法栈帧）中的局部变量表和操作数栈里的引用。说白了，你代码里正在执行的每个方法，它的局部变量只要是引用类型（对象引用，不是基本类型），这个被引用的对象就是存活对象。比如：
java复制public void process() {
User user = new User();
// 此时user指向的对象就是GC Roots可达的
}
注意一点，如果方法已经执行完了，局部变量表里的引用也随栈帧弹出而消失，对象就失去了这个根引用。这也是为什么有些大对象用完最好置null——虽然编译器优化和JIT可能会忽略置null，但在长生命周期方法里确实能帮GC提前识别垃圾。
第二个来源是本地方法栈中JNI引用的对象。也就是你用native方法（比如Java调用C/C++写的底层库）时，传给native层的Java对象引用。JVM没法直接管到native层的内存，所以必须把这些对象视为强根，防止native层还在用、Java堆就给回收了。
3.2 方法区中的静态变量和常量引用
第三个来源是方法区（JDK 8以后是元空间）里的静态变量和常量引用。这是内存泄漏的高发地带。一个static Map、一个static List、一个static单例，只要往里存了对象，这些对象和它们的整个引用链就全部被根引用着，永远存活。
我自己排查内存问题时，第一步就是看有没有静态集合类越涨越大。因为静态变量的生命周期是跟着类加载器走的，类不卸载，静态引用指向的对象就不会被回收。用ThreadLocal存储用户上下文而不清理，也经常在这里翻车——ThreadLocalMap的key是弱引用，但value是强引用，线程不销毁，value链路的对象全在。
3.3 活跃线程和JVM内部对象
第四个来源是活跃的Java线程。每个正在运行的Thread对象本身是GC Roots，线程的ThreadLocalMap、线程栈里的所有局部变量，都通过这个根可达。所以线程池里长期存活的核心线程，如果ThreadLocal用完不remove，value对象就一直在，这一点踩坑的人非常多。
第五个来源是JVM内部数据结构，比如系统类加载器加载的Class对象、基本类型对应的Class对象、常驻的异常对象（比如NullPointerException）、JNI全局引用等。这些一般不涉及业务编码，但对理解“为什么某些对象明明看起来没用却回收不掉”很有帮助。
3.4 HotSpot如何高效枚举GC Roots
GC Roots分布在栈、方法区、JNI等不同区域，如果每次GC都全量扫描，代价极高。HotSpot用了一个叫OopMap的数据结构，在JIT编译时记录哪些位置是引用，GC时直接读取这些映射，就能快速找到根对象。
与之配合的是安全点（SafePoint）。GC不能在任何指令位置随时暂停线程，只能在安全点暂停，这是为了确保OopMap的准确性。这就是为什么GC日志里能看到“VM operation”等待线程到达安全点的时间，也解释了为什么长时间运行的大循环里如果没有安全点，GC会一直等待——之前遇到过一个死循环案例，某个线程在循环里跑了几十秒，GC迟迟等不到它进安全点，STW时间无限拉长。
4. 从根出发的标记过程：三色标记算法是核心
4.1 朴素的遍历方案有什么问题
确定好GC Roots之后，剩下的事就是遍历图，把可达对象标记出来。最简单的做法是用一个栈或队列做深度优先或广度优先搜索，遍历到的对象放进一个“存活集合”。
但如果GC线程在遍历过程中，业务线程还在疯狂改对象引用（比如把某个对象的字段从null改成另一个对象），那遍历的结果就会失真。这就是“并发标记”的难点所在。老一代的Serial GC用简单的Stop-The-World+串行标记就能搞定，但CMS和G1要追求低延迟，不能在标记期间长时间暂停业务线程，于是就需要更聪明的算法——三色标记。
4.2 三色标记：白、灰、黑的状态机
三色标记算法把遍历过程中的对象抽象成三种颜色：
- 白色：尚未扫描到的对象。如果标记结束后还是白色，就说明不可达，可以回收。
- 灰色：当前正在扫描的对象。它本身可达，但它引用的子对象还没扫描完。
- 黑色：扫描完成的对象。它可达，而且它引用的所有子对象也都扫描完了。
标记过程就像BFS：先置所有对象为白色，从GC Roots开始，把根对象标记为灰色并入队；每次从队列取出一个灰色对象，把它引用的所有白色对象染成灰色，然后这个对象自己从灰色变成黑色；重复直到队列为空。最后仍然白色的对象就是垃圾。
这套颜色流转的核心价值是：标记进度一目了然，黑色对象一定不会再有白色引用指向它。这为并发标记时判断“哪些改动需要重新扫描”提供了依据。
4.3 漏标问题的本质：两个必要条件
并发标记最大的风险是“漏标”——一个存活对象被业务线程改成了不可达状态，但标记线程没发现，结果被误回收。已经证明，要发生漏标，必须同时满足两个条件：
- 一个黑色对象（已经扫描完的对象）新引用了一个白色对象。
- 删除灰色对象到白色对象的引用（或这个白色对象原来就不可达）。
通俗理解：黑色对象因为扫描完了，它引用的对象都被标黑了，如果这时候它又去引用了一个还没标记的白色对象，而这个白色对象原有的唯一引用路径又被灰色对象删掉了，那这个白色对象实际上还是存活的，但标记算法已经“认为”它不可能被黑色对象引用，就漏掉了。
解决漏标有两条路：
- 增量更新（Incremental Update）：记录黑色对象新增的引用，把黑色对象重新标记为灰色。CMS采用的就是这个思路。
- 原始快照（Snapshot At The Beginning，SATB）：记录删除的引用，假设所有对象在标记开始时是存活的，即便后来某个引用被删除，也按快照标记。G1采用这个思路。
4.4 为什么CMS和G1选择了不同策略
CMS选择增量更新，是因为它面向的是“标记-清除”模型，更关注并发阶段不能漏掉存活对象，把黑色的引用对象打回灰色重新扫描，实现简单直接。
G1选择SATB，是因为它的堆被划分成很多Region，标记过程还要兼顾Region之间的引用关系。把引用变化记录在SATB队列里，比维护增量更新那套要高效得多。代价是G1会保留一些“其实已经死了但快照里活着”的对象，这些对象要等下次标记才能真正被回收，所以G1的浮动垃圾比CMS多一些。
这里多说一句：很多文章把三色标记讲得神乎其神，其实它就是解决“标记过程中引用变化了怎么办”的工程方案。理解了漏标的两个必要条件，你就知道为什么CMS的增量更新要重新标记黑色对象，为什么G1的SATB会记录删除的引用。这些设计不是拍脑袋，而是逻辑推导的必然结果。
5. 经典回收器中的可达性分析实战
5.1 Serial和Parallel：简单的STW全量标记
Serial和Parallel回收器处理可达性分析的方式最朴素：暂停所有业务线程，使用简单的DFS/BFS从GC Roots遍历整个堆，标记所有可达对象，标记完成后直接清理。整个过程是串行或并行但完全不和业务线程并发。
这种做法的优点是实现简单、没有并发同步问题，标记结果准确无误。缺点是STW（Stop The World）时间随堆大小线性增长。堆里对象越多，遍历越久，暂停越久。Parallel是Serial的多线程版本，利用多个GC线程并行标记，能把STW从几十秒压到几秒，但仍然要暂停。
实际使用中，Serial适合客户端小应用，Parallel适合追求高吞吐量的后台批处理服务——吞吐量优先，暂停时间可以忍。如果你用的是Parallel和Parallel Old组合，就别指望低延迟，把目标定为“每秒处理更多请求”更现实。
5.2 CMS：并发标记的四个步骤
CMS（Concurrent Mark Sweep）为了追求低延迟，把标记过程拆成了四步：
- 初始标记（Initial Mark）：STW，但只标记GC Roots直接可达的对象和年轻代指向老年代的引用。耗时极短。
- 并发标记（Concurrent Mark）：GC线程和业务线程并发执行，从初始标记的结果出发，遍历整个对象图，用三色标记处理引用变化。耗时长但不暂停业务。
- 重新标记（Remark）：STW，处理并发标记期间的引用变更。CMS使用增量更新，把并发阶段新增的引用重新扫描一遍。
- 并发清除（Concurrent Sweep）：GC线程和业务线程并发，直接清掉未标记对象占用的内存。
这套流程里最考验的是并发标记和重新标记。并发标记期间业务线程不停创建新对象、修改引用，所以重新标记阶段必须把这些变化吸收。CMS为了减少重新标记的扫描范围，还引入了“Card Marking”技术——把老年代分成很多小块（Card），并发修改引用时标记对应的Card为Dirty，重新标记时只扫描Dirty Card覆盖的对象。
5.3 G1：基于Region的可达性分析
G1把堆划分成大约2048个大小相等的Region，每个Region既可能属于年轻代也可能属于老年代。可达性分析不再是“全堆扫描”，而是先做全局标记，再计算每个Region的存活对象比例，优先回收垃圾最多的Region。
G1的标记流程和CMS类似，也分初始标记、并发标记、重新标记等阶段，但有一个关键差异——它依赖RSet（Remembered Set）记录Region之间的引用关系。因为每个Region都是独立的回收单位，扫描一个Region时，不能花太多时间从全部GC Roots重新遍历。RSet就是一张表：哪些Region里有对象引用了当前Region里的对象。这样扫描当前Region时，只用看RSet里记录的外部引用和本地GC Roots即可。
G1的SATB队列在并发标记阶段记录引用删除事件。为什么记删除不记新增？因为G1的Region回收粒度比CMS细，新增引用的发生频率通常比删除高得多，记录删除的引用量更小、更可控。
5.4 ZGC的染色指针：可达性分析的新范式
JDK 15后逐渐成熟的ZGC，思路更颠覆。它把对象存活信息直接编码在64位指针的未使用位上，通过指针的“颜色”判断对象是否可达，省去了传统的标记位图。标记过程变成“移转指针颜色”，成本低到可以忽略，STW时间因此被压到毫秒级。
不过ZGC处理可达性分析的方式和传统三色标记差异很大，篇幅原因不展开。你要知道的是：ZGC也不是丢掉三色标记，而是把其中一部分工作（存活标记）从“对象头”移到了“指针”上，走的是另一条路。
6. 实战：可达性分析对线上GC问题的排查价值
6.1 一个典型的内存泄漏排查思路
假设一个Spring Boot应用老年代不断上涨，Full GC越来越频繁，怎么用可达性分析的思路去排查？
第一步，先看GC日志，确认老年代回收不掉的对象是什么。第二步，用jmap或MAT等工具导堆快照，找到占用最大的对象，看它的引用链——从GC Roots到这个对象的完整路径。第三步，分析引用链上哪个环节持有不该持有的引用，把那个引用断掉。
举个具体例子：有一次排查线上OOM，MAT结果显示有个java.util.HashMap$Node占了几百MB，引用链是Thread -> ThreadLocalMap -> Entry -> value -> HashMap。问题一目了然：某个业务代码把大对象放进了ThreadLocal，线程池里的线程一直复用但从不清理ThreadLocal。把代码改成用完调用remove()，问题立刻缓解。
这里面最关键的能力，其实是“顺着引用链看对象为什么可达”。要用好MAT或Eclipse Memory Analyzer的“Path to GC Roots”功能，你会看到一个对象最终的根引用到底从哪里冒出来，是静态变量、是线程栈、还是JNI引用。定位到根，修复方案自然就出来了。
6.2 弱引用、软引用在实际业务里的正确用法
理解了可达性分析，你对各引用类型的把握会更准。
软引用适合做“可用可不用”的缓存。比如图片缩略图、大JSON解析结果，内存够就用，不够就淘汰。但要小心：软引用对象被回收前，JVM会把它放入引用队列（ReferenceQueue），你可以在后台线程监听队列做资源清理。
弱引用适合做“生命周期与外部关联”的辅助结构。WeakHashMap是典型例子：key被置空后，value会在下次GC被回收。但注意，WeakHashMap的value可能引用一个很大的对象，而value又可能间接引用key，导致key被“保活”。要彻底避免，可以用WeakReference和ReferenceQueue手工维护。
虚引用主要用来做“对象被回收前的通知”。典型场景是DirectByteBuffer的堆外内存回收——GC看到堆内的Cleaner对象（虚引用）时，会把它入队，由Reference Handler线程调用clean()释放堆外内存。你不主动用，但Netty那些高性能框架的底层都在用它。
6.3 可达性分析输出结果的动态性：别忽视Finalizer
这里必须提醒一个很反直觉的点：一个有Finalizer（重写了finalize()方法）的对象，如果不可达，JVM并不会立刻回收。它会先被放入Finalizer队列，由Finalizer线程执行finalize()，执行完才能真正释放内存。
这意味着：一个对象即使没有GC Roots可达，也不代表它马上就能被回收。如果finalize()方法本身写得不好（比如里面做了耗时的网络请求），这个对象会在队列里停留很久，累积成“假内存泄漏”。这也是我强烈建议不要使用finalize()做资源清理的原因，生产环境对它敬而远之就好。
7. 常见问题速查：那些年我们踩过的GC坑
7.1 为什么Full GC之后老年代占用还是很高
常见原因有三类：一是静态集合或缓存持有强引用，对象不可回收；二是ThreadLocal value未清理，长期存活的线程把对象拽着；三是长时间运行的大循环导致JIT编译出来的代码持有局部变量的引用。
排查方法是导堆快照，用MAT查看老年代对象的GC Roots路径。如果是第一类，直接换数据结构或用弱引用；第二类就加remove；第三类把大循环体拆成方法，让局部变量及时出作用域。
7.2 并发标记时业务线程改了引用，会出问题吗
这取决于回收器有没有正确处理。CMS用增量更新，G1用SATB，只要对应回收器的重新标记阶段被正确触发，就不会出问题。但G1的SATB可能会让某些“已死对象”多存活一个标记周期，这是设计上的权衡，不是bug。理解了漏标的两个条件，你就知道这些方案为什么会存在、各有什么代价。
7.3 一句话内存泄漏的“破案”口诀
对象不可达但是被根引用，所以不回收；引用关系在，根就在；想清理，先断根。
排查时始终记住：不要看对象本身，要看它的GC Roots路径。路径找到了，答案就出来了。
8. 小结之外：对可达性分析的个人体会
做JVM调优这些年，我最大的感受是：很多面试者在回答“可达性分析”时能背出定义，但真要他解释CMS为什么需要重新标记，或者分析一个MAT的引用链，就懵了。原因是他们只记住了结论，没理解这个算法是在解决什么问题。
可达性分析本质上是一种“以根为锚的图可达性判断”，它巧妙地避开了循环引用带来的麻烦，让JVM能准确识别存活对象。它的衍生课题——并发标记、三色标记、SATB、增量更新、RSet、染色指针——全是围绕“如何在不停业务的情况下得到准确结果”展开的。
如果你正在准备面试，建议不仅记住三色标记的状态流转，还要能把“漏标需要同时满足哪两个条件”“CMS为什么用增量更新而G1用SATB”讲清楚。这些才是区分“背题”和“真的懂”的关键点。
如果你是在排查线上问题，建议把MAT的“Path to GC Roots”功能用熟，再配合JFR的GC事件，大部分内存问题都能定位到具体代码行。
最后再分享一个小技巧：排查GC问题时，别只顾着看堆内存和GC日志。先确认STW时间、安全点等待时间、并发标记期间CPU消耗，再决定往哪个方向深挖。很多时候，问题不在回收算法本身，而在应用的引用设计——搞懂了可达性分析，你就有了判断“这对象该不该被回收”的理论基础，排查效率会高一个量级。