背景

线上的Java服务经常会遇到内存回收不到而导致GC频繁发生，严重影响服务质量，那么遇到这种问题该如何排查？本文就是一个GC问题排查的简单系统性分析。

一、如何排查

1.日志监控平台

目前市面上大多数公司都接入了日志监控系统，比如Grafana，一般这些系统都会配置收集各个集群里面每个实例的JVM监控信息。所以在监控平台里面我们就可以看到这些实例的GC信息，并对GC进行报警设置。所以通过经验的增加，也许从日志监控平台就能快速发现问题所在。

2.命令jstat

通过一些自带的命令，登录上服务器去查看实时的GC情况。

2.1 jstat -gc

显示与GC相关的堆信息。包括Eden区、两个Survivor区、老年代、永久代等的容量、已用空间、GC时间合计等信息。

2.2 jstat -gcutil

显示内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比。

2.3 总结

• 如果频繁发生YGC但很少发生FGC，说明在大量创建临时对象，然后又被回收掉了。
• 如果Old区域使用很高又频繁FGC，那说明内存泄漏了。(注意内存泄漏与内存溢出的区别)

需要更详细的关于JVM的命令可查看我的其他文章，在中有详细的介绍。

3. 堆内存分析

1. dump内存：使用jmap -dump命令将堆内存给下载出来

2. MAT分析：

   1. 打开Dominator Tree

   2. 分析内存最大对象

堆内存分析的工具有许多，熟悉一个使用即可。

二、总结

内存泄漏情况：一般发生这种，大多数都是因为能存活很久的对象引用了短生命周期的对象，导致短生命周期对象不能及时释放。

内存泄漏：程序在申请内存后，无法释放已经申请的内存。

内存溢出：程序在申请内存的时候，没有足够的内存空间供其使用。

这篇文章还是过于理论，但是博主作为24届毕业生实在没有遇到过线上发生GC的情况，如果遇到了应该也是老员工去处理，下次有幸参与排查的话，再重开一篇文章记录一下真实的GC排查过程。