ora-01000错误是oracle游标泄漏的典型表现，根源在于resultset、statement未按rs→stmt→conn顺序显式关闭，尤其在存储过程返回refcursor、流式读取或ojdbc8延迟释放机制下更易发生。
oracle游标泄漏的典型表现就是ora-01000错误
当应用跑一阵子后突然抛出 ora-01000: maximum open cursors exceeded，基本可以确定是 resultset 或 statement 没关干净。oracle 服务端对每个会话维护游标句柄，java 客户端不显式关闭，这些句柄不会自动归还——jdbc 驱动只负责转发，不代管生命周期。
常见错误现象包括：连接池里连接复用后报错、同一事务内多次查询后失败、甚至应用重启后仍短暂报错（因为 Oracle 端游标未超时释放）。
- 别依赖
try-with-resources就万事大吉：如果ResultSet是从存储过程OUT SYS_REFCURSOR返回的，驱动可能返回包装类，close()调用未必真正触达底层游标 - 别在
catch块里提前 return：一旦跳过finally，资源就漏了 - 别把
Connection.close()当万能兜底：它不保证级联关闭所有关联的Statement和ResultSet，尤其在 Oracle JDBC 12c+ 的某些版本中行为不一致
finally块里必须按 ResultSet → Statement → Connection 顺序关闭
关闭顺序不是风格问题，而是 Oracle JDBC 驱动的实际约束：反序关闭（比如先关 Statement 再关 ResultSet）可能触发 SQLException，且游标未必释放成功。驱动内部对游标引用计数依赖这个链路。
实操建议：
- 每个
ResultSet、Statement、Connection变量都声明为null初始化，避免空指针干扰判断 - 在
finally块里分别判空再调用close()，不要合并成一行（如rs != null && rs.close()）——close()抛异常时后续不会执行 - 对存储过程返回的
ResultSet，务必确认它来自CallableStatement的getResultSet()，而不是手动executeQuery()；前者更易漏关
示例片段：
立即学习“Java免费学习笔记（深入）”；
ResultSet rs = null;
Statement stmt = null;
Connection conn = null;
try {
conn = dataSource.getConnection();
stmt = conn.createStatement();
rs = stmt.executeQuery("SELECT * FROM emp");
// 处理结果
} finally {
if (rs != null) try { rs.close(); } catch (SQLException ignored) {}
if (stmt != null) try { stmt.close(); } catch (SQLException ignored) {}
if (conn != null) try { conn.close(); } catch (SQLException ignored) {}
}Spring JDBC 或 MyBatis 下游标泄漏更隐蔽
框架封装会掩盖资源管理细节。比如 Spring 的 JdbcTemplate 默认会关闭 ResultSet 和 Statement，但前提是：你没在回调里持有引用、没用 setFetchSize() 开启流式读取、也没在 RowCallbackHandler 中抛出未捕获异常导致清理逻辑跳过。
MyBatis 更容易踩坑：当使用 <select resultmap="..."></select> 并配置 fetchSize="-2147483648"（即 Integer.MIN_VALUE）启用游标流式读取时，必须手动调用 ResultSet.close() —— MyBatis 不接管这种场景下的生命周期。
- 检查
application.properties是否设置了spring.datasource.hikari.leak-detection-threshold=60000，能提前暴露未关闭资源 - 在 Oracle 数据库侧查
v$open_cursor，过滤你的应用用户，确认哪些 SQL 对应高游标数 - 禁用连接池的
auto-commit后，事务中多个Statement共享一个物理连接，游标泄漏风险指数上升
Oracle JDBC 驱动版本影响 close() 的实际效果
ojdbc8（12.2.0.1+）开始，ResultSet.close() 在部分场景下只是标记“逻辑关闭”，真实释放延迟到 Statement.close() 或 GC 时——这和 ojdbc6/7 行为不一致，容易误判已修复。
关键参数差异：
-
oracle.jdbc.autoCommitSpecCompliant=false（默认 true）：设为 false 可让close()更激进地释放游标，但可能破坏事务语义，慎用 -
oracle.jdbc.useFetchSizeWithLongColumn=true：开启后长字段（CLOB/BLOB）读取会额外占用游标，必须确保对应ResultSet显式关闭 - 驱动升级后务必验证：相同代码在 ojdbc8 下游标数比 ojdbc6 高 2–3 倍，很可能是新版本延迟释放机制导致
最稳妥的做法，是把游标释放当作“脏活”来写：宁可多关一次，不省一行 if (x != null) x.close()。
复杂点在于，有些 ORM 或数据访问层会在你不知情的地方缓存 ResultSet 引用，或者用代理包装了原始对象。这时候光看自己写的 finally 块没用，得结合数据库监控和驱动日志（开 oracle.jdbc.Trace=true）才能定位真实泄漏点。
