高并发场景下 GC 停顿优化实战：
大厂低延迟服务的 GC 选型策略

1停顿的代价：当 GC 遇上低延迟 SLA

上述场景折射出一个普遍困惑：工程师往往把 "GC 调优"理解为调参， 但实际上调参只是最后一步——在此之前，必须先回答三个问题： 停顿时间究竟从哪里来？目标收集器能否从机制上消灭这类停顿？ 以及在你的工作负载下，这个收集器的代价是否可以接受？ 许多团队在没有回答这三个问题的情况下盲目切换 GC 算法， 结果是解决了一个问题、引入了另一个问题，甚至让情况更糟。 本文试图构建一套可以回答这三个问题的推导框架，而不是提供一个"直接用这个参数"的配方。

版本说明：本文所有讨论基于 JDK 17 LTS 和 JDK 21 LTS。 JDK 17 中 G1 是默认 GC，ZGC 和 Shenandoah 均已生产可用； JDK 21 引入了分代 ZGC（Generational ZGC，实验特性，需显式开启）， 是 ZGC 演进路线上的重要里程碑，在内存开销和吞吐量两个维度都有显著改进。 CMS 在 JDK 14 已移除，本文不再讨论。

理解这个三角，是所有后续判断的前提。接下来我们先从停顿本身入手， 弄清楚 JVM 在执行 GC 时，哪些操作必须停世界（Stop-The-World），哪些可以并发， 以及为什么即使是"并发"收集器也不能完全消灭 STW。

2GC 停顿的解剖：三条根因链路

很多工程师把 GC 停顿简单理解为"在做垃圾回收"，但实际上停顿的来源远比这复杂。 要优化停顿，必须先把停顿拆分到足够细的粒度，因为不同来源的停顿 对应完全不同的优化手段。

2.1 安全点同步：被低估的隐性停顿

JVM 在执行 STW 操作之前，必须等所有正在运行的应用线程到达一个 安全点（Safe Point）。安全点是字节码执行流中 JIT 编译器预先插入的检查位， 线程在此处响应 JVM 的停止请求。整个等待过程称为到达安全点的时间（TTSP， Time To Safe Point）。

TTSP 是一个极容易被忽略的停顿来源。在 JDK 早期版本中，它完全不出现在 GC 日志里； 即使在现代 JDK 中，也需要显式打开 -Xlog:safepoint 才能看到。 在某些场景下，TTSP 会占整个"GC 停顿"时间的 50% 以上： 一个正在执行长计数循环（loop without safe point）或 JNI 调用的线程， 可以阻塞整个 JVM 数百毫秒等待它到达安全点， 而这段时间在普通 GC 日志中表现为"GC 停顿时间很长，但 GC 自身工作量很小"的矛盾现象。

2.2 并发标记中断：Remark 与 Final Mark

现代低停顿收集器的核心思路是让大量 GC 工作与应用线程并发进行， 但并发标记存在一个根本性的问题：应用线程在标记过程中会修改对象引用关系， 这可能导致标记遗漏（漏标）。为了保证正确性，所有并发收集器都必须在某个时刻 暂停所有应用线程，重新处理并发期间发生的引用变更——这就是 G1 的 Remark 阶段（使用 SATB 算法）和 ZGC/Shenandoah 的 Pause Mark End 阶段。

这类停顿的时长与并发期间引用变更的速度（即写操作的密集程度）密切相关。 写操作越密集、并发标记阶段越长，需要重处理的增量越大，Remark 停顿越长。 这也是为什么写密集型工作负载（如内存数据库、日志聚合服务） 比读密集型工作负载更难控制 GC 停顿。

2.3 疏散停顿：对象必须在 STW 内移动

回收内存的本质是移动对象（压缩堆碎片）并更新所有指向这些对象的引用。 G1 的疏散（Evacuation）阶段是完全 STW 的：在停顿期间，GC 线程将 Collection Set 中的存活对象复制到新区域，并更新所有引用。 这个阶段的停顿时长由两个因素决定：存活对象的体积 和 需要扫描的 Remembered Set 的规模。

