登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  java教程

G1 与 ZGC 选择不只看停顿:吞吐和内存余量怎么算

来源:17golang原创

时间:2026-10-08 10:59:57 446浏览 收藏

G1 和 ZGC 的选择,先别从“谁的暂停更短”开始。生产决策应先写出三个约束:请求允许的停顿分位数、应用可接受的 GC 时间占比,以及容器给 JVM 留出的总内存。G1 通常适合希望在吞吐和停顿之间取得均衡的服务;ZGC 适合响应时间优先、需要把停顿压到很低的服务,但并发回收会消耗更多处理资源。最终选型必须用同一份业务负载压测确认。

要点速览
  • 先按存活集、分配尖峰和非堆开销估算 Xmx,不要把容器内存全部交给 Java 堆。
  • G1 的默认目标是较均匀的短暂停顿和较高吞吐,ZGC 更偏低延迟,不能直接拿单次暂停比较。
  • 用相同流量、相同 Xmx、相同日志字段比较 p99 停顿、GC 时间占比、CPU 和堆水位,再灰度上线。

先把“快”拆成停顿、吞吐和内存余量

停顿是应用线程被暂停的时间,吞吐则是应用真正运行时间占总时间的比例。Oracle 的调优指南把 -XX:GCTimeRatio=N 定义为 GC 时间与应用时间的目标比例 1/(1+N);例如 N=19 对应约 5% 的 GC 时间目标。这个数字是方向,不是压测结果。

内存预算也不能只看 -Xmx。可以先用下面的工程估算式:Xmx ≈ 峰值存活集 × (1+尖峰余量)+直接内存+类元数据与线程栈之外的堆内保留。再从容器限制中减去 metaspace、线程栈、Code Cache、JNI/直接内存和操作系统余量。比如存活集峰值约 3.2 GiB、短时分配波动按 50% 估算时,8 GiB 堆只是压测起点,不代表上线一定要给 8 GiB。

G1 与 ZGC 的取舍落在什么地方

G1 将堆拆成区域,部分工作与应用并发执行,并通过暂停目标安排回收集合。它是多数服务器配置下的默认收集器,适合希望获得相对均匀暂停、同时保留较好吞吐的服务。调优时不要轻易用 -Xmn 把年轻代钉死,因为这会削弱 G1 依据暂停目标调整年轻代的空间。

ZGC 的设计重点是低延迟,官方文档说明其暂停时间基本不随堆大小变化,但代价是并发阶段需要占用 CPU;在内存紧张或 CPU 已经饱和的服务里,低停顿不一定换来更高的业务吞吐。Java 25 的 ZGC 还支持把暂时不用的堆内存归还给系统,-XX:+ZUncommit 默认开启,但频繁提交和归还也有成本。

G1 与 ZGC 在停顿、吞吐、CPU 和内存余量之间的静态取舍结构说明图
图1:G1 与 ZGC 的取舍结构说明图,展示停顿、吞吐、CPU 与内存余量之间的关系,不是运行截图。

用同一套参数启动两组可比的压测

先固定堆上下限,避免收集器通过不同的扩缩容路径制造假差异;再只切换收集器。日志使用统一的 GC 标签,便于按请求压测窗口聚合。下面是示例启动方式,注释解释的是参数意图,不代表某个业务的最终值:

# G1:先给出固定堆和暂停目标,观察均衡点
java -Xms8g -Xmx8g -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -Xlog:gc*,safepoint:file=gc-g1.log:time,uptime,level,tags:filecount=3,filesize=50m \
  -jar service.jar

# ZGC:保持相同堆预算,只切换收集器并记录相同维度
java -Xms8g -Xmx8g -XX:+UseZGC \
  -Xlog:gc*,safepoint:file=gc-zgc.log:time,uptime,level,tags:filecount=3,filesize=50m \
  -jar service.jar

压测时至少记录业务吞吐、请求 p99/p999、GC 暂停分位数、进程 CPU、堆已用峰值和容器 RSS。G1 如果频繁出现长时间回收,先检查堆是否太小、存活数据是否过高;ZGC 如果暂停很好但 CPU 或业务吞吐恶化,就要重新核对并发 GC 的资源成本。两边都出现内存逼近上限时,先扩大可用余量或降低分配速率,不要只换收集器。

把结果转成上线决策和回退条件

展示从压测观察项到灰度选择与回退条件的关系
图2:GC 压测结果到上线决策的关系说明图,不是截图或运行证据。

可以把决策写成三段:若 G1 已满足 p99 停顿和吞吐目标,优先保留 G1;若 G1 的暂停尾部无法接受且 CPU 仍有余量,才用 ZGC 做小流量验证;若 ZGC 让 CPU、RSS 或业务吞吐越过预算,回到 G1 并优化对象分配、缓存大小或堆上限。每次只改变一个变量,至少覆盖业务高峰、分配尖峰和长时间稳定运行三个窗口。

观察结果优先动作不要先做
G1 停顿可接受,吞吐稳定保留默认策略,固定 Xmx 并灰度为了“更现代”切换 ZGC
G1 尾部停顿超预算,CPU 有余量用同堆预算压测 ZGC只看一次 Full GC 就下结论
两者都让 RSS 接近容器上限重算非堆和系统余量把 -Xmx 直接调到容器限制

常见问题

堆越大,G1 和 ZGC 就一定越快吗?

不一定。更大的堆可能减少回收频率,但会增加内存占用;G1 还要承担区域管理和并发标记成本。必须结合分配速率、存活集和 CPU 看。

能不能只用 MaxGCPauseMillis 选 G1?

不能。它是暂停目标提示,不是保证值,而且放宽暂停目标可能提升吞吐;最终仍要看真实业务的尾延迟和 GC 时间占比。

ZGC 适合所有大堆服务吗?

不适合。大堆、低延迟只是候选条件,若服务 CPU 紧张或 RSS 余量不足,ZGC 的并发成本可能让总体结果更差。

参考资料:https://docs.oracle.com/en/java/javase/25/gctuning/available-collectors.html、https://docs.oracle.com/en/java/javase/25/gctuning/ergonomics.html、https://docs.oracle.com/en/java/javase/25/gctuning/garbage-first-g1-garbage-collector1.html。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>