跳至主要內容

ZGC低延迟原理：颜色指针、读屏障、并发标记的实现机制

老张2026/4/30大约 12 分钟

ZGC低延迟原理：颜色指针、读屏障、并发标记的实现机制

适读人群：Java高级开发工程师、架构师 | 阅读时长：约20分钟 | 适用JDK版本：JDK 15+ (生产稳定版) / JDK 21 (分代ZGC)

开篇故事

2022年底，我们的一个实时风控系统遇到了严重的延迟问题。这个系统需要在50ms内完成一笔交易的风险评分，但生产监控显示，每隔一段时间就会有一批请求的响应时间突破500ms，有时候甚至超过1秒。

用GC日志一查，问题很明显：使用G1 GC，每次Mixed GC的停顿时间在150-400ms之间，GC停顿期间所有线程全部挂起，请求无法处理，超时积压，等GC结束后又是一波超时洪峰。

我们尝试把-XX:MaxGCPauseMillis从200降到50，但正如上篇所说，这样做反而降低了吞吐量，而且G1也没能稳定地把停顿控制在50ms以内，偶尔还是会有150ms的停顿。

最终决策：迁移到ZGC。JDK 15的ZGC已经是生产就绪版本，理论上STW时间不超过10ms（与堆大小无关）。

迁移后的结果让人惊讶：JVM的GC停顿时间从最高400ms降到了最高4ms，P99延迟从350ms降到了28ms，业务SLA全部达标。系统从没有一个请求超过50ms的GC停顿目标。

代价是：CPU使用率上升了约8%（并发GC占用更多CPU），以及对内存的要求更高（ZGC的并发标记和转发表需要额外内存）。

一、问题根因分析

传统GC（包括G1）的停顿时间与堆大小正相关：堆越大，需要扫描和移动的对象越多，停顿时间越长。ZGC设计的核心目标是让GC停顿时间与堆大小解耦——无论堆是1GB还是16TB，停顿时间都控制在10ms以内。

实现这个目标的关键技术是：让几乎所有的GC工作都在应用线程运行的同时并发进行。

但并发GC面临一个根本性的挑战：GC线程在扫描和移动对象时，应用线程也在同时访问这些对象，如何保证一致性？

传统做法是STW（Stop The World）——GC时所有应用线程停止，简单粗暴但停顿时间长。

ZGC的做法是：使用颜色指针（Colored Pointers）和读屏障（Load Barrier），让应用线程在访问对象时，顺便协助GC完成一些工作，从而实现真正的并发。

二、原理深度解析

2.1 颜色指针：在指针中存储GC元数据

ZGC最核心的创新是颜色指针。在64位系统中，内存地址实际上只需要48位（256TB寻址空间已经足够），剩余的高位bits被ZGC用来存储对象的GC状态信息：

64位ZGC指针的bit布局（JDK 15）：

位63~42: 未使用（reserved）
位41:    Finalizable（对象只有finalizer引用）
位40:    Remapped（重映射标记）
位39:    Marked1（标记状态1）
位38:    Marked0（标记状态0）
位37~0:  对象地址（38位，最大256GB寻址）

这四个颜色bits的含义：

Marked0Marked1RemappedFinalizable含义
0010对象已重映射，在当前GC周期可直接使用
1000对象已在GC周期1中被标记
0100对象已在GC周期2中被标记
0001对象只有finalizer引用，即将被回收

两个Marked bit交替使用：GC周期1用Marked0，GC周期2用Marked1，交替切换，避免了每次GC都要清除标记的开销。

2.2 读屏障：并发GC的安全网

颜色指针只是存储了状态，真正让并发GC安全运作的是读屏障（Load Barrier）。

每当应用线程从堆中读取一个对象引用时，JIT编译器会插入一小段屏障代码，检查指针的颜色bits是否正确：

// 原始代码
Object obj = someArray[i];

// JIT插入读屏障后（伪代码）
Object obj = someArray[i];
if (!(obj.address & GOOD_BITS == GOOD_BITS)) {
    // 指针颜色不对，需要修正
    obj = ZBarrier.loadBarrierSlowPath(obj);
}

读屏障的"慢路径"会根据当前GC阶段做不同的工作：

  • 标记阶段：如果引用的对象未被标记，将其加入标记队列
  • 转移阶段：如果引用的对象已经被转移（地址变了），更新指针指向新地址
  • 重映射阶段：确保所有过期指针被更新到新地址

这意味着，即使GC并发进行，只要应用线程访问了某个对象，读屏障就会保证访问的是正确的对象状态。

2.3 ZGC的并发GC阶段

ZGC的所有STW阶段都极短（通常<1ms），因为只做GC Roots扫描，不做全堆扫描。所有全堆的工作都在并发阶段完成。

2.4 对象转移（Relocation）与转发表

