JVM垃圾回收是保障内存合理使用的核心机制，但不当的GC配置或内存分配策略很容易导致应用吞吐量下降，影响业务响应效率。很多开发者遇到这类问题时不知道从何入手分析，也不清楚如何量化GC对性能的影响程度。
GC停顿时间占比的计算方式
GC停顿时间占比是衡量GC对吞吐量影响的核心指标，它反映了应用在运行过程中，有多少时间被GC停顿占用，计算逻辑非常清晰：
GC停顿时间占比 = 统计周期内GC总停顿时间 / 统计周期总时长 * 100%
比如应用运行了1小时（3600秒），这段时间内所有GC停顿的总时长是180秒，那么GC停顿时间占比就是180/3600*100%=5%，意味着有5%的时间应用无法处理业务请求，吞吐量自然会受到对应比例的影响。
要获取准确的GC停顿时间数据，首先需要开启JVM的GC日志输出，常用的日志开启参数如下：
# JDK8及之前版本 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log # JDK9及之后版本 -Xlog:gc*:file=/path/to/gc.log:time,level,tags
拿到GC日志后，我们可以通过脚本或者工具统计指定周期内的GC停顿总时长，这里以JDK8的GC日志为例，展示一段典型的GC日志内容：
2024-05-20T10:12:34.567+0800: 12.345: [GC (Allocation Failure) [PSYoungGen: 51200K->5120K(59392K)] 51200K->15360K(194560K), 0.0234567 secs] [Times: user=0.04 sys=0.01, real=0.02 secs] 2024-05-20T10:12:45.678+0800: 23.456: [Full GC (Ergonomics) [PSYoungGen: 5120K->0K(59392K)] [ParOldGen: 10240K->8192K(135168K)] 15360K->8192K(194560K), [Metaspace: 3072K->3072K(1056768K)], 0.1234567 secs] [Times: user=0.45 sys=0.02, real=0.12 secs]
日志中real=0.02 secs和real=0.12 secs就是对应GC事件的停顿时间，我们可以把统计周期内所有GC事件的real时间相加，得到GC总停顿时间，再结合统计周期的起始和结束时间计算总时长，就能得到准确的GC停顿时间占比。
GC导致吞吐量下降的常见原因分析
当GC停顿时间占比超过1%（对延迟敏感的应用甚至要求低于0.5%）时，就需要分析具体原因，常见的诱因主要有以下几类：
- 堆内存分配不合理：新生代过小会导致Minor GC频率过高，老年代过小会频繁触发Full GC，都会增加总停顿时间。
- 垃圾回收器选择不匹配：比如给低延迟的Web应用使用Parallel Scavenge+Parallel Old组合，其追求高吞吐量的设计会导致停顿时间偏长。
- 对象分配速率过高：短时间内大量创建短生命周期对象，会快速占满新生代，触发频繁的Minor GC。
- 内存泄漏：长生命周期对象无法被回收，逐渐占满老年代，最终导致频繁的Full GC甚至OOM。
- GC参数配置不当：比如晋升阈值设置过低，导致大量短生命周期对象提前进入老年代，增加老年代GC压力。
GC调优的核心思路
第一步：明确调优目标
调优前首先要明确核心目标，不同业务场景的目标差异很大：
- 如果是后台计算类应用，优先追求高吞吐量，可接受较长的停顿时间，GC停顿时间占比可以放宽到5%以内。
- 如果是电商、支付类延迟敏感应用，优先追求低延迟，GC停顿时间占比最好控制在0.5%以内，单次GC停顿不超过100ms。
第二步：基于日志定位问题
通过GC日志先确认当前的GC停顿时间占比，再分析GC的类型和频率：
- 如果Minor GC频率过高（比如每秒超过1次），说明新生代空间不足，或者对象分配速率过高。
- 如果Full GC频率过高（比如每分钟超过1次），需要排查老年代内存是否不足，或者是否存在内存泄漏。
- 如果单次GC停顿时间过长，需要考虑更换低延迟的垃圾回收器，比如G1、ZGC等。
第三步：针对性调整参数
根据定位到的问题调整对应的JVM参数，以下是不同场景的常用调整方案：
| 问题场景 | 调整方案 | 示例参数 |
|---|---|---|
| Minor GC频率过高 | 增大新生代空间 | -Xmn2g（设置新生代大小为2G） |
| Full GC频率过高 | 增大老年代空间，排查内存泄漏 | -Xmx4g -Xms4g（设置堆初始和最大为4G，避免堆动态扩容） |
| 单次GC停顿过长 | 更换低延迟垃圾回收器 | -XX:+UseG1GC（使用G1回收器） |
| 对象提前晋升老年代 | 调整晋升阈值 | -XX:MaxTenuringThreshold=15（设置对象年龄到15才晋升） |
第四步：验证调优效果
调整参数后需要重新运行应用，收集新的GC日志，重新计算GC停顿时间占比，确认是否达到预期目标。如果未达到，需要重复上述分析调整流程，直到满足业务需求。
常见垃圾回收器的调优建议
G1垃圾回收器
G1是目前服务端应用最常用的垃圾回收器，适合堆内存大于4G的场景，核心调优参数如下：
# 设置最大停顿时间目标，默认200ms，可根据需求调整 -XX:MaxGCPauseMillis=100 # 设置G1的堆区域大小，默认根据堆大小自动计算，可选设置 -XX:G1HeapRegionSize=4m # 设置并发标记周期启动的堆占用阈值，默认45% -XX:InitiatingHeapOccupancyPercent=45
ZGC垃圾回收器
ZGC是JDK11之后推出的低延迟回收器，停顿时间不会随着堆大小增加而增长，适合超大堆、低延迟的场景，核心参数如下：
# 启用ZGC -XX:+UseZGC # 设置最大停顿时间，默认不超过10ms -XX:ZCollectionInterval=5 # 设置堆内存大小 -Xmx16g -Xms16g
总结
分析JVM垃圾回收带来的吞吐量下降，核心是先通过GC日志计算出准确的GC停顿时间占比，量化GC对性能的影响程度。之后结合GC类型、频率、停顿时长定位具体原因，再针对性调整堆内存、垃圾回收器、GC参数，最后验证调优效果。整个过程中需要结合业务场景的吞吐量和延迟需求，避免盲目追求某一指标而忽略业务实际要求。