生产实战：系统频繁Full GC，如何一步步定位与解决？

---

文章目录

• 前言
• [一、 问题现象与初步判断](#一、 问题现象与初步判断)
• • [1.1 典型现象](#1.1 典型现象)
  • [1.2 初步判断方向](#1.2 初步判断方向)
• [二、 第一步：查看GC日志------第一手证据](#二、 第一步：查看GC日志——第一手证据)
• • [2.1 开启GC日志](#2.1 开启GC日志)
  • [2.2 关键日志解读](#2.2 关键日志解读)
• [三、 第二步：jstat实时监控------动态观察内存变化](#三、 第二步：jstat实时监控——动态观察内存变化)
• • [3.1 常用命令](#3.1 常用命令)
  • [3.2 输出指标解读](#3.2 输出指标解读)
  • [3.3 典型异常模式](#3.3 典型异常模式)
• [四、 第三步：获取堆Dump文件------冻结现场](#四、 第三步：获取堆Dump文件——冻结现场)
• • [4.1 获取Dump文件的方式](#4.1 获取Dump文件的方式)
  • [4.2 注意事项](#4.2 注意事项)
• [五、 第四步：MAT深度分析------定位泄漏根源](#五、 第四步：MAT深度分析——定位泄漏根源)
• • [5.1 第一步：查看Histogram（直方图）](#5.1 第一步：查看Histogram（直方图）)
  • [5.2 第二步：查看Dominator Tree（支配树）](#5.2 第二步：查看Dominator Tree（支配树）)
  • [5.3 第三步：使用Leak Suspects（泄漏嫌疑报告）](#5.3 第三步：使用Leak Suspects（泄漏嫌疑报告）)
• [六、 第五步：常见根因与解决方案](#六、 第五步：常见根因与解决方案)
• • [6.1 内存泄漏典型场景](#6.1 内存泄漏典型场景)
  • [6.2 大对象频繁晋升场景](#6.2 大对象频繁晋升场景)
  • [6.3 Metaspace满场景](#6.3 Metaspace满场景)
• [七、 完整的排查思维导图](#七、 完整的排查思维导图)
• [八、 总结](#八、 总结)

---

前言

作为一名Java后端工程师，你一定遇到过这样的场景：系统运行一段时间后，突然响应变慢，接口超时报警频发，甚至出现短暂的"假死"。登录监控平台一看，Full GC频繁发生，每次耗时数秒，GC后内存几乎没有下降。

这是一个典型的内存泄漏或内存分配不当导致的问题。本文将从一次真实的生产故障出发，系统化地讲解如何一步步排查Full GC频繁的问题，涵盖工具使用、分析思路和常见根因，帮助你在面对类似问题时能够从容应对。

---

一、 问题现象与初步判断

1.1 典型现象

当你看到以下监控指标时，就需要高度警惕了：

指标	异常表现
Full GC频率	每小时几次甚至几分钟一次
Full GC耗时	每次耗时1秒以上，严重时可达数秒甚至10秒+
GC后内存	GC后老年代占用率仍然很高（如80%以上），几乎不下降
系统响应	接口RT（响应时间）飙升，TP99急剧恶化
CPU使用率	GC线程频繁运行，CPU使用率飙升

1.2 初步判断方向

频繁Full GC可能的原因有很多，但归根结底离不开以下几个方向：

• 内存泄漏：对象只增不减，GC无法回收
• 大对象频繁晋升：对象直接进入老年代，老年代迅速填满
• 系统负载过高：对象创建速度超过GC回收速度
• MetaSpace满：类加载过多或类加载器泄漏
• 内存碎片：CMS等收集器产生碎片，导致大对象分配失败触发Full GC

下面，我们按照一套标准化的排查流程来逐一验证。

二、 第一步：查看GC日志------第一手证据

GC日志是排查内存问题的第一道关口。它记录了每次GC的详细信息，包括GC前后内存变化、耗时、原因等。

2.1 开启GC日志

在生产环境中，务必开启GC日志，这是事后回溯的关键依据。

# JDK8及之前
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log

# JDK9+
-Xlog:gc*:file=/path/to/gc.log:time,uptime:filecount=10,filesize=10M

2.2 关键日志解读

2024-03-09T10:15:30.123+0800: [Full GC (Allocation Failure) 10G->8G(16G), 3.5 secs]
2024-03-09T10:16:00.456+0800: [Full GC (Allocation Failure) 8G->7.5G(16G), 3.2 secs]
2024-03-09T10:16:35.789+0800: [Full GC (Allocation Failure) 7.8G->7.6G(16G), 3.8 secs]

从日志中我们可以读取到的关键信息：

字段	示例值	含义	问题信号
GC原因	Allocation Failure	分配失败触发GC	频繁出现说明内存压力大
GC前老年代	10G	老年代占用10GB	占用率高
GC后老年代	8G	老年代仍然8GB	GC后内存不降，泄漏嫌疑
堆总大小	16G	最大堆16GB	-
GC耗时	3.5秒	每次耗时数秒	严重影响系统响应

核心判断依据：如果每次Full GC后老年代内存占用率没有明显下降（例如从10G降到8G，然后下次GC前又涨回10G），说明存在内存泄漏或大量对象无法被回收。

三、 第二步：jstat实时监控------动态观察内存变化

GC日志是事后分析，而jstat可以实时监控JVM的内存变化，帮助你观察内存增长趋势和GC频率。

3.1 常用命令

# 每1秒输出一次GC信息，共输出10次
jstat -gc <pid> 1000 10

# 持续监控老年代和GC情况
jstat -gcutil <pid> 1000

3.2 输出指标解读

列名	含义	关注点
S0/S1	Survivor 0/1区使用率	是否正常晋升
E	Eden区使用率	对象分配速率
O	老年代使用率	持续增长 → 泄漏
M	Metaspace使用率	是否满
YGC / YGCT	Young GC次数/耗时	Minor GC频率
FGC / FGCT	Full GC次数/耗时	持续增加 → 问题严重

3.3 典型异常模式

# 持续观察发现老年代使用率不断攀升
Timestamp   O      FGC    FGCT
1000       45.2   12     25.3
1001       52.8   13     28.9
1002       61.3   14     32.6
1003       70.1   15     36.2
1004       78.5   16     40.1

分析结论：老年代使用率每秒钟增长约8%，Full GC次数同步增加，但每次GC后老年代仍然维持在70%以上。这强烈指向内存泄漏。

四、 第三步：获取堆Dump文件------冻结现场

当确认存在内存问题时，我们需要获取一份堆Dump文件，用于离线分析。

4.1 获取Dump文件的方式

方式	命令/操作	适用场景
jmap	jmap -dump:format=b,file=heap.hprof <pid>	最常用，会触发Full GC，生产环境慎用
自动导出	-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/	OOM时自动导出，推荐生产开启
JMX	通过JConsole或VisualVM	适合开发/测试环境

4.2 注意事项

• jmap会触发Full GC：在生产环境执行jmap dump时，JVM会先执行一次Full
  GC，可能导致系统短暂停顿，建议在业务低峰期操作。
• Dump文件很大：16GB的堆可能产生10GB+的dump文件，确保磁盘空间充足。
• 传输压缩：使用gzip压缩后再传输到分析机器。

五、 第四步：MAT深度分析------定位泄漏根源

获取堆Dump文件后，使用Eclipse MAT（Memory Analyzer Tool）或JProfiler等工具进行分析。MAT是免费且强大的选择。

5.1 第一步：查看Histogram（直方图）

打开Histogram视图，按对象实例数或Shallow Heap排序，重点关注：

• byte[]：往往是大数据、缓存、IO缓冲区
• char[]：往往与String相关
• java.lang.String：字符串对象过多
• java.util.HashMap$Node：Map容器泄漏
• 自定义业务对象：业务代码中的对象异常增长

典型发现：byte[] 占用 80% 堆内存，数量庞大。

5.2 第二步：查看Dominator Tree（支配树）

支配树可以清晰地展示哪个对象持有了大量内存。从根节点向下展开，找到占用内存最大的对象。

操作步骤：

1. 打开Dominator Tree
2. 按Retained Heap排序
3. 展开大对象，查看其内部持有的子对象
4. 追踪到GC Root路径

典型发现：一个ConcurrentHashMap实例持有了数百万个byte[]，Retained Heap达到6GB。

5.3 第三步：使用Leak Suspects（泄漏嫌疑报告）

MAT会自动分析并生成Leak Suspects报告，直接指出最可能的泄漏点。

典型报告内容：

Problem Suspect 1：
The thread `http-nio-8080-exec-12` keeps local variables with total size 4，213，456，789 (55.23%) bytes.
The memory is accumulated in one instance of `com.example.CacheManager` loaded by `AppClassLoader`.
Keywords： java.util.concurrent.ConcurrentHashMap$Node

分析结论：CacheManager类中的ConcurrentHashMap持有大量对象，且GC Root是工作线程的局部变量，说明这些对象仍在被引用。

六、 第五步：常见根因与解决方案

根据MAT分析结果，结合生产经验，Full GC频繁的常见原因及解决方案如下：

原因	典型特征	解决方案
内存泄漏	GC后内存不降，持续增长	找到泄漏对象，修复代码中的引用未释放问题
大对象频繁晋升	大量对象直接进入老年代	调大新生代，检查代码中频繁创建的大数组/大字符串
对象创建过快	Young GC频繁，晋升速度快	增加堆内存，优化代码减少对象创建
MetaSpace满	Full GC后Metaspace占用不降	检查类加载器泄漏，调大-XX:MaxMetaspaceSize
内存碎片	CMS收集器，老年代仍有空间但分配失败	启用CMS压缩-XX:+UseCMSCompactAtFullCollection或升级G1

6.1 内存泄漏典型场景

问题代码模式：

• 静态Map/List持续添加元素，从不清理
• 监听器注册后未注销
• ThreadLocal使用后未调用remove()
• 缓存框架未设置过期时间或最大大小

解决方向：

方案	适用场景	示例
使用WeakHashMap	Key的生命周期由外部控制	缓存与对象生命周期绑定的场景
使用Guava/Caffeine Cache	通用缓存	设置最大大小、过期时间
使用SoftReference/WeakReference	内存敏感型缓存	允许GC在内存紧张时回收
定期清理	业务可容忍延迟清理	定时任务清除过期数据

6.2 大对象频繁晋升场景

问题特征：

• -XX：PretenureSizeThreshold设置不当
• 代码中频繁创建大数组（如byte[1024*1024]）
• 数据库查询返回大量数据一次性加载到内存

解决方向：

方案	说明
调大新生代（-Xmn）	给大对象更多空间在新生代分配
分页查询	避免一次性加载海量数据
流式处理	使用游标或Stream分批处理
调整大对象阈值	根据业务设置合理的PretenureSizeThreshold

6.3 Metaspace满场景

问题特征：

• jstat -gcutil 显示M区使用率接近100%
• Full GC 后 Metaspace 占用几乎不降
• 常见于热部署、动态代理、JSP应用

解决方向：

方案	说明
调大-XX:MaxMetaspaceSize	给予更多本地内存空间
检查类加载器泄漏	热部署后旧ClassLoader未回收
减少动态代理生成	限制CGLIB/AOP代理类数量

七、 完整的排查思维导图

GC后内存不降
GC后内存下降
静态容器
缓存未过期
监听器未注销
大对象直接进老年代
对象创建速率过高
系统响应变慢

监控显示Full GC频繁
查看GC日志
内存泄漏
对象创建过快或堆过小
jstat确认增长趋势
获取堆Dump
MAT分析
定位泄漏点
修复容器清理逻辑
改用Caffeine/WeakHashMap
添加注销逻辑
检查晋升情况
调整PretenureSizeThreshold

或增大新生代
优化代码减少对象创建

或增加堆内存

八、 总结

频繁Full GC的排查没有银弹，但有标准化的方法论：

1. 查看GC日志：确认GC后内存是否下降，判断是泄漏还是正常压力
2. jstat实时监控：观察内存增长趋势和GC频率
3. 获取堆Dump：冻结现场，获取离线分析数据
4. MAT深度分析：通过Histogram、Dominator Tree、Leak Suspects定位泄漏点
5. 修复验证：根据根因修复代码，上线验证

预防建议：

• 生产环境务必开启GC日志和HeapDumpOnOutOfMemoryError
• 建立内存监控告警，在老年代占用率超过阈值时提前预警
• 定期进行内存压测和Full GC演练
• 代码Review时重点关注静态容器、缓存、ThreadLocal等高风险点

内存问题的排查是一场与时间的赛跑，掌握这套方法论，你就能在系统"窒息"之前，精准找到那根"稻草"。

---