JVM 的 G1 和 ZGC 有什么区别？低延迟服务应该怎么选垃圾收集器？

知识点详解：把暂停减少以后，回收工作去了哪里？

G1 的区域与暂停目标，解决什么问题？

咱们假设服务不断创建短生命周期对象，同时保留一部分长期对象。

G1 用多个 region 组织堆，这些区域可以承担不同代的角色。它会根据存活信息和回收成本等安排收集工作，不必把“年轻代、老年代”理解成始终固定大小的连续空间。

但是区域化不等于所有回收都在后台完成。G1 的年轻代和混合收集中，疏散存活对象等重要工作需要暂停应用；并发标记则能在应用运行时执行。资源或回收进度不足时，还可能遇到其他更昂贵的处理。

因此，MaxGCPauseMillis 是目标，不是保证。把目标从 200 改成 20，也不会让收集器凭空拥有十倍资源。它可能调整工作安排，但结果仍取决于对象分配、存活和机器条件。

ZGC 为什么能把更多工作放到并发阶段？

移动对象时，应用还可能通过旧引用访问对象。ZGC 通过屏障等机制，让应用与并发标记、重定位协调，尽量把耗时工作放到与应用同时进行的阶段。

这不等于它没有暂停。只是在设计上尽量减少停顿对堆大小和存活对象规模的依赖。具体性能仍需要测试，不能把一个宣传数字当成所有机器上的最大停顿保证。

工作从暂停移到并发阶段，也不是消失了。回收线程要使用 CPU，相关机制有开销，还需要足够空间让应用在回收完成前继续分配。如果分配速度超过回收能力，应用仍可能因为缺少可用空间而等待。

为什么要先说明 JDK 版本？

ZGC 已经经历过非分代与分代实现的变化。JDK 24 移除了非分代 ZGC；本文以 JDK 25 为基线，不再把“ZGC 不分代”作为特点。

G1、ZGC 的实现与默认配置也会随 JDK 演进。比较前要记下 JDK 发行版、版本、GC 参数、CPU 与内存限制；否则一边是旧版实现，一边是新版实现，结果没有说明你比较的是哪个条件。

机制依据 Java 25 GC 文档，非分代 ZGC 的移除也可对照 OpenJDK 的版本讨论记录。

低延迟服务，应该怎样比较？

先定义需求。例如，请求 P99 不能超过某个业务阈值，在此基础上还需要多少吞吐、允许用多少 CPU 和内存。这个阈值应来自项目，不使用本文虚构的压测数字。

然后在同一负载模型和资源额度下比较，既观察 GC 暂停，也看请求分位延迟、吞吐、CPU、进程内存、分配速率和回收日志。

如果 GC 暂停已经很小，但数据库等待占了大部分时间，换 GC 不一定改善用户体验。如果并发回收增加了 CPU 竞争，在资源紧张的容器里，也可能影响请求处理。

最后还要覆盖稳定负载、突发分配和接近容量的阶段，而不是只跑一个很短的小测试。对比测试验证的是这个负载与配置，不代表一方永远胜出。

面试官继续追问

ZGC 会不会消除内存泄漏？

不会。应用仍然引用的对象不能因为换收集器就被当成垃圾。泄漏与工作集超容量仍需要排查。

G1 不适合低延迟吗？

不能这样说。需求的严格程度、堆、存活对象和资源决定它能否满足。很多服务在合理配置下使用 G1 已经达到目标，不需要为了“更新”迁移。

面试速记卡

• G1：区域化组织，部分工作并发，疏散等阶段仍需暂停。
• ZGC：更多回收工作与应用并发，重点减少暂停，但不是零暂停。
• 版本：本文 JDK 25，不能再背 ZGC 不分代。
• 代价：并发回收使用 CPU，并需要内存余量。
• 选型：同负载、同资源比较业务延迟和吞吐，不只看 GC 数字。