频繁 Full GC 问题排查方法

目录

频繁 Full GC 问题排查方法

一、问题背景

二、排查步骤

（一）收集 GC 日志

（二）使用其他工具分析内存使用情况

（三）调整 JVM 参数

三、总结

---

在面试中，频繁 Full GC 问题经常被问到，然而很多同学由于平时工作中不注重总结，可能会在被问到此类问题时大脑一片空白。本文将以一个电商网站为例，为大家总结频繁 Full GC 问题排查的通用方法。

一、问题背景

最近有很多用户反馈电商网站系统反应比较慢，运维通过监控发现 Full GC 比较频繁，原本正常情况下几个小时甚至几天才做一次 Full GC，现在却几分钟就做一次，这对网站性能产生了很大影响，因为 Full GC 会导致网站停顿。

二、排查步骤

（一）收集 GC 日志

可以通过设置 JVM 参数将 GC 日志打印出来。不建议直接用记事本打开 GC 日志文件进行分析，因为比较复杂。一般可以使用工具如 GCFU 或其他开源的分析 GC 日志的工具，这些工具可以清晰地展示出 Full GC 的频率、每次执行时间等异常情况。正常情况下，Full GC 几个小时或几天做一次比较正常，如果几分钟就做一次则比较频繁。同时，还可以分析每次 Full GC 后老年代的使用情况，如果老年代使用情况仍有 80% 以上，可能是程序存在内存泄漏问题。

（二）使用其他工具分析内存使用情况

1. JVisualVM：可以分析 Java 内存的使用情况，通过它可以清晰地看出年轻代的使用情况，比如频繁被填满后触发 Minor GC，可能是年轻代使用太频繁；如果 Eden 区和 Survivor 区经常满载，也有可能是 Full GC 频繁的原因之一。老年代持续增长且在 Full GC 后也没有清理出来太多空间，也会导致 Full GC 频繁。
2. 导出 dump 文件分析：可以通过 JMAP 命令在线上导出 dump 文件，但要注意这个命令可能会导致线上系统停顿，特别是对于使用人数较多且系统内存较大的情况，导出堆的快照 dump 转储文件可能需要很长时间，会导致线上系统卡顿，所以可以选择在凌晨用的人不多的时候进行操作。有了 dump 文件后，可以分析是否有对象占用空间太大，从而定位代码问题，比如是否存在内存泄漏。例如，有一个静态的订单列表，通过业务操作不断往这个列表里添加订单对象，而在其他地方处理完后没有从列表中清除，这就是典型的内存泄漏问题，需要在代码层面进行处理，如处理完订单后从列表中清除，或者控制列表中不要放太多订单对象，防止内存暴增甚至溢出。

（三）调整 JVM 参数

如果实在没有找出代码中的漏洞问题，说明可能确实使用的内存比较多，可以调整 JVM 参数，比如调大堆内存，或者调整年轻代、Eden 区、Survivor 区等区域的比例，这需要根据对整个 JVM 内存使用的分析情况进行合理调整。

三、总结

平时同学们可以总结一套自己解决频繁 Full GC 问题的方法步骤，以便在面试时对答如流，给面试官留下好印象。希望本文总结的通用步骤能为大家提供参考。