ZGC核心原理与低停顿实现：染色指针、并发转移与重映射

第一次接触ZGC，是在一个搜索推荐服务的真实现场。当时堆内存已经给到64GB，用的还是G1，压测时GC停顿动不动就上百毫秒，P99曲线像过山车。换成ZGC之后，最直观的感受是GC日志里的Pause Mark Start、Pause Mark End这类STW阶段，基本稳定在1ms左右，和堆大小几乎解耦。这篇文章不是ZGC的配置速查，而是把ZGC垃圾回收器的实现原理拆开讲清楚：为什么它能做到这么低停顿、染色指针和多重映射到底解决了什么问题、并发转移和重映射的全流程是怎么串起来的。适合两类人：一类是刚接触ZGC、想把“为什么这样设计”搞明白的Java开发者，另一类是已经在线上用过ZGC、想理解GC日志背后逻辑的人。原理清楚了，后面遇到“为什么这里会停顿”“为什么内存不释放”这类问题，基本都能自己推断出来。

1. ZGC到底在解决什么问题

1.1 传统GC的停顿根源

先看一个所有搬过家的人都能理解的场景：你要把客厅的家具重新摆放，但屋里还有老人小孩在走动。你挪沙发的时候，别人可能正坐在沙发上；你搬书架的时候，别人可能正从书架上拿书。为了避免撞车，最稳妥的办法就是让所有人停下，你一个人快速搬完，再让大家恢复活动。这个“所有人停下”就是Stop-The-World。

传统垃圾回收里，标记-复制、标记-整理这类算法，本质都逃不开移动对象。对象一旦移动，所有引用这个对象的地址就要跟着改。应用线程如果还在跑，随时可能去读旧地址，读出来就是坏数据。所以回收器必须选择一个安全点，把所有线程暂停下来，完成一段一致性非常强的工作。G1比CMS聪明的地方在于引入了Region，把堆拆成一个个小块，可以只回收部分Region。但G1的转移阶段仍然需要STW——它需要在暂停状态下，把选中的Region里活对象复制到别的Region，并且更新所有指向旧地址的引用。堆越大，Region越多，需要处理的引用关系越复杂，STW时间往往就跟着涨。

还有一个隐性问题：传统回收器在标记阶段通常要修改对象头或使用额外的记忆集合（Remember Set）来记录跨Region引用。这些东西都要占用额外内存，并且在并发访问时有很高的缓存一致性开销。CMS就是因为标记-清理不搬运对象，堆碎片化严重；G1为了整理碎片，收入和成本很难平衡。这些矛盾的根源，还是在于“对象的状态信息”和“对象的引用关系”被分散放在对象本身和元数据区里，访问时总要去读、去写，很难做到大规模并发。

1.2 ZGC的设计目标：停顿时间与堆大小无关

ZGC最早在JDK 11作为实验特性出现，核心目标就一句话：在任意大小的堆上，把GC停顿时间控制在10ms以内。更准确地说，是让STW时间不随着堆大小线性增长。ZGC团队在设计时留了个前提：不追求绝对最高的吞吐量，可以为了低延迟牺牲一部分吞吐。这和G1、Parallel Scavenge的定位完全不同。

很多人第一次看到“停顿与堆大小无关”会觉得很玄。实际上，ZGC把完整的GC周期拆成了多个阶段，其中真正需要暂停应用线程的阶段，只做两件事：一是收集一小部分跟线程栈、静态变量直接相关的GC Roots，二是做一次非常短的全局收敛。而最耗时的“遍历整个活对象图”“复制对象”“修正引用”这些操作，全部放到了并发阶段，由GC线程和应用线程同时跑。所以堆从4GB涨到64GB，ZGC的STW时间基本能稳住，涨的是并发阶段的耗时，这部分恰恰不需要暂停应用线程。

当然，ZGC也不是银弹。它适合大堆、低延迟、P99敏感的服务；如果堆只有几百MB，或者应用本身对吞吐量极度敏感、CPU核数又少，ZGC的读屏障开销和并发线程调度成本可能反而拖后腿。这些场景差异，我在第4节会结合调参经验详细聊。

2. 理解三个底层设计：Region、染色指针、多重映射

2.1 Region：把大堆切成格子，按格回收

