真泄漏需满足：连接数持续上涨、processlist中大量Sleep且time超时、user固定为应用账号；应先通过SHOW PROCESSLIST和Threads_connected确认现象，再结合wait_timeout调短、leak-detection-threshold设60000ms等配置主动暴露问题。
怎么看连接是不是真在泄漏？
别一上来就改代码，先确认现象是否真实存在。登录 MySQL 执行 SHOW PROCESSLIST;，重点看 State 为 Sleep 且 Time 值持续增长（比如 >600 秒）的连接——这些大概率是“活着但没干活”的僵尸连接。
再查总量：SHOW STATUS LIKE 'Threads_connected';，对比业务低峰期和高峰期数值；如果长期稳定在 max_connections 的 80% 以上，风险已经实质化。
为什么 Sleep 连接不自动断开？
MySQL 默认的 wait_timeout 是 28800 秒（8 小时），interactive_timeout 同样很长。这意味着客户端不主动断开、应用也不 close，连接就能挂着不动，直到超时才释放。
这不是 bug，是设计行为，但线上必须调短：
- 建议设为
60～300秒，写进my.cnf并重启或动态执行SET GLOBAL wait_timeout = 300; - 注意：这个值只对新连接生效，已存在的 Sleep 连接仍按旧值计时
- 如果应用用了长连接池（如 HikariCP），还要同步调低连接池的
idleTimeout和maxLifetime，避免两者错位
Java 应用里哪些地方最容易漏关连接？
绝大多数泄漏发生在 JDBC 资源未显式释放，尤其在异常路径下：
-
Connection、Statement、ResultSet必须成对 close，缺一不可 - 别把
close()写在try块末尾——异常抛出后它根本不会执行 - 正确姿势是
try-with-resources，或确保finally块里调用close() - Spring
@Transactional不等于自动释放连接：事务未提交/回滚，连接就一直被持有；异常未被捕获导致事务未回滚，也是常见原因
try (Connection conn = dataSource.getConnection();<br> Statement stmt = conn.createStatement();<br> ResultSet rs = stmt.executeQuery("SELECT * FROM user")) {<br> // 处理结果<br>} catch (SQLException e) {<br> // 异常处理<br>}连接池配置怎么暴露泄漏问题？
连接池参数不是越大越好，而是要让它“提前暴露问题”：
- HikariCP 加上
leak-detection-threshold=60000（单位毫秒），连接被借出 60 秒未归还，就会打印堆栈，直接定位泄漏点 - 禁用
connection-test-query或设为无效 SQL，会掩盖连接失效问题；应启用connection-test-before-acquire -
maximum-pool-size别盲目设高——如果设成 2000，而 MySQL 的max_connections只有 151，多个服务一起连就全崩 - Druid 用户注意：
removeAbandonedOnBorrow=true和removeAbandonedTimeoutMillis=60000是等效兜底机制
连接数“只增不减”最麻烦的地方，不是它占了多少内存，而是它会把问题掩埋在正常流量之下——直到某次小高峰突然触发 Too many connections，你才发现三个月前上线的那段报表导出逻辑，从没关过连接。
