线上Java服务频繁Full GC 我是这样一步步排查优化的

GC优化不是盲目调整参数，而是一场针对应用内存行为和业务特点的精准诊断。在一次线上事故中，某个Java后端服务每隔几分钟就出现Full GC，导致接口响应超时、用户体验急剧下降。通过系统化的排查流程——从GC日志分析到堆内存快照、再到参数调优——最终将Full GC频率从每5分钟一次降低到数小时一次，应用停顿时间缩减了90%以上。以下就是这次实践的完整记录。

现象：接口超时报警牵出Full GC频繁

首先明确一个结论：Full GC频繁的直接表现是应用频繁停顿，用户请求出现超时。这个服务负责核心订单处理，监控显示接口TP99从常规的200ms以内飙升至5秒以上，同时CPU使用率剧烈波动。查看GC日志发现，Full GC每5-7分钟触发一次，每次停顿时间在3-8秒之间。老年代空间占用在Full GC后仅下降20%左右，无法有效回收，说明有大量长期存活对象持续堆积。

排查：从GC日志到堆内存分析的完整链路

GC日志是排查GC问题的第一手证据，结合jstat和堆转储（heap dump）可以快速定位根源。在JVM启动参数中配置了以下日志输出：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc.log

通过jstat -gcutil [pid] 1s实时观察各个代的使用率，发现年轻代空间频繁占满，Eden区几乎每2-3秒就要触发Minor GC，但每次Minor GC后剩余存活对象比例偏高，大量对象明显进入老年代。进一步分析堆转储（使用jmap -dump:live,format=b,file=heap.bin）后，识别出占内存最大的对象类型是订单历史记录缓存，该缓存在业务高峰期承载了超过500MB的数据。

下表展示了优化前关键GC指标：

根因：新生代过小导致对象过早晋升

年轻代空间不足导致存活对象提前晋升老年代，这是触发Full GC的根本原因。该服务默认使用Parallel Scavenge收集器，最大堆内存为4GB，新生代默认只占1/3即约1.3GB。在并发量较高的时段，每秒创建大量订单对象，Eden区迅速占满，Minor GC频繁触发。由于订单处理过程中需要短暂缓存对象（如数据库连接、中间结果），部分对象在Minor GC时仍然存活，却被过早移入老年代。老年代自身容量有限（约2.7GB），且订单历史缓存在业务高峰期会快速填满老年代空间，最终导致Full GC爆发。

优化：调整堆大小并更换为G1垃圾收集器

根据应用特点，增大堆内存至8GB并启用G1 GC，同时调大新生代比例、优化缓存策略。具体参数调整如下：

-Xms8g -Xmx8g -XX:+UseG1GC -XX:NewRatio=2 -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=16m

选择G1 GC代替Parallel Scavenge的原因在于：G1能够更精细地控制停顿时间，适合需要低延迟的在线服务。同时将新生代比例从默认的1/3调整为1/2（通过-XX:NewRatio=2），给年轻代多分配空间，减少Minor GC频率和对象晋升概率。此外，对订单历史缓存增加了过期时间（TTL=5分钟）和容量上限（200MB），避免缓存无限膨胀。这些措施协同作用，从源头上减少了老年代的填充速度。

下表对比了不同垃圾收集器在该场景下的适用性：

验证：优化后的效果与监控指标

优化后Full GC频率从每5分钟一次降至每6小时一次，接口TP99恢复至正常水平。线上稳定运行两周后，关键指标改善如下：

需要注意的是，GC优化没有一劳永逸的方案。业务流量波动、代码变更都可能打破原有的平衡。应当建立常态化的GC监控机制，定期分析GC日志，并结合压测验证参数效果。这次实践印证了一个核心观点：GC优化的本质是理解应用的内存行为特征，然后选择匹配的收集器与参数组合。盲目拷贝网上配置往往适得其反。