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

MySQL连接池泄露表现为服务变慢、SHOW PROCESSLIST出现大量Sleep连接、max_connections耗尽但无报错；本质是连接未被真正归还池中，需确保getConnection()必有对应且必定执行的close()归还动作，并开启Druid或HikariCP泄漏检测（如leakDetectionThreshold=60000）以捕获调用栈定位源头。连接没关，但程序没报错怎么办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 需在数据源配置中加：removeAbandonedOnBorrow=true、removeAbandonedTimeoutMillis=60000（单位毫秒），并开启日志级别为 DEBUG，它会在借连接超时后强制回收并打印堆栈；HikariCP 则靠 leakDetectionThreshold（单位毫秒），设为 60000 表示借出后 60 秒未归还就报警。Druid 的 removeAbandonedOnBorrow 在高并发下可能误判，建议只在测试/预发环境开启；生产建议用 logAbandoned=true + 定期查日志HikariCP 的 leakDetectionThreshold 设太小（如 5000）会导致频繁误告警，设太大（如 300000）又起不到及时发现作用，60000 是较稳妥起点两者都会在控制台或日志中输出类似 Connection leak detection triggered 的提示，并附带 getConnection() 调用栈 —— 这就是定位泄漏源头的关键线索如何用 SHOW PROCESSLIST 快速筛出可疑连接SHOW PROCESSLIST 是最轻量、最直接的现场快照工具，不用重启、不依赖应用日志。 Zeemo AI 一款专业的视频字幕制作和视频处理工具