数据库连接池泄漏本质是连接被借出后未归还，导致池子逐渐耗尽；需通过HikariCP的leak-detection-threshold日志定位泄漏行号，结合jstack区分RUNNABLE/TIMED_WAITING/WAITING线程状态判断泄漏类型，并检查ResultSet/Statement关闭、try-with-resources完整性及事务内异步调用等常见疏漏点。
数据库连接池泄漏不是“连不上库”，而是连接借出去了，却没人还——池子慢慢被占满，新请求排队、超时、报错。问题往往不爆发在高峰时刻，而是在某个方法反复调用后悄然堆积。关键不在重启，而在精准定位泄漏点并堵住源头。
看日志：让 HikariCP 自己开口说话
HikariCP 的 leak-detection-threshold 是第一道防线。一旦启用（比如设为 15000ms），它会在连接被持有超时后自动打印堆栈：
- WARN - Connection leak detection triggered for connection ... at com.example.service.UserService.loadUser(UserService.java:42)
- 这个行号就是泄漏发生的“现场”，不是调用处，而是 getConnection() 被执行、但后续没 close 的位置
- 注意：同一方法可能触发几十次，说明该逻辑路径稳定泄漏；不同方法各触发几次，则可能是多个独立泄漏点
查线程：区分“卡死”和“睡着”
用 jstack <pid> 看线程状态，能快速判断泄漏类型：
- RUNNABLE 卡在
socketRead0或JdbcConnection.execute→ 连接已借出，SQL 执行中卡住，未走到 close - TIMED_WAITING 卡在
Thread.sleep或 HTTP 客户端（如 OkHttp）→ 很可能在事务里调了外部接口，事务没提交，连接被锁住 - WAITING 卡在
HikariPool.getConnection→ 后续请求全在等连接，是结果，不是原因
验代码：三个最常漏掉的关闭点
泄漏几乎都藏在“看起来没问题”的代码里：
立即学习“Java免费学习笔记（深入）”；
- ResultSet/Statement 没关，只关了 Connection：JDBC 规范要求三者都要显式 close，尤其 ResultSet 在大数据量时会占用服务端游标资源
- try-with-resources 写法不完整：比如只把 Connection 包进 try，而 Statement 和 ResultSet 在外面创建 → 它们不会自动关闭
- 事务内嵌套异步或回调：@Transactional 方法里起了新线程、发 MQ、调 Feign，事务上下文没传播过去，导致连接无法随事务结束释放
配监控：把泄漏挡在上线前
光靠生产报警太被动。建议在测试和预发环境打开硬性约束：
- HikariCP 配置
leak-detection-threshold=5000（5秒），比生产更敏感 - 结合 Actuator + Prometheus，配置告警规则：当
hikaricp_active_connections持续 >80% 且空闲连接 - 单元测试加连接泄漏检测工具（如
ConnectionLeakUtil），每次构建跑一次，泄漏即失败
不复杂但容易忽略：泄漏从来不是“没写 close”，而是 close 没被执行到——要么在异常分支里丢了，要么被 try-with-resources 的作用域骗了，要么被 Spring 事务的边界绕过去了。盯住那几行报错堆栈，顺着线程状态找阻塞点，比盲目加最大连接数管用得多。
