JVM三色标记算法原理与并发垃圾回收实践-代码聚汇网

JVM三色标记算法原理与并发垃圾回收实践

CarrieYung·2026-08-14·阅读 23 GEO检测（免费）

JVM垃圾回收三色标记

|难度：普通|阅读约 10 分钟

1. 三色标记的基本概念与背景

三色标记（Tri-color Marking）是JVM垃圾回收器中一种重要的标记算法，它解决了传统标记-清除算法在并发标记时可能产生的对象漏标问题。我第一次接触这个概念是在研究CMS垃圾收集器时，当时为了搞明白为什么老年代回收会有"浮动垃圾"现象，才深入了解到这个精妙的标记机制。

简单来说，三色标记将内存中的对象分为三种状态：

白色：初始状态，表示尚未被垃圾回收器访问到（即未被标记）
灰色：表示对象本身已被标记，但其引用的子对象还未被检查
黑色：表示对象及其所有子引用都已被标记完成

这种标记方式最早由Dijkstra等人在1978年提出，后来被广泛应用于现代垃圾回收器的实现中。在HotSpot JVM中，无论是CMS还是G1垃圾收集器，它们的并发标记阶段都基于三色标记算法。

关键理解：三色标记本质上是一种"渐进式标记"策略，它允许垃圾回收器分批次、分阶段地完成标记工作，而不需要像传统的标记-清除算法那样必须一次性完成全堆标记。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 三色标记的工作原理详解

2.1 标记过程的三个阶段

让我们通过一个具体例子来理解三色标记的工作流程。假设我们有如下对象引用关系：

code复制A → B → D
  → C → E

初始阶段：所有对象都是白色，将GC Roots直接引用的对象（A）标记为灰色，放入灰色队列
标记阶段：
- 从灰色队列取出A，扫描A的引用，发现B和C
- 将B和C标记为灰色，A标记为黑色
- 接着处理B：扫描B的引用发现D，将D标记为灰色，B标记为黑色
- 处理C：扫描C的引用发现E，将E标记为灰色，C标记为黑色
- 最后处理D和E：它们没有子引用，直接标记为黑色
完成阶段：灰色队列为空，所有可达对象都变为黑色，剩余白色对象即为垃圾

2.2 并发标记带来的挑战

在实际的JVM实现中，标记过程往往是并发执行的（即与用户线程一起运行），这就带来了一个经典问题：如果在标记过程中，用户线程修改了对象引用关系怎么办？

考虑这个场景：

对象A（黑色）已经完成标记
用户线程执行：A.field = null; B.field = D;
此时D原本是白色对象，但因为A已经变黑不会被重新扫描，导致D被错误回收

这就是著名的"对象消失"问题。我在实际性能调优中就遇到过因此导致的内存泄漏，现象是某些对象莫名其妙"消失"，但堆内存使用量却持续增长。

3. 解决并发标记问题的两种策略

3.1 增量更新（Incremental Update）

CMS垃圾收集器采用的解决方案。其核心思想是：当黑色对象插入新的白色对象引用时，将这个黑色对象重新变为灰色。这样在后续标记阶段会重新扫描它。

用代码表示就是：

java复制void writeBarrier(Field field, Object newValue) {
    if(isMarkingPhaseActive() && isBlack(field.obj) && isWhite(newValue)) {
        makeGrey(field.obj);  // 关键操作
    }
    field.set(newValue);
}

这种方式的优点是实现相对简单，但缺点是会产生较多的浮动垃圾（因为有些对象可能已经不再被引用，但仍被标记为存活）。

3.2 原始快照（Snapshot-At-The-Beginning, SATB）

G1垃圾收集器采用的方案。其思路是：假设标记开始时所有引用关系构成一个快照，之后删除的引用仍被视为有效，确保不会漏标。

对应的写屏障实现：

java复制void writeBarrier(Field field, Object oldValue) {
    if(isMarkingPhaseActive() && isWhite(oldValue)) {
        addToMarkStack(oldValue);  // 将旧引用记录下来
    }
    field.set(newValue);
}

我在对比测试中发现，SATB通常会产生比增量更新更少的浮动垃圾，但对写操作的开销略高一些。

4. 三色标记在JVM中的实际应用

4.1 在CMS收集器中的应用

CMS的并发标记阶段完全基于三色标记：

初始标记（STW）：标记GC Roots直接关联的对象（灰色）
并发标记：应用线程与标记线程并发执行
重新标记（STW）：处理并发阶段产生的引用变化
并发清除

一个常见误区是认为CMS没有整理阶段。实际上，CMS通过空闲列表管理内存，虽然不进行压缩，但仍然需要处理标记阶段产生的浮动垃圾。

4.2 在G1收集器中的优化

G1对三色标记做了重要优化：

使用位图（Bitmap）代替对象头中的标记位
引入Remembered Sets记录跨区域引用
采用并行标记提高吞吐量

在我的性能测试中，对于大堆（>8G）应用，G1的标记效率通常比CMS高20-30%，特别是在处理跨代引用时优势更明显。

5. 三色标记相关的面试要点

根据我参与面试的经验，关于三色标记常被问及的问题包括：

基础概念：
- 三色分别代表什么状态？
- 为什么需要三色标记而不是两色？
并发问题：
- 什么是"对象消失"问题？
- 增量更新和SATB的区别是什么？
- 写屏障在标记过程中起什么作用？
实践应用：
- CMS和G1如何处理标记阶段的对象引用变化？
- 三色标记如何影响垃圾回收的停顿时间？
性能影响：
- 标记阶段对应用性能的影响因素有哪些？
- 如何通过参数优化标记阶段的性能？

对于准备面试的同学，我建议不仅要理解概念，还要能画出标记过程的状态变化图，并解释清楚写屏障的具体工作方式。我在面试候选人时，发现能清晰描述SATB工作原理的通常对JVM有较深理解。

6. 实际案例分析：标记阶段导致的长暂停

去年我们遇到一个生产环境问题：一个使用CMS的Java服务在高峰期频繁出现1-2秒的停顿。通过GC日志分析发现是重新标记阶段耗时异常。

排查过程：

检查-XX:+CMSScavengeBeforeRemark参数是否开启（没有）
分析对象修改频率（发现某些缓存对象被高频更新）
检查写屏障开销（通过-XX:+PrintGCStats确认）

最终解决方案：

启用CMSScavengeBeforeRemark减少重新标记工作量
调整缓存更新策略，在标记阶段减少写操作
对关键路径代码使用@Contended减少伪共享

这个案例让我深刻理解到，三色标记不仅是理论概念，它的实现细节会直接影响应用性能。现在我在做系统设计时，都会特别考虑对象修改频率对GC的影响。

7. 三色标记的局限性与替代方案

虽然三色标记是当前主流的标记算法，但它也存在一些局限性：

内存开销：需要维护标记位和队列，对于小对象多的应用，这部分开销占比可能较高
写屏障开销：特别是在高并发写场景下，可能成为性能瓶颈
渐进式标记的固有缺陷：总会有一定量的浮动垃圾无法及时回收

一些新兴的GC算法尝试用不同方式解决这些问题：

ZGC使用着色指针和读屏障
Shenandoah使用Brooks指针
Azul的C4算法采用连续并发压缩

我在测试ZGC时发现，它的标记阶段停顿时间确实比G1更稳定，但在内存占用方面会有所增加。选择哪种方案需要根据具体应用特点权衡。