并发转移是ZGC最复杂的部分。当GC线程并发地把对象从一个地址移动到另一个地址时，应用线程可能还在用旧地址访问这个对象，怎么处理？

ZGC使用转发表（Forwarding Table）：

转发表结构：
旧地址 → 新地址

当应用线程通过读屏障检测到一个指针指向"转移中"的对象时：
1. 查转发表，获取新地址
2. 更新指针，指向新地址
3. 返回新地址的对象给应用线程

一个对象可能被GC线程转移，也可能被应用线程通过读屏障"自助转移"（因为读屏障先到），两者通过CAS操作确保只有一个线程实际执行转移。

2.5 ZGC的内存多重映射

ZGC在Linux上使用了一个非常巧妙的技术：同一块物理内存会被映射到三个不同的虚拟地址范围，分别对应三种颜色标记（Marked0、Marked1、Remapped）。

这意味着ZGC的虚拟内存使用量是堆大小的3倍。/proc/[pid]/maps里看到的内存地址范围会很大，但实际使用的物理内存是正常的。很多运维同学第一次见到ZGC应用时，都以为进程内存泄漏了，其实是被多重映射迷惑了。

# 查看ZGC虚拟内存映射
cat /proc/<pid>/maps | grep heap
# 会看到三段地址范围，对应同一块物理内存的三种视图

2.6 JDK 21 分代ZGC

JDK 21引入了分代ZGC（Generational ZGC），是ZGC的重大改进。

传统ZGC没有分代，每次GC都扫描全堆。分代ZGC将堆分为年轻代和老年代，大多数时候只回收年轻代（成本更低），老年代的GC频率更低。

# JDK 21启用分代ZGC
-XX:+UseZGC
-XX:+ZGenerational   # 启用分代（JDK 21+）

# 分代ZGC效果：
# - 吞吐量提升：减少了全堆扫描次数
# - CPU开销降低：年轻代GC更频繁但成本更低
# - 内存占用更合理

三、诊断工具与命令

3.1 ZGC日志分析

# 启用ZGC详细日志
-Xlog:gc*:file=/var/log/gc.log:time,uptime,level,tags:filecount=10,filesize=50m

# ZGC日志关键字段解读
# [0.xxx s][info][gc] GC(0) Garbage Collection (Warmup)
# [0.xxx s][info][gc,phases] GC(0) Pause Mark Start 0.145ms  ← STW停顿
# [0.xxx s][info][gc,phases] GC(0) Concurrent Mark 2.718ms
# [0.xxx s][info][gc,phases] GC(0) Pause Mark End 0.054ms    ← STW停顿
# [0.xxx s][info][gc,phases] GC(0) Concurrent Relocate 1.234ms
# [0.xxx s][info][gc,load] GC(0) Load: 2.0/2.0/2.0 (CPU负载)
# [0.xxx s][info][gc,mmu] GC(0) MMU: 2ms/98.5%, 5ms/99.2%  ← 最小变异单元

# MMU（Minimum Mutator Utilization）：
# 2ms/98.5% 表示任意2ms时间窗口内，应用线程至少运行98.5%的时间
# 即GC停顿占用不超过1.5%的2ms时间

3.2 监控ZGC关键指标

# 用jstat监控（ZGC部分信息有限，建议用JFR）
jstat -gc <pid> 1000

# 启用JFR收集ZGC详细数据
jcmd <pid> JFR.start duration=60s filename=/tmp/zgc.jfr settings=profile

# 查看当前ZGC统计
jcmd <pid> GC.heap_info

# ZGC特有的GC触发原因
# "Proactive"：ZGC主动触发（堆空间还充足，但空闲时间长）
# "Allocation Rate"：分配速率过高
# "Allocation Stall"：分配失败，需要立即GC（紧急情况）
# 如果频繁出现Allocation Stall，说明GC跟不上分配速率，需要增大堆或调整并发线程数

3.3 压力测试与延迟验证

# 使用wrk2（保持固定RPS的压测工具）
wrk2 -t4 -c100 -d60s -R 10000 --latency http://localhost:8080/api/test

# 关注P99/P99.9延迟，ZGC应用在这两个指标上有显著优势

# 使用Jitter工具测量JVM停顿
# GCEasy.io可以分析ZGC日志，生成可视化报告

四、完整调优方案

4.1 ZGC基础配置

# JDK 15-20 ZGC配置
-Xms8g
-Xmx8g
-XX:+UseZGC

# JDK 21+ 分代ZGC（推荐）
-Xms8g
-Xmx8g
-XX:+UseZGC
-XX:+ZGenerational

# ZGC并发GC线程数（默认自动计算，约CPU核心数的1/4）
# 内存分配速率高时，可以增加并发线程数
-XX:ConcGCThreads=4          # 默认：逻辑CPU数/4，最少1个

