真泄漏需满足：连接数持续上涨、processlist中大量sleep且time超时、user固定为应用账号；hikaricp的active指标比threads_connected更准；leakdetectionthreshold建议设120000–300000ms并配warn日志；常见泄漏点包括未捕获异常中断try-with-resources、@transactional中手动获取连接未关闭、completablefuture异步分支遗漏close、sqlsession未关闭；迁移后因响应变慢、wait_timeout延长、代理层隐藏ip、驱动升级或健康检查未适配，易暴露原有泄漏。
怎么看连接是不是真泄漏了，而不是临时占满
连接池“连不上”不等于泄漏，得先区分是瞬时高峰还是真泄漏。最直接的证据是：连接数持续上涨、show processlist里看到大量 Sleep 状态且 time 超过你设的超时（比如 > 300 秒），同时这些连接的 user 固定指向你的应用账号。
- 执行
select * from information_schema.processlist where user = 'your_app_user' and command = 'Sleep' and time > 300;—— 如果结果稳定在 10+ 条且随时间只增不减，基本坐实泄漏 - 对比
show status like 'Threads_connected';和连接池最大值（如 HikariCP 的maximumPoolSize）：如果前者长期贴近甚至超过后者，而业务 QPS 并没突增，就是池子被“卡住”了 - 别只看 MySQL 侧 —— 连接池自身有活跃连接计数，比如 HikariCP 的
HikariPool-1.activeJMX 指标，比processlist更准，因为它反映的是“从池里借出但还没归还”的真实状态
HikariCP 的 leakDetectionThreshold 怎么设才有效
这个配置不是开了就灵，设错反而会掩盖问题或狂打日志。它本质是给每次 getConnection() 打一个“倒计时快照”，超时未 close() 或 release() 就触发告警，但快照里只存堆栈，不存 SQL、不存上下文。
- 设太小（如 1000ms）：高延迟 SQL 或 GC 暂停都可能误报，日志刷屏，真正泄漏反而被淹没
- 设太大（如 300000ms）：泄漏发生后要等 5 分钟才报警，线上早雪崩了
- 推荐值：2–5 分钟（
120000–300000），上线前用压测模拟典型链路耗时，取 P99 + 30% 作为基准 - 必须配合日志级别：确保
com.zaxxer.hikari日志为WARN或以上，否则泄漏日志直接被吞掉
Java 里哪些写法看着正常，其实悄悄漏了连接
泄漏往往藏在“我以为它自动关了”的地方，尤其是和流、回调、异步混用时。
-
try-with-resources看似安全，但如果Connection是从池里借的，而你又在try块里抛了未捕获异常导致后续close()没走 —— 实际上 HikariCP 的代理Connection在close()时只是归还，不是真关，所以不会爆错，但连接就卡住了 - Spring
@Transactional方法里手动调dataSource.getConnection()，事务结束后连接不会自动归还，必须显式connection.close() - CompletableFuture 异步分支里用了连接，但主线程已 return，异步线程挂掉或没执行到
close()，连接就永远滞留在池外 - MyBatis 的
SqlSession如果用的是SqlSessionFactory.openSession(false)（手动管理事务），忘了session.close()，底层连接一样不归还
迁移后为什么突然暴露泄漏，和旧环境有啥关键差异
MySQL 迁移本身不改代码逻辑，但常会放大原有隐患 —— 新库响应变慢、网络延迟升高、连接超时参数重置，都会让原本“勉强能扛”的泄漏点立刻显形。
- 新 MySQL 版本（如 8.0+）默认
wait_timeout=28800（8 小时），老版本可能是 2880（1 小时），连接空闲更久才断，泄漏连接在池里“存活”时间拉长，更容易堆积 - 如果迁移到云数据库（如阿里云 RDS、AWS RDS），中间加了代理层，
processlist显示的host可能全是内网 IP 或代理地址，查不到真实应用实例，得靠连接池监控指标反推 - 迁移时常顺手升级了驱动（如 mysql-connector-java 5.1 → 8.0），新驱动对连接生命周期更敏感，某些旧写法（比如重复 close）可能触发静默异常，中断归还流程
最麻烦的是那种“半泄漏”：连接归还了，但归还时连接已失效（比如被 MySQL 主动踢了），池子没及时剔除，下次借出就报 Connection is closed，看起来像泄漏，其实是连接健康检查没配好 —— 这个得看 connectionTestQuery 和 validationTimeout 是否匹配新库的实际行为。
