LeakDetectionThreshold是泄漏预警机制而非自动修复工具，需配合日志（设为DEBUG级）、堆栈和代码联动定位；阈值须≥2000ms且≤max-lifetime，生产建议30000ms；重点排查事务过长、资源未关闭、MyBatis配置不当及异步任务持连接等场景。
LeakDetectionThreshold 不是自动修复工具，而是泄漏预警的“倒计时哨兵”——它只在连接被借出超时未归还时打日志，真正定位要靠日志+堆栈+代码三者联动。
确保泄露日志能真正打出来
很多团队配了 leak-detection-threshold 却看不到日志，根本原因是日志被过滤了：
- Spring Boot 默认把
com.zaxxer.hikari设为 INFO 级别，而 Hikari 的泄露警告是 WARN 级，必须显式提升：在logback-spring.xml或application.yml中加一行：logging.level.com.zaxxer.hikari=DEBUG（DEBUG 级才能输出完整堆栈） - 阈值不能设为 0（默认关闭），也不能小于 2000 毫秒（Hikari 会自动禁用）；生产建议从 30000（30 秒）起步，太短易误报，太长难及时发现
- 注意：该阈值不能超过
max-lifetime，否则会被 Hikari 自动忽略
从日志里抓关键线索
看到类似这样的日志，别急着改代码，先盯住三处信息：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
线程名：如
TyFileOpsThread-Attachworker-5，说明泄漏发生在该线程执行的业务逻辑中 -
堆栈首行：
at com.zaxxer.hikari.HikariDataSource.getConnection(...)是起点，往下找第一个你自己的类，比如SupplierProductFileOpsAppService.readDataFromExcelAttach()—— 这就是高危入口 - 时间戳与频率：如果同一方法反复触发泄露日志，大概率不是偶发慢 SQL，而是该方法本身存在资源管理缺陷
重点排查这几类典型场景
泄露不等于“没写 close()”，很多是隐性失控：
立即学习“Java免费学习笔记（深入）”；
- 事务包裹了耗时操作：比如 @Transactional 方法里解析大 Excel、调外部 HTTP、压缩文件——连接从开启事务起就被占用，直到方法结束才释放。应拆分事务边界，只把 DB 操作包进事务
- 多处 return / throw 忘关资源：手动获取 Connection 后，if 分支提前 return、catch 块没 close、甚至没写 finally —— 推荐统一改用 try-with-resources
- MyBatis 配合不当：@Select 方法若没加 @Transactional，或用了 SqlSessionTemplate 但脱离 Spring 生命周期管理，连接可能 close() 了却没真正归还池中
- 异步任务持有连接：CompletableFuture.supplyAsync 里直接用 JdbcTemplate，线程切换后上下文丢失，连接无法自动回收
验证修复是否生效
改完代码别只看日志停了，还要交叉验证：
- 重启服务后，观察监控指标：
active连接数是否稳定（不随请求量线性上涨）、idle是否有合理回落 - 在测试环境模拟高并发调用那个高危方法，持续压测 5 分钟以上，确认不再出现
Connection leak detected - 用
netstat -an | grep :3306查看应用到 DB 的 TCP 连接状态，避免出现大量CLOSE_WAIT（这是物理层泄漏信号，说明连接已断但 Java 层未清理）
