FGC排查基础知识

排查思路及常用命令

1、查看java进程

ps -ef | grep java

jps

2、检查JVM配置

ps aux | grep "applicationName=adsearch"

3、查看堆内存情况

jmap -heap 进程ID | head -n20

4、观察老年代的内存使用情况，推测可能原因

GC后的短时间能够恢复到一定值，即可排除是内存泄露

5、jmap查看堆内存中的对象信息

jmap -histo 进程ID | head -n20

6、dump堆内存文件

jmap -dump:format=b,file=heap 进程ID

7、用分析工具分析dump文件

jhat、JVisualVM

找到大对象

8、最后通过代码分析可疑对象

.

GC会对程序产生影响

• FGC过于频繁：导致工作线程频繁被停止，让系统看起来一直有卡顿现象，也会使得程序的整体性能变差

• YGC耗时过长：卡顿时间就会增大，加上YGC本身比较频繁，就会导致比较多的服务超时问题

• FGC耗时过长：卡顿时间增加，尤其对于高并发服务，可能导致FGC期间比较多的超时问题，可用性降低

• YGC过于频繁：降低服务的整体性能

.

导致FGC的原因

• 大对象：系统一次性加载了过多数据到内存中（比如SQL查询未做分页），导致大对象进入了老年代。

• 内存泄漏：频繁创建了大量对象，但是无法被回收（比如IO对象使用完后未调用close方法释放资源），先引发FGC，最后导致OOM。

• 程序频繁生成一些长生命周期的对象，当这些对象的存活年龄超过分代年龄时便会进入老年代，最后引发FGC. （即本文中的案例）。

• 程序BUG导致动态生成了很多新类，使得 Metaspace 不断被占用，先引发FGC，最后导致OOM。

• 代码中显式调用了gc方法，包括自己的代码甚至框架中的代码。

• JVM参数设置问题：包括总内存大小、新生代和老年代的大小、Eden区和S区的大小、元空间大小、垃圾回收算法等等。

写完mybatis的SQL之后，一定要对各种 进行空值考虑，我公司一次FGC就是因为这个导致的，另外部门定时推送过来的订单refId存在为空的情况，导致select的时候扫描全表几千万条数据（还是分库分表的。。。），导致产生了很多实体类对象和mybatis缓存对象。
所以对于只有查询一行的SQL语句，要加上limit 1，防止 条件为空而导致扫描全表数据

.

排查总结

• 查看监控，记录出现问题的时间点和FGC频率

• 了解该时间点有没有上线版本

• 查看JVM参数设置：堆空间各个区域的大小，采用哪些垃圾回收器，分析JVM参数是否合理

• 对可能的原因进行排除：元空间打满、内存泄露、代码显示调用gc

• 通过 jmap -histo 命令并结合dump堆内存文件作进一步分析是否存在大对象或者长生命周期的对象

• 通过可疑对象，定位到具体代码