Java数据库连接未正确关闭会引发堆内与堆外双泄漏：堆内因ResultSet/PreparedStatement未关致数据钉死老年代，堆外因Socket缓冲区等OS资源持续占用导致RSS上涨、GC不可回收。
Java 数据库连接未正确关闭，表面看只是“连不上库”或“获取连接超时”，实际会引发堆内与堆外双线程泄漏——它不单是 Connection 对象没释放，而是背后一整套操作系统级资源被长期占用，JVM 垃圾回收器完全无权处理。
堆内存泄漏：ResultSet 和 PreparedStatement 没关，数据钉死在老年代
很多开发者只 close 了 Connection，却漏掉 ResultSet 和 PreparedStatement。MySQL 8.0+ 驱动默认缓存元数据和部分结果集行数据，ResultSetImpl 对象一旦没 close，整块查询结果（含字段名、类型、原始字节）就常驻堆中。PreparedStatement 复用时若内部还强引用旧 ResultSet，缓存越积越大，MAT 分析常看到大量 com.mysql.cj.jdbc.result.ResultSetImpl 占满老年代。
- 用 jmap -dump:format=b,file=heap.hprof <pid> 抓堆快照，MAT 中点 “Leak Suspects” 直接定位
- 检查所有 try-with-resources 是否漏写 rs：比如只声明了 conn 和 stmt，却没把 ResultSet rs = stmt.executeQuery() 加进括号里
- 避免手动 new PreparedStatement 或 DriverManager.getConnection() —— 绕过连接池等于放弃自动回收保障
堆外内存泄漏：Socket 缓冲区、连接句柄持续堆积
当 RSS 内存（ps aux --sort=-rss）持续上涨，但 jstat 显示堆内存稳定，问题大概率在堆外。Connection 背后绑定的 Socket、TCP 接收/发送缓冲区、Netty DirectBuffer 等资源由操作系统管理，JVM 不感知。这些资源不释放，就会表现为：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- ss -tulpn | grep :3306 显示 ESTABLISHED 连接数远超 HikariCP 的 maxPoolSize
- MySQL 执行 SHOW PROCESSLIST，出现大量 Sleep 或 Reading from net 状态，说明连接借出后没归还
- /proc/<pid>/maps | grep rw 发现可写映射区（如 anon_inode:[eventpoll] 或 socket:[xxx]）线性增长
HikariCP 泄漏检测必须真启用，不能只配参数
leak-detection-threshold=60000 只是配置，不等于生效。这个阈值单位是毫秒，建议设为业务逻辑预期最大耗时的 1.5 倍（比如通常 2 秒完成，就设 30000）。开启后，一旦某连接持有超时，日志会出现 Connection leak detection triggered，并附带完整调用栈，精准到哪一行 getConnection() 没还。
立即学习“Java免费学习笔记（深入）”；
- 配合 spring.datasource.hikari.log-connection-warnings=true，让警告真正输出
- 不要依赖“反正连接池会自动回收”——泄漏检测是兜底手段，不是替代规范编码
正确释放的最小实践：try-with-resources 必须声明全
不是“用了 try-with-resources 就安全”，而是必须把所有 AutoCloseable 资源一次性声明进去：
- Connection、PreparedStatement、ResultSet 三者缺一不可
- 声明顺序无关关闭安全，但要注意依赖关系：比如 BufferedInputStream 应后声明，确保它先于底层 FileInputStream 关闭
- 自定义资源实现 AutoCloseable 时，close() 方法必须幂等、不抛未捕获异常，否则可能中断后续资源关闭