ZGC 和 Shenandoah 的革命性创新正在于此——它们实现了 并发疏散（Concurrent Relocation）， 允许对象在应用线程继续运行的同时被移动。代价是需要一种机制 让应用线程在访问被移动的对象时能透明地找到新地址—— ZGC 用读屏障（Load Barrier），Shenandoah 用 Brooks 转发指针。 这两种机制会给每次对象读操作增加一个小的固定开销， 这正是它们吞吐量低于 G1 的主要来源之一。

理解了这三条根因链路，就能理解为什么针对不同停顿来源需要不同的应对策略： 对于 TTSP 引起的停顿，换收集器没用，应该检查 JIT 编译行为和长循环； 对于 Remark 停顿，应该关注并发期间的写操作密度，考虑降低对象变更速率； 对于疏散停顿，G1 的调优思路是"减小 Collection Set、控制 To-space 充裕度"， 而 ZGC 和 Shenandoah 的思路是"让疏散本身并发化，彻底绕开这个问题"。 三条链路对应三种完全不同的优化方向，混淆它们是很多调优尝试失败的根本原因。

3G1：区域化分代与 Mixed GC 的失败窗口

G1（Garbage First）自 JDK 9 成为默认收集器，其核心设计思路是 把堆拆分成大小相等的 Region，然后优先回收垃圾最多的 Region—— "Garbage First"名字由此而来。与传统分代收集器（固定新生代/老年代边界）不同， G1 的 Region 可以在逻辑上动态扮演 Eden、Survivor、Old 或 Humongous（巨型对象）等角色。 这个设计的优势是：GC 可以在每次停顿内选择一个合适规模的 Region 子集（Collection Set）， 从而更可预测地控制停顿时长。

3.1 三级 GC 与触发条件

G1 存在三个层级的 GC，它们的触发条件和停顿特征截然不同，工程师必须分清楚：

3.2 IHOP 与并发标记周期

G1 通过初始堆占用百分比（IHOP，Initiating Heap Occupancy Percent） 来决定何时启动并发标记周期。默认值为 45%，意味着当老年代占用超过堆的 45% 时， JVM 开始并发标记以评估哪些 Old Region 可以纳入下一轮 Mixed GC。 JDK 9 以后 G1 会自动调整 IHOP（Adaptive IHOP），但在对象分配速率变化大的场景下， 自动调整可能滞后，导致 Mixed GC 频率不足，老年代快速膨胀，最终触发 Full GC。 一个典型的错误配置模式是：将 -XX:MaxGCPauseMillis 设置得过于激进（比如 20ms）， 导致 G1 每次只能回收极少量 Old Region，老年代净增速超过回收速度， 一段时间后老年代膨胀至无法通过 Mixed GC 消化，退化为 Full GC。 这种现象的诊断特征是：短时间内大量 Mixed GC 后跟一次极长停顿的 Full GC。

-XX:G1HeapRegionSize 是另一个影响停顿的关键参数。Region 越大， Humongous 阈值（0.5×Region）越高，但每个 Region 的 RSet 条目也可能更多。 对于堆小于 8GB 的服务，通常不需要手动设置；超大堆场景推荐从 8MB 或 16MB 开始试验。

3.3 G1 与 ZGC 的失败窗口：机制层面的根本差异

所谓"失败窗口"，是指收集器在正常工作边界之外被迫退化的条件。 理解两者的失败窗口，比理解它们的正常工作流程更重要—— 因为线上事故几乎都发生在失败窗口附近。

