连接池未关闭本质是socket缓冲区、resultset数据等堆外资源持续驻留，需分层排查：先依rss与堆内存增长特征区分泄漏类型，再通过hikaricp检测、show processlist、ss/lsof锁定源头，最后验证resultset/statement释放逻辑。
连接池未正确关闭，不是简单“连不上数据库”这么表面——它会触发一连串底层资源失控，最终演变成堆内堆外双泄漏。关键不在连接对象本身，而在它背后绑定的 Socket、缓冲区、结果集数据这些 JVM 不直接管理的资源。
堆内存涨得快？先查 ResultSet 和 Statement
很多泄漏其实卡在“只关 Connection，不关 ResultSet”。MySQL 8.0+ 驱动默认缓存元数据和部分行数据，ResultSetImpl 对象一旦没 close，整块结果集就钉在堆里。PreparedStatement 复用时若内部还强引用着旧 ResultSet，缓存越积越大，MAT 里能看到大量 com.mysql.cj.jdbc.result.ResultSetImpl 占据老年代。
- 用 jmap -dump:format=b,file=heap.hprof
抓堆转储，MAT 中按 “Leak Suspects” 快速定位 - 检查所有 try-with-resources 是否漏写了 ResultSet：比如只声明了 Connection 和 PreparedStatement，却没把 rs 加进去
- 避免手动 new PreparedStatement 或 DriverManager.getConnection()，绕过连接池等于放弃自动回收保障
RSS 持续上涨但堆很稳？盯死网络层
这时候大概率是堆外泄漏：Linux 进程 RSS 内存（ps aux --sort=-rss）不断攀升，jstat 却显示老年代平静如水。本质是 Socket 缓冲区、Netty DirectBuffer、Jedis 的本地连接句柄没释放。
- 执行 ss -tulpn | grep :3306，看 ESTABLISHED 连接数是否远超 HikariCP maxPoolSize
- 进 MySQL 执行 SHOW PROCESSLIST，留意大量 Sleep 或 Reading from net 状态——说明连接借出去就没还
- 查 /proc/
/maps | grep rw ，如果可写映射区线性增长，基本锁定堆外资源堆积
HikariCP 泄漏检测不是摆设，要真开
光配个 leak-detection-threshold=60000 不够，得让它真正触发并输出调用栈。这个阈值单位是毫秒，建议设为连接预期最大持有时间的 1.5 倍（比如业务逻辑通常 2 秒内完成，就设 30000）。
- 日志出现 Connection leak detection triggered 时，会打印完整堆栈，精准到哪一行 getConnection() 没还
- 配合 spring.datasource.hikari.log-connection-statement 开启连接日志，记录每次获取/归还动作
- 别依赖“反正有超时”，leak-detection 是主动兜底，超时只是被动回收，两者必须共存
Redis 连接池泄漏常被低估
JDBC 漏了还能查 SQL，Redis 漏了更难察觉。高频场景有三类：Jedis 实例用完没 close、Redisson 的 RLock 或监听器没显式取消、SCAN 迭代器没 close。
- JedisPool 要确保每次 jedis.close()，不是 returnResource（旧 API 已废弃）
- Redisson 使用 RLock 时，必须配对 lock.unlock()，且最好加 try-finally，防止异常跳过
- SCAN 场景下，ScanIterator 是有状态的，不用了必须调 close()，否则游标资源一直占着
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
