导读

本文是线上问题解决案例系列之一，旨在通过实在案例向读者介绍发现问题、定位问题、解决问题的办法。本文讲述了从垃圾回收耗时过长的表象，逐渐定位到数据库连接池保活问题的全过程，并对其中用到的一些知识点进行了总结。

一、问题形容

大促期间，某接口超时次数增多，经排查间接起因是GC耗时过长，查看监控FullGC达500ms以上，接口超时工夫与FullGC产生工夫吻合。

图1 FullGC耗时监控

二、利用根本状况

  • 容器：8C12G；
  • JVM配置：-XX:+UseConcMarkSweepGC -Xms6144m -Xmx6144m -Xmn2048m -XX:ParallelGCThreads=8 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+ParallelRefProcEnabled；
  • 数据库类型：MySQL；
  • 数据库连接池：DBCP；

三、排查过程

1、 GC耗时过长，阐明内存中垃圾对象很多。

2、 首先狐疑是否有内存透露，察看FullGC后堆内存回收状况，尚属失常，临时排除内存透露起因。

图2 产生FullGC后堆内存回收监控

3、 推断FullGC耗时过长是否因为老年代有大量死亡对象，遂导出FullGC前后堆内存dump，通过比对“保留大小”，发现FullGC后大量数据库相干对象被回收。

图3 堆内存对象剖析

4、 数据库连贯失常应该不会频繁创立和断开，进入老年代后，失常不应该被回收，通过堆dump内容OQL剖析每个数据库连贯数量，发现很多库连接数都大于“maxActive”数量，能够必定有很多生效连贯。

5、 初步判断间接起因是很多生效数据库连贯进入老年代，导致FullGC耗时过长。

6、 狐疑连接池验证周期过长，导致数据库因闲暇过长敞开连贯，将连接池参数“
timeBetweenEvictionRunsMillis”由1分钟调整到10秒，问题仍旧。

7、 浏览DBCP源码，发现是通过
org.apache.commons.pool.impl.GenericObjectPool.Evictor定时工作，依照timeBetweenEvictionRunsMillis配置的周期定时驱赶生效连贯，驱赶条件：若连贯闲暇工夫大于“minEvictableIdleTimeMillis”，则会驱赶连贯，期待垃圾回收。若开启“testWhileIdle”则会执行“validationQuery”。进一步浏览代码，发现执行“validationQuery”后，连贯闲暇工夫并不会从新计算，导致连贯在业务低谷时很容易被淘汰，而数据库连贯会关联大量对象，创立、回收老本低廉，并且影响GC。

8、 反向思考，为何只有在大促期间才产生问题？

图4 平时和大促时回收频率比照

能够看到平时因为业务量小，GC不频繁，过期连贯没有达到进入老年代阈值，在年老代被回收。而大促时业务量大，GC频繁，连贯在进入老年代当前才过期，导致老年代FullGC工夫过长。

9、 至此，根本能够必定问题起因是数据库连接池不具备“保活”能力，导致连接不断淘汰和新建，在业务顶峰时段，连贯进入老年代而后生效，造成FullGC耗时过长，最终导致接口超时次数增多。

四、解决方案

计划1：改为G1回收器，对老年代回收是分块进行，能够避免长时间进展。另外默认MaxTenuringThreshold值是15，能够避免生效连贯过早进入老年代；

计划2：
minEvictableIdleTimeMillis设置为0，使数据库连贯不会主动生效，进入老年代当前始终存活，防止在老年代生效回收；

五、问题总结

数据库连接池并不具备通常了解的“保活”能力，数据库连贯在业务不沉闷的利用中，会一直淘汰和重连，而连贯会通过虚援用形式（
com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference）携带大量对象，如果连贯存活工夫内YGC次数达到寿命阈值，则会进入老年代，老年代是应用“标记-革除”算法，回收老本更高，进而造成FullGC耗时过长。

六、拓展知识点

1、 Druid连接池同样存在不能“保活”问题，较新版本提供“KeepAlive”选项（未验证）；

2、 Druid连接池配置的“validationQuery”语句通常并不会被执行，MySqlValidConnectionChecker在查看连贯有效性时，会判断驱动是否实现pingInternal办法，如果实现则会通过此办法验证有效性。MySQL的JDBC驱动实现了该办法，因而“validationQuery”配置的语句通常不会执行；

图5 连贯有效性校验代码

3、 DBCP和Druid连接池默认都是FILO，如果业务不忙碌，会导致只有最前边的连贯被应用-偿还-应用，后边连贯根本都在无谓的驱赶、重建连贯；

4、 虚援用对GC的影响：这些援用只有通过两次GC能力被回收掉，如果进入老年代，则必须通过两次FullGC能力开释内存。本例中因为一直有新的虚援用对象在老年代生效，导致FullGC后，内存水位依然偏高，会加剧GC压力。新版本JVM已对此做了优化，一次GC能够回收掉；

5、 相似的影响还有finalize办法；

6、 CMS回收器默认MaxTenuringThreshold为6，而ParallelGC和G1均默认15；

结语

本文对数据库连贯生效引起的GC问题进行了详细分析，心愿读者通过本文对数据库连贯“保活”机制、GC问题根本分析方法有所收益，后续该系列文章会持续推出其余案例分享。

作者：京东批发 王利辉

内容起源：京东云开发者社区