数据库连接池引起的FullGC问题，看我如何一步步排查、分析、解决

问题现象

在某个工作日，突然收到线上的服务告警，有大量的请求延时产生，查看线上服务发现基本上都是获取数据库连接超时，而且影响时间只有3~4秒钟，服务又恢复了正常。隔了几分钟之后，又出现了大量的告警，还是影响3~4秒后又恢复正常。 由于我们是底层服务，被重多的上层服务所依赖，这么频繁的异常波动已经严重影响到了业务使用。开始排查问题

排查过程

DB的影响？

1. 当第一次告警产生时，第一反应是可能上层服务有大量的接口调用，并且涉及到一些复杂的SQL查询导致数据库连接数不够用，但是在分析了接口调用情况后发现异常前后的请求并没有明显的变化，排除突发流量造成的影响
2. 查询DB情况，负载良好，无慢查询，排除DB造成的影响

容器或JVM的影响？

排除了DB的影响之后，再往上排查容器的影响 我们再次回过头看异常告警，发现在每一波告警的时间段内，基本上都是同一个容器IP所产生，这个时候基本上已经有80%的概率是GC的问题了。 查询告警时间段内的容器CPU负载正常。再看JVM的内存和GC情况，发现整个内存使用曲线是像下面这样：

Heap

 

Old Gen

 

从上图可以发现内存中存在长时间被引用，无法被YongGC所回收的对象，并且对象大小一直在增长。直到Old Gen被堆满之后触发Full GC后对象才会回收。

临时措施

现在问题已经找到了，到目前为止只是3台实例触发了FullGC，但是在查看其它实例内存使用情况时，发现基本上所有的实例Old Gen都快到达临界点了。所以临时解决方案是保留一台实例现场，滚动重启其它所有的实例，避免大量的实例同时进行FullGC。否则很可能导致服务雪崩。

原本服务是有设置jvm监控告警的，理论上来说当内存使