G1 的失败窗口由两个相互叠加的压力触发：其一是老年代回收速度跟不上晋升速度。 Young GC 每次都会将 Eden 存活对象晋升到 Survivor 或 Old Region， 而 Mixed GC 的节奏受到并发标记周期的约束——并发标记必须先完成，才能评估哪些 Old Region 值得回收。 当流量突发导致对象晋升速率急剧上升，而 Mixed GC 节奏来不及跟上时， 老年代填满、Free Region 耗尽，疏散失败。 其二是 Remembered Set（RSet）的规模反噬：RSet 记录所有从 Old Region 到 Eden/Survivor 的跨代引用， 混合收集时必须完整扫描入选 Old Region 的 RSet。 当老年代对象间引用密度高时（例如大型缓存服务），RSet 条目数可达数千万， 单次 Mixed GC 的扫描时间随老年代规模线性增长，形成恶性循环： 停顿时间超过目标 → G1 减小下次 Collection Set → 老年代净回收量下降 → 下次压力更大。

ZGC 的失败窗口则完全不同，它的名称叫做Allocation Stall（分配停滞）。 由于 ZGC 的所有回收工作都是并发进行的，当应用线程的对象分配速率持续超过 GC 线程的并发回收速率时， 可用内存耗尽，应用线程被迫挂起等待 GC 腾出空间——这等价于一次不受控的 STW。 触发条件通常是：堆使用率长时间维持在 75% 以上， 或者流量突发（比如定时任务触发大量对象创建）超出了 GC 线程的追赶能力。 与 G1 不同，ZGC 不存在"RSet 越来越大"这类渐进式劣化，但在 Allocation Stall 发生的瞬间， 整个 JVM 的停顿时间可以与 G1 Full GC 相当，而且在日志中表现为 Allocation Stall，而非常规 GC 停顿，容易被监控遗漏。

两种失败窗口的应对策略差异同样根本：G1 的应对是"提前启动并发标记、增加 Reserve"， 即尽量在失败窗口到来之前完成老年代压缩；ZGC 的应对是"扩大堆或增加并发 GC 线程"， 即从源头扩大吞吐裕量。误用对方的应对手段——比如在 ZGC 上调 IHOP、 或在 G1 上增加 ConcGCThreads——对解决问题没有帮助，有时反而增加 CPU 开销。

4ZGC：染色指针与并发重定位的代价模型

ZGC（Z Garbage Collector）自 JDK 15 进入生产可用状态，其设计目标非常明确： 在任意堆大小下（从几百 MB 到数 TB），将 STW 停顿时间控制在 10ms 以内。 实践中，在堆大小 4GB–100GB 范围内，ZGC 的 STW 停顿通常在 1–5ms 区间， 远优于 G1 在同等堆大小下的 50–500ms 停顿。

4.1 染色指针：让指针携带 GC 元数据

ZGC 最核心的创新是染色指针（Colored Pointers）技术。 在 64 位地址空间中，实际的物理地址只需要 48 位（或更少）， ZGC 利用地址中的高位比特来存储 GC 元数据标志位（在 JDK 17 中使用 Marked0、Marked1、Remapped、Finalizable 四个标志位）。 当 GC 线程移动一个对象时，它不需要立刻更新所有指向该对象的引用—— 只需要在页表级别重新映射虚拟地址，并把引用中的标志位标记为"已重定位"。 下次应用线程访问这个"过期"引用时，读屏障（Load Barrier） 检测到标志位状态，触发修复（Barrier Slow Path），找到对象的新地址并更新引用。

这个机制的关键含义是：ZGC 的 STW 阶段只需要扫描 GC Roots（线程栈、静态变量、JNI 全局引用等）， 不需要扫描整个堆或 Remembered Set。GC Roots 的数量通常在数万到数十万的数量级， 与堆大小无关，这就是为什么 ZGC 的停顿时间对堆大小几乎不敏感的根本原因。

4.2 读屏障的代价

读屏障不是免费的。每次从堆中读取对象引用时，JIT 编译器生成的代码都需要 检查引用的颜色标志位，并在必要时走 Slow Path 修复引用。 在引用读操作频繁的工作负载（如遍历大型对象图、频繁访问集合元素）中， 读屏障的开销会积累为可观的 CPU 成本，表现为整体吞吐量下降 5–15%（合成基准数字， 实际场景差异很大，取决于读/写比例和对象图特征）。

