HikariCP通过leakDetectionThreshold配置主动检测连接泄漏，触发后打印完整调用栈定位问题代码；结合jstack分析RUNNABLE/TIMED_WAITING/WAITING三类线程状态可识别泄漏根源；单元测试中验证连接归还状态能提前拦截泄漏。
Java 中不能直接用反射“探测线程栈”来定位 JDBC 连接泄漏——反射本身不提供线程执行上下文或资源持有关系的洞察。真正有效的方式是结合连接池的泄漏检测机制 + 线程栈快照分析，而反射仅在极少数定制化监控场景中辅助获取私有字段（如 HikariCP 内部连接包装器的状态），但绝非主路径。
下面分三步讲清楚怎么实操：
一、让连接泄漏“当场现形”，而不是靠反射去猜
HikariCP 提供开箱即用的泄漏检测能力，它会在连接被借出超时后，自动打印完整调用栈：
- 配置
leakDetectionThreshold（单位毫秒）：HikariConfig config = new HikariConfig(); config.setLeakDetectionThreshold(60_000); // 超60秒未归还即告警
- 生产建议值：30–120 秒。太短易误报（如慢查询）；太长失去预警价值。
- 触发后日志示例：
WARN - Connection leak detection triggered for connection ... at com.example.service.UserService.getUser(UserService.java:47)
这行就精准定位到哪一行代码
getConnection()后没close()或没走try-with-resources。立即学习“Java免费学习笔记（深入）”；
二、用 jstack 抓现场，看谁“拿着不放”
当泄漏疑似发生（比如活跃连接数长期满、空闲连接趋近于 0），立即导出线程栈：
jps -l # 找到 Java 进程 PID jstack <pid> > dump.log # 生成线程快照
重点筛查三类线程：
-
RUNNABLE 状态卡在
Connection.prepareStatement()或executeQuery()→ 很可能 SQL 正在执行，但后续没 close -
TIMED_WAITING 卡在
Thread.sleep()或 HTTP 客户端调用里 → 常见于事务内调外部服务，导致连接随事务悬停 -
WAITING 卡在
HikariPool.getConnection()→ 不是根源，是结果：上游线程没还连接，下游只能排队
不必手动反射读取线程对象字段——jstack 输出已包含线程名、状态、完整堆栈、锁信息，足够定位。
三、单元测试阶段主动拦截，比运行时排查更高效
在 DAO 或 Service 测试中，模拟连接借用并验证是否归还：
- 使用 HikariCP 的
HikariDataSource配合setInitializationFailTimeout(-1)和setConnectionTestQuery("SELECT 1")确保测试环境可用 - 在测试 teardown 阶段检查：
assertThat(dataSource.getHikariPool().getTotalConnections()).isEqualTo(0); assertThat(dataSource.getHikariPool().getActiveConnections()).isZero();
- 更进一步：用
Mockito拦截Connection.close()调用，断言其被触发
这类验证写在 CI 流程里，能拦截 80% 以上因忘记 close() 或 try-with-resources 缺失导致的泄漏。
不依赖反射，靠配置+工具+测试闭环，才是稳定识别 JDBC 连接泄漏的正解。
