sql连接泄漏表现为连接数持续增长致超时失败，主因是connection未正确关闭，需检查finally或try-with-resources释放逻辑、连接池泄漏检测配置及框架隐式持有场景。
SQL连接泄漏通常表现为应用运行一段时间后数据库连接数持续增长，最终达到连接池上限或数据库最大连接数限制，导致新请求无法获取连接而超时失败。根本原因在于程序中获取的数据库连接未被正确关闭，常见于异常路径遗漏、资源管理不当或连接池配置不合理。
检查代码中连接释放逻辑
重点审查所有使用 Connection、Statement、ResultSet 的地方，确认是否在 finally 块或 try-with-resources 中显式关闭：
- 使用传统 try-catch 时，必须在 finally 中调用
connection.close()，且需判空和捕获关闭异常 - 推荐统一使用 try-with-resources（JDK 7+），自动关闭实现了 AutoCloseable 的资源，如
try (Connection conn = ds.getConnection(); PreparedStatement ps = conn.prepareStatement(...)) { ... } - 避免在方法中返回未关闭的 Connection 或 ResultSet，尤其不要将 Connection 存入类成员变量或静态容器
验证连接池实际行为
即使代码写了 close()，也可能因连接池代理机制导致“假关闭”——实际归还到池而非真正断开。需结合连接池日志与监控确认：
- HikariCP：开启
leakDetectionThreshold（如设为 60000 毫秒），超时未归还会输出堆栈定位泄漏点 - Druid：启用
removeAbandonedOnBorrow=true和removeAbandonedTimeoutMillis=60000，并查看druid_stat.sql中 activeCount 是否长期不降 - 观察数据库端活跃连接（如 mysql 执行
SHOW PROCESSLIST），比对应用连接池监控指标是否一致
排查隐式连接持有场景
某些框架或中间件可能在不经意间长期持有连接：
- spring 的 @Transactional 方法若未正确传播或异常未被事务管理器捕获，可能导致连接未释放
- 流式查询（如 JDBC 的
setFetchSize(Integer.MIN_VALUE)）或游标分页时，ResultSet 未完全读取就关闭 Connection，部分驱动会延迟释放 - 异步任务中直接使用主线程的 Connection（如未重新从池获取），或在 CompletableFuture 中未确保 close 在完成回调中执行
辅助诊断手段
快速定位泄漏源头可借助以下方式：
- 启用 jvm 参数
-Dcom.zaxxer.hikari.leakDetectionThreshold=60000（HikariCP），触发时打印调用栈 - 使用 Arthas 的
watch命令监控javax.sql.DataSource.getConnection()和java.sql.Connection.close()调用次数是否匹配 - 在测试环境模拟长周期运行，配合 JMX 查看连接池的
activeConnections、idleConnections变化趋势
连接泄漏不是偶发问题，而是资源管理漏洞的必然结果。从代码规范、池配置、框架集成三方面协同检查，多数情况可在 1–2 小时内定位根因。