ZGC和G1一样，不搞整堆的连续空间管理，而是把堆切分成固定大小的Region。每个Region可以独立分配、独立回收，这样GC时只需要挑选出“值得回收”的Region集合，而不是每次都要处理全堆。

ZGC的Region分成三类：小Region默认2MB，存放小对象；中Region默认32MB，存放中等大小对象；大Region则用于分配超大对象，大小按需伸展。对象越大，放进大Region的比例越高，这是为了避免对象在多个Region之间横跨，横跨对象在复制和引用追踪时都很难处理。这种分级设计还能降低复制成本：如果一个Region里活对象特别少，回收时只需搬走少量对象，剩下的空间直接释放；如果活对象密度很高，那这个Region暂时就不值得回收，留着继续用。

这里有一个容易被忽略的细节：Region只是逻辑上的“格子”，ZGC并不假定对象必须连续存放在某个固定Region里。真正支撑“不暂停也能搬对象”的，是下面要说的染色指针和多重映射。没有这两个机制，Region做得再细，搬运时还是得STW。

2.2 染色指针：状态写在指针上，而不是对象头里

这是ZGC最核心、也最反常识的一个设计。传统垃圾回收器标记对象，大部分是往对象头里写状态：标记位、分代年龄、偏向锁信息都在对象头里。标记阶段修改对象头，应用线程访问对象时也要读对象头，这就带来两个问题：一是并发访问同一对象时缓存行竞争严重，二是对象头里能放的状态位有限，很难承载GC状态机。

ZGC换了个思路：不把状态写进对象内部，而是把状态直接编进引用指针本身。它借用了64位虚拟地址空间的高位，空出4个颜色标注位：Marked0、Marked1、Remapped、Finalizable。这样，一个引用指针除了“对象在哪个地址”，还包含了“这个对象当前处于什么GC状态”。常见的x86_64/Linux实现里，低42位用于编码堆内地址，最大支持4TB堆；不同平台地址位宽会有差异，但原理一致。

你可以把染色指针想象成给快递包裹贴了不同颜色的标签：同样是这个包裹，贴红标签代表“正在标记中”，贴蓝标签代表“已经搬迁完成”，贴黄标签代表“需要特殊处理”。搬运工人看到标签颜色，就知道该走哪条流程，不需要拆开包裹看内容。GC同理：一个对象物理内存没变，但引用指针的颜色变了，语义就变了。GC线程在并发标记时，只要看到某个引用处在不正确的颜色状态，就知道这个引用还没处理过，可以立刻处理。

这个设计带来的直接好处：状态切换是原子地改写一个指针值，不需要去碰对象本体，也不需要加锁。两个Marked位专门用来交替使用，本次GC用Marked0做标记位图，下次GC用Marked1，这样就可以避免每次GC都要清空整张标记位图。ZGC把非常昂贵的内存扫描工作，变成了几下指针运算。

2.3 多重映射：三个地址，一份物理内存

染色指针解决了“状态放哪里”，但还有一个问题：同一块物理内存，如果同时被多个视图引用，GC线程怎么看对象的真实数据？应用线程访问时又怎么知道该用哪个视图？

ZGC的操作系统层面解决方案是多重映射：在JVM启动时，通过mmap把同一块物理内存映射到三个不同的虚拟地址区间，分别对应Marked0、Marked1、Remapped三个颜色视图。对于应用线程和GC线程来说，这三个地址看着不同，但它们最终指向的是同一份物理页，数据没有多份拷贝。GC线程做标记时，在当前颜色的视图上处理；应用线程访问时，通过指针的颜色位选到对应的视图。

打个比方：同一个房间，在地图App上有三个入口地址，门牌号不同，但推开门进去，家具完全一样。你手里拿的是旧门牌号，走到门口发现新门牌是另一个，导航员（读屏障）会告诉你新门牌在哪儿，并顺手帮你把门牌号换成新的。这个“顺手换门牌”的动作，就是ZGC里的自愈机制。

多重映射的好处很明显：GC调整对象状态时，不需要改写对象数据，也不需要加内存屏障保证可见性，只需要切换指针颜色的视图。缺点的代价是地址空间占用。ZGC在JVM启动时会预留大量虚拟地址空间，但这只是虚拟地址，不占物理内存，所以对实际内存没有影响。这也是为什么换ZGC后，很多人看/proc/<pid>/maps会觉得“这个进程虚拟内存怎么这么大”，其实不用担心。

