JarFile实例多 Finalizer占用内存过大 引起的YGC时间过长 的问题排查和解决办法

故事起源

  已经记不清楚了是内存先告警还是CPU先告警的，而且还经常半夜告警，由此牵出了一系列的故事。。。。。。

问题描述

  当出现内存出现第一次告警的时候是在半夜，我通过命令查看指定服务器的GC情况，发现FGC次数比较多，然后使用命令进行dump。然后当我去拽文件的时候发现服务被重启了（团队中负责人强哥也收到了告警），我当时是在默认的工作目录下进行的dump，所以文件没有保存上。重启之后已经3点了，大家都没有睡意，就组了一把王者（茂哥和强哥说要带我，说带我赢，随便赢！结果青铜局被虐，他们骗我。。。。。。）

  等到上班的时候，我们再次查看服务的GC情况发现服务的YGC时间太长，竟然在1s~2s之间，如下图：

  看到这个时间的长度我们是很崩溃的，我们的服务并没有复杂的业务，这么长时间的YGC确实是不能忍受的。而且长时间的YGC还造成了我们服务的超时，CPU的峰值被拉高，然后就是一些列的告警。。。。

  为了查看大对象的引用，使用命令查看目前内存中的数据：

  dump之后使用MAT分析工具分析发现这个“java.lang.ref.Finlizer”的占用那是真的多啊！另外一个“LaunchedURLClassLoader”也不少：

  再来个柱状图分析的结果：

  树形展示看的更加清楚明晰：

  排除掉弱引用、虚引用、软引用的依赖之后，查看GC Root的保留之后我的内心是崩溃的，这是啥啊？完全没有我们的业务代码啊！

  这什么东西引起的链表那么深？

  当我再也没有力气点“next”查看链表的最后一个是什么的时候，茂哥发现了一个好东西，使用JProfile 查看GC Root的可视化界面（一屏拉不下，看不清楚就不用看了，不重要，只要知道很多就行了 ^ _ ^ ）：

  看的我们头皮发麻。随后我们对项目中可能存在的“代码刺客”进行了一波优化：拆分请求量大的业务，优化循环BeanCopy，优化Number类型通过连接引号转字符串，更换G1垃圾收集器（用了一会就崩溃了，后续又换回了ParNewGC组合），调整堆大小和EDU的大小以及8:1这个比例。。。。。。

  优化过之后我们的YGC降到了0.3秒左右，内心当时真是欢欣鼓舞举国欢庆啊，心想着可算把这个问题解决了。

领导的怀疑

  当我们认为事情告一段落的时候，我们毅哥提出了质疑，因为0.3对于YGC来说还是有点长。因为我们另外一个项目的流量要比我们出问题的这个要大，但是那个服务的YGC都在100ms以内。因此怀疑还是我们的项目的某个地方出了问题(后续验证这个怀疑是正确的)。

  如果这样分析看来确实是有点问题，但是问题在哪里通过这个分析工具也没有明确的指示。以往的内存溢出我们使用工具很快就能够定位到问题，但是这个问题，确实蚌住了！

  因为项目中使用到了Mybatis-Plus，随后对这个产生了怀疑，茂哥在把Mybatis-Plus去掉之后发现YGC确实下降了，然后我们就开始重新分析。

  去项目的github上搜索了别人提出的issue看看有没有和“MybatisConfiguration”类似的问题，答案结果并不如意。然后继续去Google继续搜索。

  当看见这篇文章的时候我内心一激灵，这个问题貌似和我们的百分之99.99的类似啊，毕竟我们也使用了druid而且MySQL的连接jar也是8.X的，宇视我怀着激动的心情点进了这篇文章。

解决办法

升级Druid的版本号！

问题原因

这个问题，太坑了！！！！！！！！！！！！！！！
  根据原文里说的，是因为开启了空闲检测，而低版本的druid有个BUG。连接地址Druid版本BUG查看项目中版本源码（我们使用的是1.1.10版本）


  我们的配置完美“命中”！

github上相关的issue

  解决之后查看内存占用大小，再也看不到“JarFile”的问题了，真是太开心了！！！

耗时两周成功解决！