这正是前面场景中，切换到 ZGC 后吞吐量下降 12%、平均延迟略微升高的原因—— 不是 ZGC 有 bug，而是这个服务的工作负载特征使读屏障开销比较显著。 对于读多写少、对象生命周期长的工作负载，ZGC 的读屏障代价更高； 对于对象分配速率高、短命对象多的服务，ZGC 的优势更明显。

4.3 分代 ZGC（JDK 21 实验特性）

非分代 ZGC 的主要缺点是：它不区分新生代和老年代，每次 GC 周期都需要处理整个堆， 在分配速率高的场景下内存回收效率较低，需要配置较大的预留内存（通常需要多配置 50%–100% 的堆内存以避免 OutOfMemory）。JDK 21 引入的 分代 ZGC（-XX:+UseZGC -XX:+ZGenerational） 通过引入新生代（Young Generation）和老年代（Old Generation）的概念， 让 ZGC 能更频繁地回收短命对象，在相同堆大小下显著提高内存利用率， 同时维持亚毫秒停顿的核心特性。

需要注意：分代 ZGC 在 JDK 21 中是实验性（Experimental）特性， 不建议在没有充分测试的情况下直接上生产。在 JDK 23+ 中其状态预计变为正式支持； 本文建议在 JDK 21 环境下进行充分的压测和 GC 日志分析后再决策。

5Shenandoah：Brooks 指针与并发压缩的另一条路径

Shenandoah GC 由 Red Hat 贡献给 OpenJDK，自 JDK 12 进入实验阶段，JDK 15 正式进入 OpenJDK 主线， Oracle JDK 中默认不包含（Oracle JDK 不发布 Shenandoah）。 它的设计目标与 ZGC 接近——亚毫秒级停顿——但采用了完全不同的技术路径。

5.1 Brooks 转发指针

Shenandoah 通过Brooks 指针实现并发疏散。每个对象头前有一个额外的 转发指针（Forwarding Pointer）字段，通常指向对象自身（正常状态）， 当对象被 GC 移动后，原地址的转发指针指向新地址。 应用线程和 GC 线程之间通过比较-交换（CAS）原语来协调对转发指针的修改。

与 ZGC 的读屏障不同，Shenandoah 使用写屏障（JDK 13 之前的 IU 模式还有读屏障） 来维护对象图的一致性。写屏障在每次写操作时检查目标地址是否被移动， 如果是则通过转发指针找到新地址再写入。每个对象额外消耗 8 字节（一个指针大小）的空间。

5.2 IU 模式（JDK 13+）

从 JDK 13 开始，Shenandoah 引入了 -XX:ShenandoahGCMode=iu（Incremental Update 模式， 现为默认），相比早期的 SATB 模式减少了读屏障，进一步降低了吞吐量损失。 IU 模式下 Shenandoah 的吞吐量损失与 ZGC 相近，但停顿时间略高于 ZGC， 因为 Final Mark（确定存活集合）阶段的工作量稍多。

5.3 与 ZGC 的主要差异

停顿数字为综合公开测试报告的合成参考值，非基准测试结论，实际值因工作负载、堆大小、硬件差异显著。

6七种高并发场景的 GC 选型矩阵

7GC 选型决策树：四个问题定位起点

决策树不代替压测，但它能帮助你快速排除明显不合适的选项， 把精力集中到真正值得实测的候选上。以下决策树基于上文的机制分析， 用四个关键问题完成初步过滤：

8调优实战：从 GC 日志到参数体系

GC 调优的正确顺序是：先观测，再分析，最后调参。 跳过观测直接改参数是导致调优失败的最常见原因—— 因为不同的停顿来源需要完全不同的应对手段，而这些来源在不打开足够日志的情况下是不可见的。