3. ZGC并发回收全流程拆解

3.1 并发标记：把活对象点亮

ZGC一次完整的GC循环，大致分为并发标记、并发转移、并发重映射三个大阶段。标记阶段的目标，是找出所有从GC Roots可达的活对象。

流程是这样的：先有一个极短的STW“初始标记”，应用线程全体停一下，ZGC把每个线程栈、JNI引用、静态变量这些根引用记录下来。这一步之所以必须停，是因为线程栈里的引用只能在线程暂停的时候才能稳定枚举。但停顿时间不取决于堆大小，只取决于线程数量和根引用数量，所以通常只有零点几毫秒。

接下来是并发标记。GC线程从GC Roots出发，沿着对象引用遍历整个对象图。真正干活的是GC线程和应用线程同时进行。应用线程每访问一个引用，都会经过读屏障，读屏障会把当前对象染色到正确的标记位；如果发现有引用指向的对象还没有标记，就立即补上标记。GC线程同样通过读屏障扫描对象图。因为所有对引用的访问都会经过读屏障，所以漏标的情况能及时补上。

并发标记阶段结束前，还有一个很短的STW“再标记”，主要用来处理弱引用、虚引用、终结器引用这一类需要特殊语义的引用。之后，ZGC会统计每个Region的活对象密度和回收收益，决定哪些Region要被转移。整个标记阶段，STW只占两个极小的窗口，最耗时的对象图遍历完全并发，这是停顿不随堆大小增长的第一个关键点。

3.2 并发转移：只搬有价值的Region

标记完成后，ZGC会得到一份“回收候选Region”的清单，通常只挑选那些活对象少、碎片多的Region，复制成本低，收益高。这一步叫作并发转移。

转移开始前会有一个非常短的STW，用来初始化转移集合和准备GC Roots，然后应用线程恢复。接下来，GC线程把选中Region里的活对象逐个复制到新的Region，复制完成后，在旧对象的内存位置写入一个前向指针，指向新对象的地址。这样，如果应用线程访问到了尚未更新的旧引用，就能顺着前向指针找到新对象。

这里最精彩的就是读屏障的自愈机制。假设一个应用线程正在执行一段业务代码，读了一个对象字段，拿到一个旧引用，指向已经被转移走的旧Region。如果没有读屏障，这条引用就是悬空的，访问会出错。有了读屏障，它在拿到这个引用的瞬间检查颜色：发现对象处于“已转移但引用还没重映射”的状态，就会立刻顺着前向指针跳到新地址，并且把当前引用字段的值改写为新地址。这个过程对外部线程来说是原子的，应用线程感觉不到任何异常。优雅的地方在于，ZGC不需要专门派一个线程去全堆修正引用，而是让业务线程在访问时自然完成修正，谁碰谁改。

并发转移阶段虽然不需要STW，但非常占用CPU。GC线程要把活对象拷到新Region，业务线程访问旧引用时还要做前向跳转。如果业务线程太多了，拷贝速度跟不上分配速度，ZGC就会进入白热化状态，出现分配停顿——Application线程在尝试分配新对象时，会等待GC完成一部分转移。这一般不是算法问题，而是“堆太小+分配速率太高+GC线程太少”的综合结果。

3.3 并发重映射：拖到下一次GC再做

转移阶段结束之后，理论上是需要把堆内所有指向旧地址的引用都修正到新地址的。对很多回收器来说，这步就是STW重灾现场。但ZGC并没有单独抽出一个阶段来做全堆重映射。

它的做法是把重映射和下一次GC的并发标记合并。下一次GC启动时，同样从GC Roots出发，遍历对象引用，遇到处于Remapped状态的引用时，读屏障会重新做一次自愈修正。也就是说，重映射工作被分摊到了下一次完整的GC循环里，大多数引用会被“顺便”修正完。那些没有被下一次GC遍历到的对象，可能仍然持有旧引用，但旧Region已经被回收，不会再分配新对象，所以这些旧引用虽然存在，却不会造成错误访问；等下一次GC再次扫描到它们时，自然会更新。

