记一次线上fullgc排查历程

在公司一次重大项目中，生产环境突然发生频繁fullgc问题，通过cat发出警告。很不幸，这次项目非常重要，领导很看重，所以得赶紧解决问题，下面就是排查的艰苦历程

22:10 线上可以报警，出现fullgc问题，初步判断是服务器少了，于是申请堆线上服务器进行扩容，扩容之后，还是有fullgc问题

22:30 初步通过代码判断是自己查询了大对象导致老年代内存快速增长，目前业务中只有一个地方老年待，于是盲目改代码:一次查询修改成分页查询

修改完代码 进行发布 还是依然fullgc

23：30 突然发现启动参数 配置的内存是2G,于是乎修改成6g ，心想一定是这个地方内存小了导致的

 修改完之后进行发布，发现fullgc频率低了很大但是依然存在fullgc问题

12：00 开始进行dump文件下载分析

jmap -dump:format=b,file=/tmp/heapDump.hprof pid 

00：50 dump文件下载完成，开始进行正式分析，利用mat工具对dump文件进行分析

分析Leak Supercts视图 发现代码确定存在很大的问题

 选择一个地址进行具体分析

 当前具体的堆内存信息

 

内存对应的详细信息

简单介绍一下这里的MySQL JDBC内存信息

代表类相关的信息

catalog：mysql 目录 类似schema 

connection:对应数据库连接信息 记录用户名 密码 url  连接数等数据库连接的配置

owningStatement:对应JDBC42PreparedStatement 记录预编译语句相关

field：对应查询的字段

columnLabelToIndex：对应查询列的索引

rowData：对应列的数据

找出内存泄露的地方 那我们怎么定位到是SQL语句呢？

科普一下，在SQL语句执行的流程中我们都知道 SQL语句一般都会进行预编译 与之对应的JDBC功能都是Statement语句 所以我们找到内存中带有Statement的内存信息 如下图

在这个图中 我们惊喜的发现了新大陆 originalSql 这个就是保存原始未解析之前的SQL信息

 根据有问题的SQL在到代码中反查，确实发现了这段代码

没有走索引而且一次性查询的数据量非常大

导致fullgc的原因是这样的

故事还得从这个接口的作用说起,此接口是提供给监控服务使用,每完成一单主动交易，监控服务就会调用此接口校验是否需要查询可用库存，随着iat_task_detail表数据库越来越大30W+，任务执行速度越来越快，导致内存中堆积大量查询结果，大对象直接进入老年代，不会进行yong gc，大量请求直接导致老年代瞬间达到fullGC条件，就会执行fullGC,然后任务还在继续,就会导致fullGC释放之后，很短时间有达到fullGC条件，会继续fullGC，不断循环往复， 这就是cat监控短时间内有大量fullGC问题的根源

知道了问题根因，那我们如何解决呢？

解决办法就很简单了，针对本次单层货权，不需要查询此SQL 直接返回true，就行了，是不是很简单

03：10 修改完代码重写发布，fullgc问题解决了，监控了一个小时发现正常了 

04：00 回家 睡觉了。。。。

思考总结:针对fullgc问题 我们还是的根据dump文件对代码进行分析才行，一定要动手实践，所谓的高手就是跨过坑和大海