8.1 必开的 JVM 日志参数

JDK 9+ 的统一日志系统（-Xlog）取代了老的 -XX:+PrintGCDetails 等参数体系。 生产环境推荐的最小日志配置：

8.2 G1 核心调优参数体系

G1 的参数调优有一个优先级顺序：首先控制停顿目标 → 然后调整 IHOP 和 Mixed GC 频率 → 最后处理 Humongous 分配。三者顺序颠倒会导致治标不治本。

8.3 ZGC 核心参数

ZGC 的设计理念是"尽可能不需要手动调参"，大多数场景下只需要正确设置堆大小相关参数。

8.4 GC 日志的三个关键诊断信号

拿到 GC 日志后，按以下优先级检查三类信号，能快速定位 80% 以上的停顿异常：

• 信号 1：Evacuation Failure（G1） — 日志中出现 to-space exhausted 或 Evacuation Failure，意味着 Free Region 耗尽，G1 被迫停止疏散并升级为 Full GC。 短期应急：增大 G1ReservePercent；根治：降低 IHOP，增加堆大小，或减少 Humongous 分配。
• 信号 2：Safepoint 停顿异常 — safepoint.log 中 Application time 与 Total time for which application threads were stopped 的差值远大于实际 GC 工作时间，说明 TTSP 是主要停顿来源。排查方向： 长计数循环（JVM flag -XX:+UseCountedLoopSafepoints 在 JDK 11+ 已默认开启）、 JNI 调用、Object.wait() 前的偏向锁撤销。
• 信号 3：ZGC 并发失败（Allocation Stall） — ZGC 日志中出现 Allocation Stall，表示 GC 速度跟不上分配速率，应用线程被迫等待 GC 完成。 这通常意味着堆太小，或 ConcGCThreads 不足，需要扩大堆或增加并发线程。

8.5 复合场景数字对照：一次典型的低延迟服务调优路径

以下数字为合成示例（非真实单一案例，基于多个调优实践的典型值综合构造）， 仅用于说明调优路径上各阶段的量级变化关系，不代表任何特定服务的实测结论。 场景假设：某金融类 API 服务，堆 12GB，JDK 17，G1 默认配置，QPS 约 8000。

以上数据为合成示例，仅展示典型量级关系，非任何真实服务的基准测试结论。ZGC 吞吐损失在该假设场景较大，是因为该场景有大量对象读操作；不同业务特征下数字可能完全不同。

这个对照揭示了一个反直觉的结论：G1 调参后的 P999 延迟（280ms）虽然仍不理想， 但吞吐量几乎无损；而切换 ZGC 后虽然 P999 大幅改善，但吞吐下降 11% 在高 QPS 场景下 意味着需要额外扩容约 12% 的实例来维持同等处理能力，带来可观的成本增量。 这个权衡的正确答案取决于业务对 P999 延迟的实际 SLA 要求和可接受的成本预算—— 两者都合理，但必须是有意识的选择而非未经量化的直觉决定。

9五个让 GC 选型出错的认知陷阱

GC 选型领域存在若干根深蒂固的误判模式，在架构评审和调优讨论中反复出现。 逐一拆解这些陷阱，比介绍参数本身更有实际价值。

陷阱一：把"默认参数下的基准测试"当作生产参考

大多数网络上流传的"ZGC vs G1 对比测试"使用的是 SPECjbb 或 Renaissance 等合成基准， 或者是配置好的实验环境——这些场景的对象分配模式、引用密度、读写比例 与真实业务代码差异巨大。更重要的是，基准测试通常不反映内存压力下的行为（ 堆接近满时 GC 行为会显著变化）。在做选型决策前，务必用生产流量回放或真实压测， 在接近生产的堆配置和流量模式下运行至少 30 分钟以上再得出结论。

陷阱二：堆越大越好