怎么实现这种“两次GC共用一套机制”？靠的就是那4个颜色位。本次标记用Marked0，下次用Marked1，两个标记位图交替使用，避免了清空位图和重算状态的高成本。这也解释了为什么ZGC的GC日志里，经常能看到一个GC周期结束后，紧接着的下一个GC周期的“Concurrent Mark”阶段就承担了上一次的重映射工作。

3.4 为什么STW时间不随堆大小增长

把三个阶段串起来看，真正的STW只有三处：初始标记、再标记、转移准备。这三处做的工作量都不和堆大小成正比：

• 初始标记：枚举GC Roots，只和线程数、根引用数有关。
• 再标记：处理弱引用和少量收敛工作。
• 转移准备：选择Region集合，不扫描全堆。

最耗时的对象图标记、对象复制、引用自愈更新，全部并发完成。应用线程在并发阶段只需要付出一些读屏障的开销，不需要长时间停下来等堆。所以堆从16GB涨到64GB，ZGC的停顿依然可以做到几毫秒以内；代价是并发阶段的时间变长，GC线程占用更多CPU。这就是为什么ZGC官方文档特别强调：它适合CPU核数比较多的机器，因为它在拿“并发CPU时间”换“停顿时间”。

3.5 分代ZGC的演进

经典ZGC有一个被人诟病的点：每次GC都是全堆标记。虽然停顿低，但并发标记和转移的工作量在对象很多时依然可观。为了让年轻代对象能更频繁地被回收，JDK 16以后引入了分代ZGC的实验特性，JDK 21正式转正。

分代ZGC在染色指针上做了进一步扩展，把堆分成年轻代和老年代，年轻代采用复制回收，老年代沿用并发整理。核心的染色指针、读屏障、多重映射机制没有变，只是新增了用于跟踪跨代引用的写屏障。对使用者来说，JDK 21上可以用-XX:+ZGenerational开启分代模式，并结合-XX:+UseZGC使用；JDK 17还是只有非分代版本。我建议新项目直接考虑分代ZGC，尤其是对象分配速率高、服务对延迟敏感的场景，收益比非分代更明显。

4. 日志、参数与线上调优

4.1 先学会看ZGC日志

想用好ZGC，第一件事不是调参，而是打开GC日志。JDK 9之后统一用-Xlog，ZGC常用的日志参数组合是这样的：

-Xlog:gc*,gc+heap=debug,gc+stats=debug

在我的线上经验里，日志能看到的信息比想象中多。先看一段简化后的ZGC GC日志（不同JDK版本的阶段命名略有差异，但核心结构一致）：

[0.338s][info][gc,start] GC(1) Garbage Collection (Allocation Rate) [0.338s][info][gc,phases] GC(1) Phase: Pause Mark Start 0.048ms [0.338s][info][gc,phases] GC(1) Phase: Concurrent Mark 74.2ms [0.338s][info][gc,phases] GC(1) Phase: Pause Mark End 0.022ms [0.338s][info][gc,phases] GC(1) Phase: Concurrent Process Non-Strong References 0.013ms [0.338s][info][gc,phases] GC(1) Phase: Concurrent Reset Relocation Set 0.041ms [0.338s][info][gc,phases] GC(1) Phase: Concurrent Destroy Detached Pages 0.003ms [0.338s][info][gc,phases] GC(1) Phase: Concurrent Prepare Relocation 0.021ms [0.338s][info][gc,phases] GC(1) Phase: Concurrent Relocate 30.1ms [0.338s][info][gc,phases] GC(1) Phase: Pause Relocate Start 0.031ms

先说结论：看ZGC日志，最需要盯住的是所有带Pause的阶段。Pause Mark Start和Pause Mark End通常在1ms以内；如果它们突然超过5ms甚至10ms，说明GC Roots数量异常或业务线程太多导致收敛变慢，要关注线程栈大小和JNI引用。Concurrent Mark和Concurrent Relocate虽然耗时长，但那是GC线程并发执行的，不会阻塞业务线程，不能把这些数值当成服务停顿时间。

日志开头GC(1) Garbage Collection (Allocation Rate)里的Allocation Rate是GC触发原因，常见几种：

• Allocation Rate：预测到当前分配速率会耗尽可用内存，主动提前GC。
• Allocation Stall：应用线程分配对象时无法获取内存，被迫等待GC腾空间。这是最危险的信号。
• High Usage：堆使用量达到软限制。
• Proactive：距上次GC已经过了ZCollectionInterval，主动触发。

