datasource 本身不提供泄漏监控，但通过 hikaricp 的 leakdetectionthreshold 配置、jmx 指标观察、jstack 线程分析及单元测试断言，可实现连接泄漏的主动发现与精准定位。
DataSource 本身不直接提供“泄漏监控”功能，但配合连接池实现（如 HikariCP）和 JVM 层工具，可以构建一套高效、可落地的连接泄漏发现与定位机制。关键不是等它爆满才行动，而是让泄漏在发生时就暴露出来。
开启连接泄漏检测开关
HikariCP 内置了轻量级泄漏检测能力，只需配置一个参数即可激活：
- 设置 leakDetectionThreshold（单位：毫秒），例如
config.setLeakDetectionThreshold(60_000)表示连接被借出超 60 秒未归还即视为泄漏 - 该参数默认为 0（禁用），生产环境建议设为 30–120 秒，太短易误报，太长失去意义
- 触发后会在日志中打印完整堆栈，精确到哪一行代码获取了连接却未释放，例如：
WARN - Connection leak detection triggered for connection ... at OrderService.createOrder(OrderService.java:32)
结合 JMX 实时观察连接池状态
通过 Actuator 或 JConsole 连接应用的 JMX 端口，重点关注以下指标：
- ActiveConnections：持续高位不降（如长期等于 maxPoolSize）是泄漏强信号
- IdleConnections：长期接近 0，且 ThreadsAwaitingConnection 持续增长，说明连接有去无回
- ConnectionTimeoutCount 和 ConnectionCreationCount 同步飙升，暗示连接不断新建却难回收
- 每 5 分钟对比一次曲线，比看单次值更有价值
用 jstack + 线程栈交叉验证
当怀疑泄漏存在时，执行 jstack <pid></pid> 并重点筛查三类线程：
- RUNNABLE 状态卡在 socketRead0 / executeQuery：连接已借出，在 SQL 执行阶段卡住，大概率未 close 或事务未提交
- TIMED_WAITING 卡在 sleep / HTTP 调用：常见于事务内调外部服务，导致整个事务（连带连接）长时间挂起
- WAITING 卡在 HikariPool.getConnection：这是结果，不是原因——上游连接没还，下游只能排队
单元测试中主动拦截泄漏
在测试阶段就堵住漏洞，比上线后救火更可靠：
- 使用 HikariConfig.setInitializationFailTimeout(-1) 让连接池启动失败时抛异常
- 在每个集成测试前后统计连接数：
dataSource.getHikariPoolMXBean().getActiveConnections() - 测试结束断言活跃连接数为 0，CI 流水线自动拦截泄漏测试用例
- 搭配 Testcontainers 启动真实数据库，模拟真实连接行为
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
