在公司一次重大项目中，生产环境突然发生频繁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内存信息
<class>代表类相关的信息
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文件对代码进行分析才行，一定要动手实践，所谓的高手就是跨过坑和大海
