mysql数据库连接池泄露如何排查_检查数据库连接的申请与释放

MySQL连接池泄露表现为服务变慢、SHOW PROCESSLIST出现大量Sleep连接、max_connections耗尽但无报错本质是连接未被真正归还池中需确保getConnection()必有对应且必定执行的close()归还动作并开启Druid或HikariCP泄漏检测如leakDetectionThreshold60000以捕获调用栈定位源头。连接没关但程序没报错怎么办MySQL 连接池泄露最典型的表象是服务跑着跑着变慢、SHOW PROCESSLIST 里出现大量 Sleep 状态的连接、max_connections 被耗尽但应用日志里几乎不报错。这不是“没出问题”而是连接被申请后没被显式释放还卡在池子里占着资源。关键判断点检查连接是否真被归还给池子而不是靠 try-catch 或 finally 里调用 close() 就以为万事大吉——很多连接池比如 HikariCP、Druid的 close() 实际上只是归还不是销毁如果归还逻辑被跳过比如异常提前 return、线程中断、异步回调未执行连接就永远滞留。务必确认所有 getConnection() 都有对应且**必定执行**的归还动作如 HikariDataSource 的 Connection.close()避免在 connection 上做长耗时操作如大文件处理、外部 HTTP 调用否则连接会卡住等效于“泄露”不要在 finally 块外写 return也不要依赖 JVM shutdown hook 清理连接——它不保证触发时机Druid 和 HikariCP 的泄漏检测开关怎么开两个主流连接池都内置了泄漏检测但默认关闭。不开等于盲跑。Druid 需在数据源配置中加removeAbandonedOnBorrowtrue、removeAbandonedTimeoutMillis60000单位毫秒并开启日志级别为 DEBUG它会在借连接超时后强制回收并打印堆栈HikariCP 则靠 leakDetectionThreshold单位毫秒设为 60000 表示借出后 60 秒未归还就报警。Druid 的 removeAbandonedOnBorrow 在高并发下可能误判建议只在测试/预发环境开启生产建议用 logAbandonedtrue 定期查日志HikariCP 的 leakDetectionThreshold 设太小如 5000会导致频繁误告警设太大如 300000又起不到及时发现作用60000 是较稳妥起点两者都会在控制台或日志中输出类似 Connection leak detection triggered 的提示并附带 getConnection() 调用栈 —— 这就是定位泄漏源头的关键线索如何用 SHOW PROCESSLIST 快速筛出可疑连接SHOW PROCESSLIST 是最轻量、最直接的现场快照工具不用重启、不依赖应用日志。 Zeemo AI 一款专业的视频字幕制作和视频处理工具