记一次JVM内存溢出排查过程

1. 频繁FullGC预警

1.1 频繁FullGC告警：
时间发生在2020-07-10（周五）晚上21:15分左右，本该收拾行囊下班，突然收到频繁FullGC预警消息，吓的菊花一紧，过一会收到接口探活告警，说明服务已经不可用了；

1.2 下线当前问题节点：
服务是3台节点部署，既然其中一台出现问题，在上层网关上将当前节点下线，保证用户的请求不会再打到当前节点；

1.3 年青代和老年代情况：
登录监控平台查看jvm的情况：

黄色线：老年代
蓝色线：年青化
在21:10左右时，就已经开始发生明显的频繁FullGC；

1.4 YGC次数和FGC次数：
登录监控平台查看jvm的情况：

蓝色：当前出问题节点的YGC总次数；

蓝色：当前出问题节点的FGC总次数；

1.4 年青代具体情况：

黄色：S0；
紫色：S1；
蓝色：Eden；
大概在21:10 - 21: 20这段时间一直在YGC

2. 排查原因

经过上面的分析，和上次遇到的频繁FGC问题不一样 上次的是突增，突然被内存被占满，而本次的是存在缓慢的增长过程，猜测程序可能做了大批量导出；

2.1 生成dump文件
查看是否生成dump文件，如果没有生成，手动通过： jmap -dump:live,format=b,file=dump.hprof 进程号；生成dump文件；

2.2 重启服务
既然内存快照保存下来了，就可以放心的重新启动服务；

2.3 查看后台操作日志
查看后台操作日志，发现用户对一张拥有2200W记录的表做了一次导出，但是导出的sql里面有id值，按道理说只会导出一条；也不会导致程序内存溢出啊；

2.4 分析dump文件
既然可疑的导出有明确指定id，不会造成大批量的数据被加载进服务，那只能分析dump文件
dump文件大约28G，分析套路和 记一次排查线上频繁FullGC 过程 一样；

最后分析出来三个zip文件，解析后查看index.html;

大概占了24.3G，查看详细的调用栈；

还是出在导出的问题上；

2.5 查看服务器日志
经过精心排查服务器日志发现，在用户跳转到查询列表时，在没有输入任何查询条件的情况下，点击过导出按钮，造成大量记录被加载进内存；

2.6 服务优化
1.导出的限制方面做控制；
2.大数据量导出考虑数据迁移到其它平台；
3.为什么全量导出的操作没有被记录到操作日志（待排查）
4.网关高耗时请求也考虑告警；