记一次频繁YoungGC生产问题排查思路及解决方案

1、问题背景

系统开发了新功能上线，本来上完之后功能验收正常，就在大家都松了一口气安心听技术分享时，晚上6.56分突然收到了系统告警：

YoungGC时间过长，说实话一开始看到这个告警心里是毫无波澜的，一是因为一次YoungGC时间过长影响不大，二是因为这是内部系统，虽然处理的数据量比较大，但是YoungGC不会影响功能正常运行。

当时心里的第一想法是：应该是刚启动导致系统有些不平稳，过一会儿就好了。

然而过了几分后，第二台主机也开始告警，意识到问题严重性的我赶紧跑上来排查问题。

2、GC日志分析

首先找运维拿到GC日志之后，通过在线分析网站：https://gceasy.io/把日志文件载入分析：

很明显，基本上都是Allocation Failure引起的GC，表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。

3、Dump文件分析

大概知道了原因，但还是得定位到具体问题，再找运维拿了dump文件之后，本地通过jvusalvm装入dump文件进行分析，发现堆里面有89万个File对象（尴尬的是，这个问题是后来大佬发现的，自己当时看的时候没注意到这里……）

这时候离真相已经很近了，只要知道是什么地方有大量创建对象这个操作就行了，这时候有两个方法：

1. 看代码
2. 通过jstack看看线程的堆栈信息

通过第二种方式很容易就定位到了具体问题

4、解决方案

既然知道是第三方SDK引起的问题，直接把用到这个SDK地方先给停了，然后把89W个文件rm -rf一把梭，之后系统就恢复平稳运行了。

5、小结

业务原因对接了第三方SDK，类似一个消息队列，由于SDK自身问题导致会把无法消费的消息通过文件的形式暂存在本地，然后通过一个定时任务每十分钟去重新消费这些消息，但是不知道为什么没有消费成功。

这些文件日积月累慢慢影响着GC的性能，最终到达性能监控的阈值，然后告警……