HikariCP的leakDetectionThreshold是连接泄漏预警开关，非自动修复机制；它仅在连接超时未归还时触发WARN日志，需配合DEBUG日志级别、堆栈捕获及TCP状态分析才能准确定位泄露源头。
hikaricp 的 leakdetectionthreshold 不是“开了就能自动修漏”，而是触发日志告警的倒计时开关——它只对未归还连接生效，且必须配合日志级别和线程堆栈才能定位到具体代码行。
为什么配置了 leakDetectionThreshold 却没看到泄露日志？
常见原因有三个：
- 日志级别不够：
HikariCP默认只在WARN级别输出泄露警告，而 Spring Boot 默认日志配置常把com.zaxxer.hikari设为INFO或更低，导致日志被过滤 - 阈值设得太大：比如设成
60000（60秒），但业务里一个事务实际卡住 45 秒就结束了，根本触发不了 - 连接被“假释放”：MyBatis 的
@Select方法若没加@Transactional，或用了SqlSessionTemplate但没走 Spring 管理的生命周期，连接可能被 close() 但未真正归还池中
leakDetectionThreshold 在 Oracle 场景下的合理取值
Oracle 驱动（ojdbc7/8）+ HikariCP 组合下，建议从 30000（30 秒）起步，而非默认的 0（关闭）：
- 太短（如 5000）会导致误报：网络抖动、DBA 手动 kill session、甚至 Oracle 的
sqlnet.ora中SQLNET.EXPIRE_TIME触发的探测包都可能让连接短暂不可用 - 太长（如 120000）会让问题延迟暴露：一次泄露可能要两分钟才报，线上已积压几十个连接
- 生产环境推荐分阶段：预发设 30000，灰度期观察日志频次；稳定后可调至 45000，平衡误报与敏感度
如何让泄露日志真正指向你的代码？
光靠 leakDetectionThreshold 只能知道“哪个连接泄露了”，但不知道“谁拿走又没还”。必须补两步：
- 在
application.yml中显式开启堆栈捕获：spring: datasource: hikari: leak-detection-threshold: 30000data-source-properties: net.sourceforge.jtds.jdbc.Connection: true（仅限 jTDS）——Oracle 场景下无效，需换招 - 改用
HikariDataSource的构造器注入方式，在代码中手动设置：hikariConfig.setLeakDetectionThreshold(30000);hikariConfig.setConnectionInitSql("SELECT 1 FROM DUAL");（可选，用于验证连接有效性） - 最关键的是：确保日志框架（如 Logback）对
com.zaxxer.hikari开启DEBUG级别，这样泄露发生时会打出完整线程堆栈，你能直接看到是哪个@Service方法里的JdbcTemplate.query()调用后没走 finally 块
泄露日志里出现 CLOSE_WAIT 是什么信号？
这不是 Java 层面的问题，而是 Oracle 连接断开后 TCP 状态残留，说明连接泄漏已进入“物理层恶化”阶段：
-
CLOSE_WAIT出现在应用服务器 netstat 结果里，代表本地（Java 进程）收到了 FIN 包但没发回 ACK+FIN，本质是 Socket 没 close() - 这通常意味着：Hikari 已调用
Connection.close()，但底层 Oracle JDBC 驱动因异常（如网络中断、驱动 bug）没真正释放 socket，或者你用了setAutoCommit(false)后忘了rollback()/commit()，连接卡在事务中无法复用 - 此时
leakDetectionThreshold日志可能已经不出现——因为连接对象已被标记“已关闭”，只是 socket 还挂着。必须结合netstat -an | grep CLOSE_WAIT和lsof -i -p {pid}交叉验证
真正难排查的不是“哪里没关连接”，而是“为什么关了却还在占用”。leakDetectionThreshold 是探针，不是手术刀；它告诉你病灶在哪片区域，但切口位置得靠堆栈+DB 会话快照+TCP 状态三者对齐才能找准。