增大堆可以减少 GC 频率，这在直觉上是正确的——但超过某个拐点后， 对于 G1 而言，更大的堆意味着更大的 Remembered Set 规模和更长的 Mixed GC 停顿； 对于 ZGC 而言，更大的堆意味着并发标记和重定位的工作量更大， 虽然不影响 STW 时间，但会增加并发 GC 的 CPU 持续占用，进而影响整体吞吐。 合理的堆大小通常是在 GC 频率不造成明显吞吐损失的前提下尽量小， 而非无限增大。

陷阱三：GC 停顿 = 服务延迟

GC 停顿只是服务延迟来源之一。在很多实际案例中，将服务从 G1 切换到 ZGC 后， P99 延迟的改善幅度远小于 GC 停顿的改善幅度——因为 P99 延迟还包含 线程调度延迟、TCP 缓冲区、数据库查询、外部 HTTP 调用等非 GC 因素。 如果 GC 停顿占 P99 延迟的比例低于 20%，换 GC 算法对 P99 的改善将非常有限， 优化性价比不高。量化 GC 停顿在总延迟中的占比，是做选型决策前的必要前置分析。

陷阱四：忽略 NUMA 架构对 GC 的影响

在高核数 NUMA（Non-Uniform Memory Access）服务器上，如果 JVM 没有开启 NUMA 感知 （-XX:+UseNUMA），GC 线程在跨 NUMA 节点扫描 Region 时会产生大量远端内存访问， 导致 GC 停顿时间大幅上升。这在 32 核以上的单机部署场景中尤为明显， 但容器化部署（通常绑核）和 cgroup CPU 限制环境下的影响可能较小。

陷阱五：把 ZGC/Shenandoah 视为"免维护"

低停顿收集器并不意味着不需要运维关注。ZGC 的 Allocation Stall、 Shenandoah 的 Degenerated GC 都是并发 GC 退化的信号， 一旦出现意味着 GC 速度已经无法追上分配速率，如果不及时处理（增大堆或降低分配速率）， 最终同样会触发 Full GC 或 OOM。低停顿收集器只是将"正常情况下的停顿"降低了， 并没有消除"极端情况下的停顿"。需要在 APM/Prometheus 中专门为这些退化信号配置告警。

10GC 选型沉淀：决策检查表与参考资料

10.1 GC 选型与上线前检查表

10.2 三个收集器的核心权衡一览

停顿、吞吐数字均为综合参考值，非基准测试结论，实际取决于工作负载、堆大小和硬件。

10.3 延伸阅读与参考资料

1. BOOK 周志明，《深入理解 Java 虚拟机（第3版）》，机械工业出版社，2019 —— 第3章（垃圾收集器与内存分配策略）是理解 G1/ZGC 机制的中文最佳起点； CMS 相关章节在 JDK 14+ 已过时，但对理解停顿根因仍有价值
2. DOC JDK 17 Garbage Collection Tuning Guide —— Oracle 官方，涵盖 G1/ZGC/Parallel/Serial 的参数详解与适用场景说明
3. DOC JDK 21 Garbage Collection Tuning Guide —— 新增分代 ZGC 相关章节，适合计划升级 JDK 21 的团队参考
4. DOC JEP 439: Generational ZGC —— 分代 ZGC 的设计动机、架构变化与已知限制；JDK 21 进入实验阶段的原始提案
5. DOC Shenandoah GC OpenJDK Wiki —— Shenandoah 官方文档，包含 IU 模式说明、参数指南和已知问题跟踪
6. PAPER Tene, G., Iyengar, B., Wolf, M. (2011). "C4: The Continuously Concurrent Compacting Collector." ACM SIGPLAN Notices, 46(11), 79–88 —— 理解无停顿 GC 的理论边界，对于深入理解 ZGC/Shenandoah 的并发疏散机制有重要参考价值
7. BLOG Per Lidén (ZGC 主要作者), inside.java: ZGC — The Z Garbage Collector —— ZGC 设计者对核心机制的权威解释，是理解染色指针和读屏障的第一手资料