连接池耗尽主因是应用层未释放连接，而非数据库负载过高；需通过SHOW FULL PROCESSLIST排查慢查询、Sleep连接及存储过程调用，并用try-with-resources确保CallableStatement和ResultSet及时关闭，同时配置leakDetectionThreshold与MySQL的wait_timeout协同防泄漏。
连接池耗尽不是“连不上”，而是“连上了却回不去”——绝大多数情况是连接被卡在应用层没释放，而不是数据库扛不住。
查 SHOW FULL PROCESSLIST 看哪些连接真正在干活
别只盯着 Threads_connected 数值，它只告诉你“有多少连着”，不告诉你“为什么连着”。执行 SHOW FULL PROCESSLIST 后重点看三列：
-
Command是Query且Time> 30 秒：大概率是存储过程或慢 SQL 卡住，检查它是否含SELECT ... FOR UPDATE、未提交事务、嵌套循环或没加索引的WHERE -
Command是Sleep但Time持续增长：说明应用拿到连接后没关，或者调用完存储过程没消费全部ResultSet -
Info字段出现CALL开头：确认是不是某个存储过程在拖住连接，记下Id，后续可针对性KILL
Java 调用存储过程必须用 try-with-resources
漏关 CallableStatement 是生产环境最常复现的泄漏点。JDBC 不会因为你用了连接池就自动帮你关语句对象——Connection.close() 只归还连接，不清理其创建的 CallableStatement 或 ResultSet。
- 错误写法：
cs.execute()后直接 return，没关cs，也没处理多结果集 - 正确写法：必须包裹在
try-with-resources中，且显式循环消费所有结果集（存储过程可能返回多个SELECT） - 示例：
try (CallableStatement cs = conn.prepareCall("{CALL proc_report(?)}")) { cs.setInt(1, tenantId); cs.execute(); // 必须消费全部结果集 do { try (ResultSet rs = cs.getResultSet()) { if (rs != null) { while (rs.next()) { /* 处理 */ } } } } while (cs.getMoreResults()); }
启用连接泄露检测，60 秒不归还就报警
HikariCP 的 leakDetectionThreshold 不是摆设。设成 60000（60 秒），一旦连接被借出超时未归还，它会在日志里打出完整调用栈，精准定位到哪一行代码拿了连接没还。
- Druid 对应配置是
removeAbandonedOnBorrow=true+removeAbandonedTimeoutMillis=60000 - 注意：这个阈值要略大于你最长业务逻辑耗时，否则误杀正常请求；但绝不能设成 0 或 -1（即禁用）
- 配合 JVM 参数
-Dhikari.leak-detection-threshold=60000可动态覆盖配置文件
别忽略 MySQL 的 wait_timeout 和 interactive_timeout
即使应用层代码没问题，这两个参数设得过大（比如默认 28800 秒 = 8 小时），也会让空闲连接长期挂在线上，挤占有效连接数。
- 线上建议设为
300（5 分钟）：足够覆盖大多数长事务，又不至于让空闲连接赖着不走 - 修改后需重启 MySQL 或执行
SET GLOBAL wait_timeout = 300（仅对新连接生效） - 注意：应用连接池的
maxLifetime必须小于该值，否则连接池会尝试复用已被 MySQL 主动断开的连接，抛出Communications link failure
真正难排查的从来不是“谁连多了”，而是“谁连了不放”。连接池耗尽问题里，80% 的根因藏在应用代码的 finally 块之外、try-with-resources 之外、或是存储过程里一个没被 COMMIT 的事务里。
