Java应用频繁Full GC的根因排查需先启用详细GC日志（JDK8用-XX:+PrintGCDetails等，JDK9+用-Xlog:gc），再结合jstat、jmap与MAT分析高频次、低回收量、触发原因三类信号，定位内存泄漏、参数不当或元空间溢出等问题。
Java 应用频繁 Full GC，通常意味着堆内存压力大、对象生命周期异常或 JVM 参数配置不合理。抓取和排查的关键是：先拿到准确的 GC 日志，再结合日志内容定位根因，而不是盲目调参。
开启详细 GC 日志（JDK 8 及以上）
必须启用 GC 日志才能分析，推荐使用统一、可解析的格式：
- JDK 8：启动参数加 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/path/to/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M
- JDK 9+（统一日志框架）：用 -Xlog:gc*:file=/path/to/gc.log:time,tags,level:filecount=5,filesize=10M，更结构化，支持时间戳、线程 ID、GC 类型等字段
- 避免只加
-verbose:gc，它输出信息极简，无法判断是 CMS 还是 G1 的并发失败，也看不到晋升失败、元空间溢出等关键线索
快速识别 Full GC 频繁的特征
打开 GC 日志后，重点关注三类信号：
- 高频次：1 分钟内出现多次 Full GC（如每 10~30 秒一次），尤其在无明显业务高峰时
- 低回收量：每次 Full GC 后老年代剩余仍接近最大值（例如“[Tenured: 2800M->2790M(3072M)”），说明对象没被释放，可能是内存泄漏或大对象持续晋升
- 触发原因明确：日志中带关键词如 Ergonomics（堆自动扩容失败）、Metadata GC Threshold（元空间满）、Allocation Failure（年轻代/老年代分配失败）、Concurrent Mode Failure（CMS 并发失败退化为 Full GC）
结合工具做定向排查
单看日志只能猜方向，需配合运行时数据验证：
-
jstat 实时观察：执行 jstat -gc
2000 （每 2 秒刷新），重点看FGC（Full GC 次数）是否陡增、FGCT（Full GC 总耗时）是否持续上涨、OU（老年代已使用）是否长期 >90% -
jmap 抓堆快照（慎用）：在 Full GC 刚发生后立即执行 jmap -dump:format=b,file=heap.hprof
，再用 Eclipse MAT 或 VisualVM 分析：按“Group by Class”看谁占老年代最多；用“Leak Suspects Report”看疑似泄漏链 -
检查元空间：若日志提示 Metadata GC，用 jstat -gcmetacapacity
查看 MC（元空间容量）、MU（已使用），再确认是否漏设-XX:MaxMetaspaceSize
常见根因与对应动作
不必从头写代码，多数问题有固定模式：
-
年轻代过小 + 大对象直接进老年代：观察日志中是否有大量 “Promotion Failed”，调大
-Xmn或用-XX:PretenureSizeThreshold控制大对象阈值（仅限 Serial/Parallel） - 内存泄漏（如静态 Map 缓存未清理）：MAT 中发现某个业务类实例数随时间线性增长，且 GC Roots 可达，需检查缓存逻辑或注册监听器是否反向持有引用
-
G1 停顿失控：频繁 Mixed GC 后仍触发 Full GC，可能
-XX:MaxGCPauseMillis设太低导致 G1 过早回收，或堆碎片严重，可尝试增大堆或加-XX:G1HeapRegionSize -
显式 System.gc() 调用：检查代码或依赖库（如某些 NIO 框架、旧版 Druid）是否主动触发，加上
-XX:+DisableExplicitGC临时规避（但应修复源头）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
