2026 年垃圾回收器抉择：ZGC 真的全面碾压 G1 吗？

几年前，我们在面试时还在背诵 CMS 和 G1 的区别。到了 2026 年，讨论的焦点已经彻底变成了：“我的微服务到底该用 G1，还是直接切到 ZGC？”

自从 Java 21 补齐了 ZGC 的最后一块短板——分代收集（Generational ZGC），它似乎成了完美的化身：无论是分配多大的堆（哪怕是 16TB），GC 停顿时间都能稳定控制在亚毫秒级（< 1ms）。

很多架构师看完发布会，转身就在生产服务器上把 -XX:+UseG1GC 换成了 -XX:+UseZGC -XX:+ZGenerational。

结果第二天，运维团队报警：服务器 CPU 占用率飙升，业务系统虽然没有长停顿了，但总体的 QPS（吞吐量）竟然下降了 10%！

这是为什么？

1. 吞吐量 (Throughput) vs 延迟 (Latency) 的零和博弈

垃圾回收器不可能打破物理学定律。ZGC 能做到亚毫秒停顿的核心代价是：它把本该在 STW（Stop The World）里做的事情，挪到了和你的业务线程一起并发执行。

G1 在进行 Mixed GC 时，会暂停所有业务线程（通常几十到几百毫秒）。在这期间，GC 线程独占所有的 CPU 资源，高效地清理垃圾。由于清理得很彻底，业务线程恢复后可以跑得飞快。

ZGC 采用了染色指针（Colored Pointers）和读屏障（Load Barriers）技术。当你的业务线程试图读取一个正在被 ZGC 转移位置的存活对象时，读屏障会触发，业务线程不仅要等，甚至还要“顺手”帮 ZGC 完成对象地址的修复工作。

这意味着，ZGC 在运行期间会持续**“偷走”**业务系统的 CPU 算力。

在 2026 年的现代 Java 架构中，没有绝对的好坏，只有场景的适配。以下是经过实战检验的选型指南。

CPU 资源吃紧：如果你是部署在 2 核 4G 这种丐版容器里，千万别用 ZGC。ZGC 的并发线程会直接把 CPU 榨干，导致业务线程饥饿。
重度批处理 / 大数据处理：比如你写了一个跑在凌晨 2 点的 Spring Batch 定时任务，或者做账单结算。没人关心它停顿了 2 秒还是 3 秒，只关心它能不能早点跑完。G1 的极致吞吐量完胜。
小内存堆 (< 8GB)：如果你的堆内存本来就很小，G1 的停顿本来就只有十几毫秒。强行上 ZGC 就是徒增 CPU 开销。

核心在线交易/网关服务：如果你的 API 耗时 P99 指标被严格要求在 50ms 以内。G1 偶尔一次 200ms 的停顿会导致上游出现断崖式超时。这时候，ZGC 的亚毫秒停顿是救命稻草。
超大内存堆 (32GB ~ 1TB+)：当你把 Elasticsearch 或是本地的巨大 JVM 缓存节点丢在 64G 内存的机器上时。G1 一次 Full GC 能让你怀疑人生（卡顿好几秒）。对于 ZGC 来说，扫 1TB 和扫 1GB 的停顿时间几乎是一样的。
交互式应用/游戏服务器：对掉帧极其敏感的场景，ZGC 是无可替代的神。

不同于以前繁琐的参数配置，分代 ZGC 最大的特点就是“自适应”。一般情况下你只需要设置两个参数：

# 开启分代 ZGC (Java 21+)
-XX:+UseZGC -XX:+ZGenerational
# 设置最大和最小堆内存，强烈建议设为一样大，避免运行时扩容引发抖动
-Xms16G -Xmx16G

但如果你发现开启后依然有性能问题，你需要关注这个最关键的参数： 并发 GC 线程数 (-XX:ConcGCThreads)

ZGC 默认会使用机器总逻辑核心数的大约 1/4 作为并发垃圾收集线程。如果你发现它抢占了太多业务 CPU，可以适当调低：

# 限制 ZGC 只能用 2 个核在后台悄悄扫垃圾
-XX:ConcGCThreads=2

在评估 2026 年的技术栈时，不要被跑分数据蒙蔽双眼。 G1 是一台皮卡，粗糙但极其能拉货（吞吐量）；ZGC 是一辆超跑，平顺、极速，但极其吃油（吃 CPU）。作为架构师，给对应的业务分配正确的车型，才是你最核心的价值。