看到Allocation Stall频繁出现，基本就是两个方向：堆开小了，或者分配速率涨得太快。先加堆，再看并发GC线程数和ZAllocationSpikeTolerance。

4.2 常用参数与实际效果

我整理几个实际会用到的参数，没有生僻的，都是调优时真正动过的：

特别提醒一个坑：ZGC没有-XX:MaxGCPauseMillis参数。很多人从G1切过来，习惯性带上MaxGCPauseMillis=50，结果启动后发现参数不生效甚至报错。ZGC的停顿时间不是靠目标参数调节的，它靠算法保证。你真正能影响的，是GC触发的频率和并发线程数，不是某个固定的停顿目标。

4.3 一套可复制的切换步骤

我每次给服务切换ZGC，基本都按这个流程走：

1. 确认JDK版本。至少JDK 15以上，强烈建议JDK 17或JDK 21。JDK 11虽然有ZGC，但很多调优参数和分代能力都没有，不值得折腾。
2. 在测试环境把堆大小、线程数、请求模型都压到接近生产水平，先用默认参数跑3天，收集GC日志。
3. 打开日志重点看两个指标：Pause阶段耗时和Allocation Rate触发频率。如果并发标记经常超过300ms，说明对象图很大，可以考虑加CPU线程；如果频繁Allocation Stall，说明堆太小，优先加-Xmx。
4. 灰度发布。建议先在单台实例上用-XX:+UseZGC切过去，对比P99和CPU。ZGC不是没有代价的，它的读屏障会带来一些吞吐损失；如果服务CPU长期跑满，就要重新评估值不值得。
5. 稳定运行后，配合监控告警：当GC日志出现Allocation Stall或Pause超过预期阈值时，自动触发报警。

4.4 我踩过的几个坑

第一个坑：堆小就别硬上ZGC。我在一个2GB堆的定时任务服务上试过ZGC，结果是P99没改善多少，CPU反而多吃了不少。ZGC的并发标记和屏障开销，在堆规模太小时体现不出优势。这种场景老老实实用G1或者Parallel，都比ZGC划算。

第二个坑：分代参数不要凭记忆乱写。JDK 21的分代ZGC，参数是-XX:+ZGenerational，但不同版本默认行为可能不同，有些版本非分代仍是默认，有些版本分代是默认。上线前一定用java -XX:+PrintFlagsFinal -version | grep ZGC确认一下。

第三个坑：看GC日志时被Concurrent Relocate的时间吓到。有次我线上看到Concurrent Relocate吃了400ms，差点以为是服务卡了400ms，后来看了线程拓扑才明白，那是GC线程并发执行的，业务线程没有等它。判断停顿的唯一标准，还是那几个Pause阶段。

5. 常见问题与避坑速查

我把线上被问得最多的问题整理成了一张速查表，排查时照着看能省不少时间：

还有一条排查经验：想确认ZGC到底在干什么，可以用jcmd <pid> GC.heap_info查看Region使用情况，输出里会列出小Region、中Region、大Region的存活率和回收候选集合。高频触发GC时，我通常先看这个，再回GC日志找Allocation Rate，基本能定位问题。

关于ZGC还有一个额外提醒：它是并发GC，GC线程和应用线程会抢CPU。如果应用本身已经把CPU用满，ZGC并发标记时会进一步加剧CPU竞争，造成业务线程吞吐下降。这种情况下与其调GC参数，不如加核或者减少GC频率。这是我在一个CPU已经很紧张的推荐服务上得出的教训，强行上ZGC最后反而把P99压得更糟，换成分代ZGC并限制了并发线程数之后才恢复稳定。

我个人在实际操作中的体会是：ZGC最值得研究的不是那几行启动参数，而是它“把状态编码进指针”的思维方式。染色指针、多重映射和读屏障三者配合，把GC的关键操作全部打散到并发流程里。理解了这个状态机，下次看到日志里Pause阶段稳定在1ms以内，就不会只觉得“哇好快”，而是能说清楚它为什么快。如果你正准备在线上尝试ZGC，建议从“打开GC日志观察两周”开始，先建立基线，再动手调参，比一上来就抄一整套参数靠谱得多。