如何分析JDBC驱动导致的内存泄漏_排查未关闭的ResultSet与缓存的Statement-Oracle-PHP中文网

resultset 不关闭会导致堆内存泄漏。jdbc规范不保证自动释放，mysql/postgresql等驱动中未关闭的resultset会持续占用堆内存或本地缓存，尤其在预编译缓存、连接池场景下更易引发oom。

resultset 不 close 就真会吃光堆内存

java 应用跑着跑着 oom，堆 dump 里全是 sun.jdbc.odbc.jdbcodbcresultset 或 com.mysql.cj.jdbc.result.resultsetimpl 实例？八成是 resultset 没关。jdbc 规范明确要求：只要 statement 或 preparedstatement 关闭，它关联的 resultset 自动失效；但反过来说，resultset 不关，底层结果集数据（尤其是大字段、流式读取）可能长期驻留在 jvm 堆或驱动本地缓存中。

常见错误现象：

用完 ResultSet 后只调了 statement.close()，没调 resultSet.close()
在 try-with-resources 里只声明了 Connection 和 PreparedStatement，漏掉 ResultSet
catch 块里吞了异常，close() 根本没执行

实操建议：

所有 ResultSet 必须显式 close()，哪怕你确定它来自 PreparedStatement —— 不同驱动行为不一致，MySQL Connector/J 8.0+ 默认缓存结果集元数据和部分行数据，PostgreSQL 的 PGResultSet 在游标未关闭前会持有连接资源

优先用 try-with-resources，把 ResultSet、Statement、Connection 全部声明在同一语句里：

try (Connection conn = ds.getConnection();
     PreparedStatement ps = conn.prepareStatement("SELECT * FROM huge_table");
     ResultSet rs = ps.executeQuery()) {
    while (rs.next()) { /* ... */ }
} // 自动 close rs → ps → conn

别信“我用的是 HikariCP，它会自动回收”——连接池只管连接，不管结果集生命周期

Statement 缓存开关（prepareStatementCacheSize）影响内存驻留时间

MyBatis、Spring JDBC 或直连 JDBC 时启用预编译语句缓存，本质是复用 PreparedStatement 对象。但缓存本身不是问题，问题是缓存里的 PreparedStatement 如果曾生成过未关闭的 ResultSet，它的内部状态（比如 MySQL 驱动的 cachedResultSet 字段）可能仍引用着旧结果集数据。

使用场景：

Spring Boot + spring.datasource.hikari.data-source-properties.prepStmtCacheSize=25
MyBatis 开启 localCacheScope=STATEMENT 但未控制好生命周期

实操建议：

检查驱动配置项：cachePrepStmts=true（MySQL）、prepareThreshold=5（PostgreSQL），这些开启后，PreparedStatement 实例会被复用，其关联的 ResultSet 若未清理干净，会在缓存中滞留更久
避免在 long-lived service bean 中缓存 PreparedStatement 或 ResultSet 引用 —— 它们不是线程安全的，且生命周期难追踪
用 JMC 或 VisualVM 监控 com.mysql.cj.jdbc.StatementImpl 实例数，如果数量持续上涨，大概率是 close() 调用缺失或被跳过

Connection.close() 不等于 ResultSet 自动释放

很多开发者以为“只要 connection.close() 了，所有子资源就清空了”。错。JDBC 规范只要求 driver 在 Connection.close() 时尝试清理，但实际行为取决于驱动实现。MySQL Connector/J 在连接归还给 HikariCP 时，仅重置状态，不会主动遍历并 close 所有已创建的 ResultSet；Oracle 的 OracleResultSet 更是可能抛出 SQLException: Closed Connection 而不是静默释放。

性能与兼容性影响：

MySQL 5.7 驱动下，未关闭的 ResultSet 可能导致连接无法真正归还池中，触发 HikariPool$ProxyConnection 泄漏检测告警
PostgreSQL 驱动在连接 close 时若发现还有活跃游标，会发 ClosePortal 消息，但不会等响应，应用层看不到错误

实操建议：

永远不要依赖 Connection.close() 代劳 ResultSet.close()
在连接池监控页面（如 HikariCP 的 /actuator/metrics/hikaricp.connections.active）观察 active 连接数是否缓慢上涨，配合堆 dump 看 ResultSet 实例是否与连接数强相关
用字节码插桩（如 Byte Buddy）或代理数据源，在 ResultSet.close() 被跳过时打日志 —— 这比等 OOM 再查快得多

堆 dump 里怎么快速定位泄漏点

拿到 hprof 文件后，别一上来就翻“ biggest objects”。直接搜 ResultSet 类名，看哪些实例的 closed 字段为 false，再顺着它的 owner 或 statement 字段往上找调用栈。

实操建议：

Eclipse MAT 中用 OQL 查询：

SELECT s FROM com.mysql.cj.jdbc.result.ResultSetImpl s WHERE s.closed = false

注意区分 ResultSet 接口实现类 —— MySQL 是 ResultSetImpl，PostgreSQL 是 PGResultSet，Oracle 是 OracleResultSetImpl，不同驱动类名不同
重点看每个 ResultSet 的 rows 或 rowData 字段大小，如果里面装了几万条 byte[] 或 Blob，基本就是泄漏源
导出 GC root 路径，90% 情况下会指向某个 static cache map、ThreadLocal 或未关闭的 service 实例