线上问题处理案例：出乎意料的数据库连接池
原文中文，约2200字，阅读约需6分钟。
📝
内容提要
本文介绍了一起线上问题处理案例，通过排查垃圾回收耗时过长的表象，逐步定位到数据库连接池保活问题。最终提出了两种解决方案。
🎯
关键要点
-
本文介绍了一起线上问题处理案例，定位到数据库连接池保活问题。
-
大促期间，某接口超时次数增多，GC耗时过长是直接原因。
-
应用基本情况包括容器配置、JVM配置、数据库类型和连接池类型。
-
排查过程中发现内存中垃圾对象多，初步排除内存泄漏。
-
通过堆dump分析发现很多失效数据库连接进入老年代，导致FullGC耗时过长。
-
连接池验证周期过长，调整参数后问题依旧。
-
阅读DBCP源码发现连接空闲时间未重新计算，导致连接在业务低谷时被淘汰。
-
大促期间业务量大，GC频繁，过期连接在老年代被回收，导致接口超时。
-
确认问题原因是数据库连接池不具备保活能力，导致连接不断淘汰和新建。
-
提出两种解决方案：改为G1回收器或将minEvictableIdleTimeMillis设置为0。
-
总结数据库连接池不具备保活能力，连接在不活跃时会被淘汰和重连。
-
拓展知识点包括Druid连接池的保活问题、虚引用对GC的影响等。
🏷️
