数据库连接未关闭引发堆内堆外双泄漏：堆内因resultset/preparedstatement未关致数据钉死老年代，堆外因socket缓冲区等os资源持续占用致rss上涨、gc不可回收。
数据库连接未关闭引发的内存泄漏，本质是堆内与堆外资源双重失控——不只是 Connection 对象没释放，更是 ResultSet、PreparedStatement、Socket 缓冲区、TCP 连接句柄等 JVM 无法直接管理的资源长期驻留。排查不能只盯着“有没有调 close()”，而要分层验证：先区分泄漏类型，再定位源头，最后验证修复效果。
看内存特征，快速锁定泄漏类型
堆内存和堆外内存表现完全不同，这是判断的第一步：
- 用 jstat -gc
观察老年代使用率增长缓慢或稳定，但 ps aux --sort=-rss | head -n 10 显示进程 RSS 内存持续线性上涨 → 堆外泄漏嫌疑最大 - 用 jmap -dump:format=b,file=heap.hprof
抓堆快照，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/
/maps | grep rw | awk '{sum += $3} END {print sum/1024/1024 " MB"}' ，观察可写内存映射区是否随运行时间持续增长，这是堆外缓冲区堆积的直接证据
启用并验证连接池泄漏检测
HikariCP 的泄漏检测不是配个参数就生效，必须确保它真能捕获并输出调用栈：
- 配置 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，整块查询结果（含字段名、原始字节）就钉在老年代
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