# 软引用保留期（软引用对象在内存充足时保留多少秒）
-XX:SoftRefLRUPolicyMSPerMB=0  # 0表示内存不足时立即回收软引用（激进）
                                # 默认1000ms/MB

# 定期GC（避免堆碎片）
-XX:ZCollectionInterval=120    # 每120秒至少触发一次GC

# 内存归还OS
-XX:ZUncommitDelay=300         # GC后300秒将空闲内存归还OS

# 不归还OS（提高性能，避免重新申请开销）
-XX:-ZUncommit                 # 禁用内存归还

4.2 高吞吐场景与低延迟场景的差异配置

# 低延迟优先（交易系统、实时风控）
-XX:+UseZGC
-Xms16g -Xmx16g                # 堆大些，减少GC触发频率
-XX:ConcGCThreads=8             # 更多并发线程，加快GC速度
-XX:-ZUncommit                  # 不归还内存，避免重新申请延迟
-XX:ZCollectionInterval=60      # 定期GC，维持堆健康

# 高吞吐优先（批处理、大数据）
-XX:+UseZGC
-XX:+ZGenerational              # 分代ZGC，提高吞吐量
-XX:ConcGCThreads=2             # 减少并发GC对CPU的占用
-XX:ZCollectionInterval=300     # 不频繁GC，让对象积累更多再回收

4.3 从G1迁移到ZGC的步骤

1. 升级JDK到15+（建议21+用分代ZGC）
2. 先在测试环境替换参数，运行24小时
3. 用JFR对比迁移前后的GC停顿分布
4. 关注CPU使用率变化（ZGC通常高5-10%）
5. 灰度上线，监控业务P99/P999延迟
6. 确认稳定后全量切换

五、踩坑实录

坑一：虚拟内存告警

第一次部署ZGC应用，运维系统监控到进程虚拟内存是堆大小的三倍，立刻告警说"内存泄漏"，把我叫起来排查。

花了半小时解释：ZGC的多重映射机制导致虚拟内存是实际物理内存的3倍，这是正常的设计，不是内存泄漏。物理内存使用量和RSS才是需要关注的指标，不是虚拟内存（VSS）。

教训：迁移ZGC之前，一定要提前告知运维团队，调整监控告警阈值，否则会有很多虚假告警。

坑二：ZGC在小堆上的开销

有个微服务，堆只有512MB，迁移到ZGC后CPU使用率提高了15%，反而比G1差。

原因是：ZGC的并发GC设计面向大堆（通常4G+）。小堆的GC本身就很快，ZGC的并发开销反而显得突出。对于小堆，G1甚至Serial GC的总体效率可能优于ZGC。

最终这个服务保留了G1，只有堆>=4G的服务才迁移ZGC。

坑三：Allocation Stall导致的延迟尖峰

ZGC上线后，P99延迟达到预期，但P999（千分之一）偶尔还是会出现200ms+的延迟。查ZGC日志，看到了：

GC(N) Allocation Stall (allocation.failure): 187.234ms

这是Allocation Stall——对象分配时堆空间不足，应用线程被挂起等待GC释放空间，类似于传统GC的Full GC。

原因是流量尖峰期对象分配速率超过了ZGC并发回收的速率。解决方案：增大堆（从8G到12G），同时增加并发GC线程数（-XX:ConcGCThreads从4增到6）。之后Allocation Stall彻底消失。

坑四：读屏障的性能开销被低估

ZGC的读屏障虽然大多数情况下只执行"快路径"（检查颜色bits，通常只需1-2纳秒），但在特定场景下，慢路径会被频繁触发，带来明显的性能开销。

有一个批量查询场景，每次请求需要访问几万个对象引用。GC并发期间，大量读屏障进入慢路径（更新旧指针），导致这个接口的响应时间在GC期间从10ms涨到80ms。

通过增加堆空间、减少GC频率，使GC并发期间占总时间的比例降低，从而减少了读屏障进入慢路径的概率，问题基本解决。

六、总结

ZGC通过颜色指针和读屏障这两项核心技术，实现了真正的并发GC：除了极短的Pause Mark Start（通常<1ms）和Pause Mark End，所有工作都在应用线程运行的同时完成。

颜色指针把GC状态存储在指针的高位bits中，不占用额外内存，访问效率极高。读屏障在应用线程读取对象引用时检查指针状态，必要时协助GC更新指针或标记对象，将GC工作分散到应用线程的每次内存访问中。

ZGC的代价是：更高的CPU开销（并发GC消耗CPU）、更高的内存开销（转发表、元数据）、虚拟内存是堆的3倍（多重映射）。

对于延迟敏感的系统，这些代价通常是值得的。P99停顿时间从几百毫秒降到个位数毫秒，对业务SLA的改善是质的飞跃。JDK 21的分代ZGC进一步降低了CPU开销，是目前低延迟Java应用的最优选择。

编辑此页
最近更新:
贡献者: xiaozhangge