转载

牛逼了！用 IDEA 扒出了开源组件导致FGC的原因

点击上方“ 匠心零度 ”，选择“设为星标”

做积极的人，而不是积极废人！

某天上午收到最近发布的一个服务 频繁FGC 的告警，这个服务只是给公司内部相关人员使用的，并非给互联网用户提供服务的系统。而且功能也比较简单，就是查看一些统计信息、报表数据、数据导出Excel等，访问量非常低。

另外，由于这个服务并不是OLTP，所以就是简单的使用默认的ParallGC垃圾回收器，JVM参数也只是做了简单的配置：

关键线索

废话不多说，既然有FGC，那就首先查看GC日志。毕竟FGC的原因还是比较多的，GC日志也是 最直观 的展示FGC原因的证据之一。

这里要补充一句，我们在排查问题时，切记不要靠自己的主观意识猜测，而应该做到每一步的推断都有理有据，这样才能越来越接近真相，找出真正的凶手。

GC日志中寻找FGC的命令以及结果如下所示（只贴出部分）：

根据这段GC日志就能非常肯定： 是因为某些地方调用System.gc()触发的FGC 。

因为这个服务访问亮比较小，并发量并不高。所以，笔者想看看触发FGC的时候，服务被调用了什么接口（如果是并发很高的OLTP，这种方法可能就不是很适用，毕竟每秒TPS成百上千，甚至更大，根本无法确定是哪个接口引起的）。

以上面这段FGC日志，根据其触发的时间点，然后去系统业务日志中查找。很顺利我们就找到了这个时候是调用了一个导出报表数据到Excel并下载的接口。一开始我还有点怀疑会不会是导出数据量很大引起FGC，但是后面走读业务代码，发现导出数据限制最大不超过1000，所以，这个猜想也就被否定了。

重现问题

既然是导出Excel引起的，那么笔者就打算模拟这段代码，试图以最小量的代码看是否能重现这个问题。毕竟： 范围越小，距离真相也就越近 。

所以，笔者根据这个接口的业务代码，等价的写出了下面这段代码：

配套的JVM参数如下，接下来运行这段代码即可。过程是如此顺利，10次Excel操作，10次FGC：

之所以用这段JVM参数，是为了希望通过 -verbose:gc 将GC日志直接输出到idea的控制台，而不是将GC日志输出到GC日志文件中，这样更方便定位问题。而且这段JVM参数相比生产环境的JVM参数，堆的大小和比例都是一样的，垃圾回收器也都是默认的。

既然重现问题了，那就相当于问题解决了一半。窃喜，哈哈哈～～～

另辟蹊径

事实上定位这种问题最常见的方法还是借助 btrace 跟踪是哪里调用了System.gc()，毕竟，如果不能像笔者这种场景用一段很小的代码重现问题，笔者接下来介绍的方法可行性就不是很高。但是既然重现了，那么笔者今天就介绍另外一个门槛更低的办法： 借助IDEA强大的搜索功能 。毕竟定位问题不是为了炫技，只要能找出问题的办法，都是好办法。

需要说明的，这段代码笔者是在一个新建的Maven工程中运行的，这段代码只依赖了一个jxl。之所以这么做，是为了笔者接下来介绍的方法能更精确的定位问题所在：

接下来就是笔者介绍的方法：如何通过牛逼的IDEA找出是哪里调用了System.gc()。在搜索触发FGC的元凶之前，需要先下载jxl的源码--这段重现问题源码唯一的Maven依赖。这个下载必不可少，否则IDEA是无法搜到的：

牛逼了！用 IDEA 扒出了开源组件导致FGC的原因