Java垃圾回收Full GC频繁触发导致应用雪崩的排查

前置说明：本文以排查一个实际线上Java应用因频繁Full GC导致请求卡顿、最终服务不可用的“雪崩”场景为例。排查过程基于JDK 8及JDK 11，工具以命令行为主，确保在服务器环境中可直接操作。

第一阶段：监控确认，锁定问题

当应用响应变慢或告警响起，首先需要确认是否是GC问题。

1. 查看 GC 日志。
   应用启动时应添加GC日志参数。如果没有，检查 /var/log/、/tmp/ 或应用日志目录，寻找形如 gc.log、gc.log.current 的文件。如果日志路径未知，使用 命令 jinfo -flags <pid> 查看 JVM 启动参数，其中 -Xloggc: 参数指明了日志路径。
   快速分析 日志内容，搜索 关键字 Full GC。关注以下信息：

   • 触发频率：间隔是否极短（如每秒或每几秒一次）。
   • 触发原因：紧跟着 Full GC 的括号内文字，常见的有 Metadata GC Threshold、Ergonomics、Allocation Failure、System.gc()。
   • 耗时：(pause) 后的时间，频繁的Full GC通常伴随数百毫秒到数秒的停顿。
   • 回收效果：Heap 后的数字变化。如果Full GC后老年代占用依然很高，说明回收效果差。

2. 实时监控 GC 状态。
   使用 JDK 自带的 jstat 命令。

   # 每2000毫秒打印一次GC统计，共打印10次
   jstat -gcutil <pid> 2000 10

   重点观察以下列：

   • FGC：Full GC 次数。观察其是否在持续快速增加。
   • FGCT：Full GC 总耗时。计算 (最新FGCT - 上一次FGCT) / (最新FGC - 上一次FGC) 得到平均单次Full GC耗时。
   • O 列：老年代(Ol Old)使用占比。如果此值持续在90%以上甚至接近100%，则基本确认是老年代空间不足引发的Full GC。
   • M 列：元空间(Metaspace)使用占比。如果此值很高，则可能是元空间导致的Full GC。

第二阶段：深入分析，定位根因

确认是Full GC导致问题后，需要分析“为什么”老年代或元空间会持续满。

1. 检查 JVM 内存配置。
   使用 jinfo -flags <pid> 或启动日志，确认 堆内存参数：

   • -Xms (初始堆大小) 和 -Xmx (最大堆大小) 是否设置得过小？对于生产应用，通常设置为相同值以避免动态扩缩带来的开销。
   • -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 的设置。元空间默认不限大小，但若应用动态生成大量类（如使用Groovy、反射过多），也可能撑满。观察 jstat 的 M 列或GC日志中 Metaspace 的变化。

2. 抓取 堆内存快照 (Heap Dump)。
   这是定位内存泄漏最直接有效的方法。强烈建议在Full GC发生时或发生后立即抓取。

   # 命令式抓取，会触发一次Full GC，对生产有影响，慎用
   jmap -dump:live,format=b,file=heapdump.hprof <pid>
   
   # 通过JVM参数自动抓取（推荐生产环境使用）
   # 启动时添加参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/
   # 发生OOM时会自动生成dump文件。

   下载 生成的 .hprof 文件到本地。

3. 分析 堆转储文件。
   使用 MAT (Memory Analyzer Tool) 或 VisualVM 打开 heapdump.hprof 文件。

   • 查看 Leak Suspects Report（泄漏疑点报告），MAT会直接给出可能的问题点。
   • 分析 Dominator Tree（支配树），查看 占用内存最大的对象是什么。这通常是直接元凶。
   • 检查 对象引用链：对于可疑的大对象集合，查看 为什么它无法被回收（即被哪些GC Root引用着）。常见的GC Root有：当前线程栈帧中的局部变量、静态变量、JNI引用等。
   • 特别注意：如果分析发现是 char[]、String、HashMap、ArrayList 等基础类型对象占用巨大内存，需要反向追踪是哪个业务对象（如某个Service、缓存Map）持有了它们。

4. 排查 非内存问题。
   如果堆内存分析无异常（即对象都是合理存活），需要考虑：

   • 元空间泄漏：分析 dump中的类加载情况。在VisualVM的“类”视图中，查看 已加载类的数量。如果数量持续异常增长，可能存在类加载器泄漏。
   • 显示调用 System.gc()：在代码中全局搜索 System.gc() 或 Runtime.getRuntime().gc()，检查是否被错误地频繁调用。添加 JVM参数 -XX:+DisableExplicitGC 可以禁止该调用（但需评估影响）。

第三阶段：优化与解决

根据第二阶段的根因，采取对应措施。

1. 解决 内存泄漏。
   这是最常见且需优先处理的问题。根据堆分析报告：

   • 修复 代码中的集合类（List, Map）无限增长问题，确保有明确的清理逻辑或使用弱引用/软引用容器。
   • 检查 各类连接（数据库、网络）是否被正确关闭，避免连接池对象泄露。
   • 审查 使用缓存的地方（如本地HashMap、Guava Cache等），确保 有大小限制和淘汰策略（LRU）。

2. 调整 JVM 内存参数。

   • 扩容堆内存：如果应用确实需要更多内存，且服务器资源允许，增大 -Xms 和 -Xmx 的值。

     -Xms4g -Xmx4g # 设置为4GB

   • 调整分代比例：通过 -XX:NewRatio（老年代:新生代比例）或 -XX:NewSize、-XX:MaxNewSize 直接设置新生代大小。适当增大新生代，可以减少对象过早晋升到老年代的概率。

     -XX:NewRatio=2 # 表示老年代:新生代 = 2:1
     # 或者
     -XX:NewSize=1g -XX:MaxNewSize=1g

   • 调整元空间：如果确认是元空间问题，设置 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 为合理值（如256M或512M）。

     -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m

3. 优化 GC 算法。
   对于JDK 8，如果存在长时间停顿的老年代回收问题，可以考虑从Parallel GC切换到低停顿的G1垃圾回收器。

   -XX:+UseG1GC
   -XX:MaxGCPauseMillis=200 # 设置预期的最大GC停顿时间目标（毫秒）
   -XX:InitiatingHeapOccupancyPercent=45 # 当整个堆占用达到45%时，开始并发标记周期

   对于JDK 11及以后版本，G1已成为默认GC，也可以测试更新的ZGC (-XX:+UseZGC) 或Shenandoah (-XX:+UseShenandoahGC)，它们能提供更低的停顿时间。

4. 规避 全局GC。

   • 如果业务中存在 System.gc() 调用且无法移除，使用 -XX:+DisableExplicitGC 参数。
   • 检查 某些框架（如RMI的DGC、NIO的DirectByteBuffer）是否会定期触发 System.gc()，并寻找禁用其自动GC的方法（如 -Dsun.rmi.dgc.server.gcInterval=3600000）。

最终行动清单：

1. 通过GC日志和jstat 确认 Full GC频率和老年代状态。
2. 生成 Heap Dump文件。
3. 使用 MAT 分析 dump，定位 占用内存最大的对象及其引用链。
4. 根据根因，修复 代码或调整 JVM参数。
5. 重启 应用，持续监控 jstat 输出，验证Full GC频率和老年代占用是否下降到合理水平。