CallableStatement.close()必须显式调用，因ResultSet.close()仅清空本地缓存，不释放Oracle服务端游标；只有cs.close()才发送CLOSE CURSOR请求，且需在finally中独立判空关闭，避免漏关或反序导致游标泄漏。
CallableStatement.close() 必须显式调用，不能依赖 ResultSet.close()
从 oracle 存储过程返回 ref cursor 时，resultset 是由 callablestatement 派生出来的包装对象，它本身不持有游标句柄——真正占用服务器端游标的，是背后的 callablestatement 实例。调用 rs.close() 通常只是清空本地结果集缓存，**不会触发对底层游标的释放**；只有 cs.close() 才会向 oracle 发送真正的 close cursor 请求。
常见错误现象包括：代码里关了 ResultSet 却漏掉 CallableStatement、或在 catch 块中提前 return 导致 cs.close() 被跳过、或误以为连接池归还 Connection 就能级联关闭所有语句。
-
CallableStatement必须和ResultSet一样，在 finally 或 try-with-resources 中显式 close - 若存储过程有多个 OUT
REF CURSOR参数，每个都对应一个独立的ResultSet，但它们共享同一个CallableStatement生命周期——关一次cs.close()即可释放全部关联游标 - 不要在
cs.getResultSet()后立即rs.close()然后继续用cs获取下一个结果集；getResultSet()是“单次消费”，重复调用会返回 null，且旧结果集已失效
try-with-resources 无法自动管理 CallableStatement 的典型场景
当 CallableStatement 不是在当前方法内创建，而是由上层传入、或通过工厂方法获取（例如 Spring 的 JdbcTemplate#call() 回调、自定义 DAO 工具类封装），那么 try-with-resources 就覆盖不到它的生命周期。此时资源管理权已脱离当前作用域，容易脱节。
使用场景举例：DAO 方法接收一个已打开的 Connection，再基于它创建 CallableStatement 并执行；或者用 HikariCP 连接池 + 自定义语句缓存逻辑，CallableStatement 被复用多次。
- 传入的
CallableStatement必须由调用方负责关闭，被调用方不得假设它会被自动清理 - 若封装了存储过程调用工具类，应在文档中明确标注“调用者需确保
CallableStatement关闭”，并在内部避免持有长期引用 - Spring 的
SimpleJdbcCall默认不缓存CallableStatement，但若手动配置了setStatementsCacheSize(n)，则需确认缓存策略与连接池行为是否兼容（尤其 ojdbc8 的 implicit caching 可能干扰）
Oracle 驱动版本对 CallableStatement 关闭行为的影响
ojdbc8（12.2.0.1+）默认开启 implicitCachingEnabled=true，它会在 Connection 内部缓存 CallableStatement 对象以提升复用性能。但这个缓存只在 Connection 级别有效——一旦连接被归还给池，缓存即失效；而如果 cs.close() 被跳过，缓存条目不会被清除，下次复用该连接时可能拿到一个“脏”的语句对象，导致游标未释放或状态错乱。
错误表现：同一连接反复执行相同存储过程后，v$open_cursor 中出现大量重复 sql_id，且 LOADS 和 INVALIDATIONS 计数异常升高。
- 生产环境建议显式禁用隐式缓存：
jdbc:oracle:thin:@host:port:SID?implicitCachingEnabled=false&cacheSize=0 - 若必须启用缓存，请确保每次
cs.close()都成功执行，并在连接归还前调用conn.clearStatementCache() - ojdbc6 及更早版本无此机制，但存在另一问题：
cs.close()在某些异常路径下可能静默失败（如网络中断时），因此仍需在 finally 中判空 + try-catch
最容易被忽略的关闭顺序与空指针陷阱
即使写了 cs.close()，如果放在 Connection.close() 之后，或和 rs.close() 合并在一行判空（如 rs != null && rs.close()），就可能因异常中断后续执行，导致游标实际未释放。
关键点在于：Oracle JDBC 驱动内部对游标句柄的引用计数依赖 ResultSet → CallableStatement → Connection 的释放链路。反序或跳过任一环，都可能让服务端游标滞留。
- 每个变量声明为
null初始化：CallableStatement cs = null;，避免局部变量逃逸干扰判空 - finally 中必须分三段独立判空 + close：
if (rs != null) try { rs.close(); } catch (SQLException ignored) {}，不可合并 - 不要在
cs.close()后再调用cs.getResultSet()或任何其他方法，驱动可能抛SQLException: Closed Statement
CallableStatement.close() 很容易变成一个看似执行了、实则被吞掉的空操作。Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
