在 Java 后台服务中高堆内存占用是比较常见的情况。例如缓存服务、数据同步服务、规则引擎、报表计算服务、订单聚合服务等通常都会在 JVM 堆中保存大量业务对象。当堆内存设置到 16GB、32GB甚至更高时如果老年代对象长期较多GC 停顿就可能成为影响系统稳定性的关键因素。尤其是服务既要处理后台任务又要提供在线接口时GC 停顿很容易造成响应时间抖动。在这类场景下G1 和 ZGC 应该如何选择本文结合高堆内存占用场景对两者的特点和适用情况做一个简要对比。一、高堆内存服务为什么容易出现 GC 问题高堆内存服务通常有以下特点本地缓存数据较多Map、List、Set 等集合对象较多部分对象生命周期较长老年代占用长期较高批处理任务可能一次性加载大量数据。例如一个 Java 服务设置了 16GB 堆内存-Xms16g -Xmx16g服务运行一段时间后堆内存长期保持在 70% 到 85%。这时如果使用 G1可能会出现 Mixed GC 停顿变长的问题。对于纯后台任务来说短时间停顿可能影响不明显但如果服务还承担在线查询、实时同步或任务调度接口GC 停顿就可能直接带来响应时间抖动。所以高堆内存场景下的 GC 优化重点不只是“减少 GC 次数”而是要控制每次 GC 对业务线程的影响。二、G1更适合大多数通用 Java 服务G1 是目前 Java 服务中非常常用的垃圾收集器。它在吞吐量和停顿时间之间做了相对均衡的设计适合大多数后台服务和中大堆场景。G1 的优势主要有成熟稳定线上使用案例多吞吐表现较好适合大多数普通 Java 服务可以通过参数控制目标停顿时间对批处理、后台任务、普通接口服务都比较友好。G1 配置示例java -Xms16g -Xmx16g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis100 \ -XX:G1HeapRegionSize16m \ -XX:InitiatingHeapOccupancyPercent35 \ -XX:G1ReservePercent20 \ -Xlog:gc*:filegc.log:time,uptime,level,tags \ -jar high-heap-service.jarG1 参数说明1.-XX:UseG1GC启用 G1 垃圾收集器。G1 是比较通用的垃圾收集器适合大多数 Java 后台服务。对于高堆内存服务来说通常可以先从 G1 调优开始而不是一开始就切换到 ZGC。2.-XX:MaxGCPauseMillis100设置 G1 的目标停顿时间。需要注意的是这个参数不是硬性保证而是 JVM 的调优目标。G1 会尽量按照这个目标控制 GC 停顿但实际停顿时间仍然会受到堆大小、对象存活率、老年代占用和对象引用关系的影响。这个值不建议设置得过低。比如设置成10ms可能会导致 GC 过于频繁吞吐量下降如果设置得过高比如200ms单次停顿可能较长接口延迟毛刺会更明显。在高堆内存服务中可以从100ms开始评估。如果业务对延迟更加敏感也可以结合压测情况再调整。3.-XX:G1HeapRegionSize16m设置 G1 Region 的大小。G1 会把堆划分成多个 Region然后按 Region 进行回收和管理。Region 太小数量会变多管理成本会上升Region 太大回收粒度会变粗可能影响回收灵活性。以 16GB 堆为例16m是一个比较常见的取值。它能在 Region 数量和管理成本之间取得相对平衡。如果 Region 设置过小比如1mRegion 数量会非常多管理开销会增加。如果 Region 设置过大比如32m回收粒度会变粗大对象和内存碎片问题可能更明显。4.-XX:InitiatingHeapOccupancyPercent35设置 G1 触发并发标记的堆占用阈值。这个参数决定了老年代占用达到一定比例后G1 什么时候开始并发标记。设置得低一些G1 会更早开始标记GC 可能更频繁但每次回收压力相对较小设置得高一些GC 触发次数可能减少但每次回收压力更大停顿也可能更长。例如设置较低如30%GC 更早触发回收更及时但频率可能增加设置较高如70%GC 触发较晚次数可能减少但容易导致单次回收压力变大设置为35%适合高堆占用场景下让 G1 更早开始老年代回收准备。对于高堆内存、高老年代占用的服务适当降低这个值可以减少 Mixed GC 压力。5.-XX:G1ReservePercent20设置 G1 预留空间比例。这个参数用于给对象晋升和复制预留一部分空间降低 evacuation failure 或晋升失败的风险。在高堆内存服务中如果对象存活率较高、老年代占用较高适当提高预留空间会更稳妥。缺点是可用堆空间会相应减少所以也需要结合实际内存使用情况评估。6.-Xlog:gc*:filegc.log:time,uptime,level,tags开启 GC 日志。GC 调优不能只凭感觉需要通过 GC 日志观察 Young GC、Mixed GC、Full GC、堆使用变化和停顿时间。只有确认问题确实来自 GC后续调优才有意义。三、ZGC更适合大堆低停顿场景ZGC 是面向低延迟场景设计的垃圾收集器。它的核心思路是尽量把 GC 的主要工作放到并发阶段执行从而减少应用线程被暂停的时间。ZGC 的优势主要有停顿时间更短更适合大堆内存场景对接口响应稳定性更友好可以减少高堆场景下的长时间 STW更适合对延迟敏感的在线服务。ZGC 配置示例java -Xms16g -Xmx16g \ -XX:UseZGC \ -XX:ZGenerational \ -XX:SoftMaxHeapSize14g \ -XX:ConcGCThreads6 \ -Xlog:gc*:filegc-zgc.log:time,uptime,level,tags \ -jar high-heap-service.jarZGC 参数说明1.-XX:UseZGC启用 ZGC 垃圾收集器。ZGC 更适合大堆内存、低停顿场景。它会尽量把标记、整理、重定位等工作放到并发阶段执行从而减少 Stop-The-World 对业务线程的影响。2.-XX:ZGenerational启用分代 ZGC。分代 ZGC 是 JDK 21 引入的重要特性。开启后ZGC 会按照年轻代和老年代的思路管理对象更适合大多数 Java 服务中“短生命周期对象较多同时又存在长期存活对象”的情况。对于高堆内存服务来说分代 ZGC 通常更值得优先评估。需要注意的是JDK 21 之前没有这个选项。如果使用较低版本 JDK需要先确认当前版本是否支持分代 ZGC。3.-XX:SoftMaxHeapSize14g设置 ZGC 的软堆上限。SoftMaxHeapSize不是最大堆限制真正的最大堆仍然由-Xmx16g决定。它表示 ZGC 会尽量把堆使用控制在这个值附近但在必要时仍然可以使用到-Xmx指定的最大堆。例如这里设置-Xmx16g -XX:SoftMaxHeapSize14g意思是最大堆为 16GB但 ZGC 会尽量把堆使用控制在 14GB 左右。这个参数适合用来给服务预留一定内存缓冲。实际设置时不建议把它设置得过于接近物理内存或容器内存上限需要给 JVM 堆外内存、线程栈、Metaspace、直接内存以及 GC 相关开销留出空间。如果没有明确经验可以先将软上限设置为最大堆的 70% 到 85% 区间再结合压测和线上监控调整。4.-XX:ConcGCThreads6设置 ZGC 并发 GC 线程数。ZGC 的很多 GC 工作会并发执行因此并发 GC 线程数会影响回收速度和业务线程资源竞争。这个值不是越大越好。设置太小可能导致 GC 跟不上对象分配速度设置太大又可能抢占业务线程 CPU影响正常请求处理。通常可以根据机器 CPU 核数和业务负载进行调整。对于 CPU 资源紧张的服务需要避免 GC 线程占用过多计算资源。可以先使用默认值再结合 CPU 使用率、GC 频率和响应时间做调整。5.-Xlog:gc*:filegc-zgc.log:time,uptime,level,tags开启 ZGC 日志。切换 ZGC 后需要持续观察 GC 停顿、并发阶段耗时、堆使用率、CPU 使用率和接口响应时间。不要只看服务能否启动成功而要通过压测和灰度验证 ZGC 是否真正改善了业务表现。四、G1 与 ZGC 对比对比项G1ZGC定位通用型垃圾收集器低延迟垃圾收集器适用场景大多数 Java 服务高堆内存、低停顿服务堆内存场景中大堆常用大堆更有优势停顿时间可能出现几十到几百毫秒通常更低吞吐表现较好可能略有损耗CPU 开销相对较低可能略高内存开销相对较低可能略高调优复杂度参数较多相对简单推荐场景普通后台服务、批处理服务在线接口、实时任务、大堆低停顿服务可以简单理解为G1 更偏通用和稳定ZGC 更偏低延迟和大堆停顿控制。五、什么时候继续使用 G1如果服务符合以下情况优先继续使用 G1GC 停顿在业务可接受范围内服务更关注整体吞吐量主要是离线任务或批处理任务CPU 资源比较紧张没有明显的接口响应抖动G1 调优后已经满足业务要求。对于大多数普通后台服务来说G1 已经足够。通过合理调整目标停顿时间、并发标记启动时机、Region 大小和预留空间通常可以缓解大部分 GC 停顿问题。六、什么时候考虑 ZGC如果服务符合以下情况可以考虑评估 ZGC堆内存较大比如 16GB、32GB 或更高堆使用率长期较高老年代对象较多G1 Mixed GC 停顿超过业务可接受范围服务同时提供在线接口对响应时间稳定性要求较高可以接受一定 CPU 或内存开销。ZGC 更适合解决“大堆内存下 GC 停顿明显”的问题。如果业务目标是减少接口响应抖动而不是单纯追求最高吞吐量那么 ZGC 更值得评估。七、不要把 GC 切换当成唯一解法无论使用 G1 还是 ZGC都不能忽略内存本身的问题。如果堆内存长期处于高水位还需要重点排查缓存是否设置了容量上限缓存是否有过期策略是否存在大对象长期不释放Map、List 是否只增不减ThreadLocal 是否及时清理是否存在内存泄漏批处理是否一次加载过多数据。如果业务代码存在内存泄漏切换 ZGC 只能缓解停顿并不能解决堆内存持续上涨的问题。因此正确的优化顺序应该是先治理内存结构再考虑 GC 调优和垃圾收集器切换。八、推荐优化流程高堆内存服务出现 GC 停顿时可以按照下面的顺序处理开启 GC 日志确认停顿是否来自 GC分析堆内存结构排查缓存、大对象和集合对象优化业务代码减少不必要的对象占用先尝试 G1 调优如果 G1 仍然停顿明显再评估 ZGC通过压测和灰度验证后再逐步上线。这个流程的好处是比较稳妥不会一开始就把问题归因到垃圾收集器也能避免因为盲目切换 GC 带来新的 CPU 或内存压力。九、总结G1 和 ZGC 没有绝对的优劣关键在于业务场景。G1 更适合大多数通用 Java 服务优势是成熟、稳定、吞吐表现较好。ZGC 更适合高堆内存、低停顿要求的服务优势是可以明显降低 GC 对业务线程的影响。如果服务是普通后台任务且 GC 停顿在可接受范围内G1 通常已经足够。如果服务堆内存很大同时又对接口响应稳定性有较高要求可以考虑评估 ZGC。普通服务优先 G1高堆内存、低停顿场景评估 ZGC先治理内存再考虑更换垃圾收集器。