数据库连接未关闭引发堆内堆外双泄漏：堆内因ResultSet/PreparedStatement未关致数据钉死老年代，堆外因Socket缓冲区等OS资源持续占用致RSS上涨、GC不可回收。
数据库连接未关闭引发的内存泄漏，本质是堆内与堆外资源双重失控——不只是 Connection 对象没释放，更是 ResultSet、PreparedStatement、Socket 缓冲区、TCP 连接句柄等 JVM 无法直接管理的资源长期驻留。排查不能只盯着“有没有调 close()”，而要分层验证：先区分泄漏类型，再定位源头，最后验证修复效果。
看内存特征，快速锁定泄漏类型
堆内存和堆外内存表现完全不同，这是判断的第一步：
- 用 jstat -gc <pid> 观察老年代使用率增长缓慢或稳定，但 ps aux --sort=-rss | head -n 10 显示进程 RSS 内存持续线性上涨 → 堆外泄漏嫌疑最大
- 用 jmap -dump:format=b,file=heap.hprof <pid> 抓堆快照，MAT 中打开 “Leak Suspects”，重点搜索 com.mysql.cj.jdbc.result.ResultSetImpl 或 PreparedStatement 实例大量堆积 → 堆内泄漏明确指向结果集未关闭
- 如果两者同时显著增长，说明存在“双泄漏”：ResultSet 钉住堆内存，底层 Socket 缓冲区占用堆外内存
查连接状态，确认物理连接是否真实堆积
连接池配置只是逻辑上限，真正占用系统资源的是操作系统级的 TCP 连接：
- 执行 ss -tulpn | grep :3306，比对 ESTABLISHED 连接数与 HikariCP 的 maxPoolSize。若前者远超后者（如 max=20，实际连了 80+），说明连接借出后未归还
- 进 MySQL 执行 SHOW PROCESSLIST，筛选 State 为 Sleep 或 Reading from net、Time > 60s 的连接——这些就是挂起未关闭的“幽灵连接”
- 在 Linux 下运行 cat /proc/<pid>/maps | grep rw | awk '{sum += $3} END {print sum/1024/1024 " MB"}'，观察可写内存映射区是否随运行时间持续增长，这是堆外缓冲区堆积的直接证据
启用并验证连接池泄漏检测
HikariCP 的泄漏检测不是配个参数就生效，必须确保它真能捕获并输出调用栈：
立即学习“Java免费学习笔记（深入）”；
- 配置 spring.datasource.hikari.leak-detection-threshold=30000（单位毫秒，建议设为业务最长耗时的 1.5 倍）
- 必须开启日志输出：spring.datasource.hikari.log-connection-warnings=true，否则即使触发也不会打印
- 一旦出现 "Connection leak detection triggered" 日志，立刻检查其后的完整堆栈，精准定位到哪一行 getConnection() 调用后没有对应归还
- 特别注意绕过连接池的直连：DriverManager.getConnection() 或手动 new PreparedStatement，这类调用完全不受池子管控，极易遗漏 close
检查代码中的资源释放逻辑
很多问题不在 Connection，而在更下游的 ResultSet 和 PreparedStatement：
- 所有使用 try-with-resources 的地方，确认是否把 ResultSet rs = stmt.executeQuery() 也纳入括号中。只声明 conn 和 stmt，漏掉 rs，就会导致结果集常驻堆中
- 避免在循环中反复创建 PreparedStatement 却不 close；复用时若内部仍强引用旧 ResultSet，缓存会越积越大
- MySQL 8.0+ 驱动默认缓存元数据和部分结果行数据，ResultSetImpl 一旦未 close，整块查询结果（含字段名、原始字节）就钉在老年代
