ORA-01000，maximum-open-cursors 错误，是 Oracle 数据库开发中极为常见的错误。在 Java 的上下文中，当应用程序尝试打开的 ResultSet 多于数据库实例上配置的游标时，就会发生这种情况。
常见原因有：
-
配置错误
- 您的应用程序中查询数据库的线程多于数据库上的游标。一种情况是您的连接和线程池大于数据库上的游标数。
- 您有许多开发人员或应用程序连接到同一个数据库实例（可能包含许多架构），而您一起使用的连接过多。
-
解决方法：
-
光标泄漏
背景
本节介绍游标背后的一些理论以及应如何使用 JDBC。如果你不需要知道背景，你可以跳过这一步，直接进入“消除泄漏”。
什么是光标？
游标是数据库上保存查询状态的资源，特别是读取器在 ResultSet 中的位置。每个 SELECT 语句都有一个游标，PL/SQL 存储过程可以根据需要打开和使用任意数量的游标。您可以在 Orafaq 上找到有关光标的更多信息。
一个数据库实例通常服务于几个不同的模式，许多不同的用户每个都有多个会话。为此，它为所有模式、用户和会话提供了固定数量的游标。当所有游标都打开（正在使用）并且请求进入需要新游标时，请求将失败并出现 ORA-010000 错误。
查找和设置光标数
该编号通常由 DBA 在安装时配置。当前使用的光标数量、最大数量和配置可以在Oracle SQL Developer 的管理员功能中访问。从 SQL 可以设置：
ALTER SYSTEM SET OPEN_CURSORS=1337 SID='*' SCOPE=BOTH;
将 JVM 中的 JDBC 与 DB 上的游标相关联
以下 JDBC 对象与以下数据库概念紧密耦合：
- JDBC Connection 是数据库会话 的客户端表示，并提供数据库事务。一个连接在任何时候只能打开一个事务（但事务可以嵌套）
- JDBC ResultSet 由数据库上的单个游标 支持。当在 ResultSet 上调用 close() 时，光标被释放。
- JDBC CallableStatement 调用数据库上的存储过程，通常用 PL/SQL 编写。存储过程可以创建零个或多个游标，并且可以将游标作为 JDBC ResultSet 返回。
JDBC 是线程安全的：在线程之间传递各种 JDBC 对象是完全可以的。
例如，您可以在一个线程中创建连接；另一个线程可以使用此连接来创建 PreparedStatement，而第三个线程可以处理结果集。一个主要的限制是您在任何时候都不能在一个 PreparedStatement 上打开多个 ResultSet。见Does Oracle DB support multiple (parallel) operations per connection?
请注意，数据库提交发生在连接上，因此该连接上的所有 DML（插入、更新和删除）将一起提交。因此，如果要同时支持多个事务，则每个并发事务必须至少有一个 Connection。
关闭 JDBC 对象
执行 ResultSet 的典型例子是：
Statement stmt = conn.createStatement();
try {
ResultSet rs = stmt.executeQuery( "SELECT FULL_NAME FROM EMP" );
try {
while ( rs.next() ) {
System.out.println( "Name: " + rs.getString("FULL_NAME") );
}
} finally {
try { rs.close(); } catch (Exception ignore) { }
}
} finally {
try { stmt.close(); } catch (Exception ignore) { }
}
注意 finally 子句如何忽略 close() 引发的任何异常：
- 如果您只是关闭 ResultSet 而不使用 try {} catch {}，它可能会失败并阻止语句被关闭
- 我们希望允许在尝试主体中引发的任何异常传播给调用者。
如果您有一个循环，例如创建和执行语句，请记住关闭循环中的每个语句。
在 Java 7 中，Oracle 引入了 AutoCloseable interface，它用一些不错的语法糖替换了大部分 Java 6 样板。
持有 JDBC 对象
JDBC 对象可以安全地保存在局部变量、对象实例和类成员中。通常更好的做法是：
- 使用对象实例或类成员来保存在较长时间内多次重复使用的 JDBC 对象，例如 Connections 和 PreparedStatements
- 为 ResultSets 使用局部变量，因为这些变量通常是在单个函数的范围内获得、循环然后关闭的。
但是，有一个例外：如果您使用 EJB 或 Servlet/JSP 容器，则必须遵循严格的线程模型：
- 只有应用程序服务器创建线程（用于处理传入请求）
- 只有应用服务器创建连接（从连接池中获取）
- 在调用之间保存值（状态）时，必须非常小心。永远不要将值存储在您自己的缓存或静态成员中——这在集群和其他奇怪的情况下是不安全的，并且应用程序服务器可能会对您的数据做可怕的事情。而是使用有状态 bean 或数据库。
- 特别是，从不在不同的远程调用上保存 JDBC 对象（连接、结果集、PreparedStatements 等） - 让应用程序服务器管理它。 Application Server 不仅提供连接池，还缓存您的 PreparedStatements。
消除泄漏
有许多流程和工具可用于帮助检测和消除 JDBC 泄漏：
-
在开发过程中 - 及早发现错误是迄今为止最好的方法：
-
开发实践：良好的开发实践应该在软件离开开发人员办公桌之前减少软件中的错误数量。具体做法包括：
-
Pair programming，教育没有足够经验的人
-
Code reviews 因为多只眼睛比一只眼睛好
-
Unit testing 这意味着您可以通过测试工具来运行您的任何和所有代码库，这使得重现泄漏变得微不足道
- 使用existing libraries 进行连接池，而不是自己构建
静态代码分析：使用像优秀的Findbugs 这样的工具来执行静态代码分析。这会发现许多未正确处理 close() 的地方。 Findbugs 有一个 Eclipse 插件，但它也可以一次性独立运行，并集成到 Jenkins CI 和其他构建工具中
-
在运行时：
-
可持有性和提交
- 如果 ResultSet 可保持性为 ResultSet.CLOSE_CURSORS_OVER_COMMIT，则在调用 Connection.commit() 方法时将关闭 ResultSet。这可以使用 Connection.setHoldability() 或使用重载的 Connection.createStatement() 方法来设置。
-
在运行时记录。
- 在您的代码中加入良好的日志语句。这些内容应该清晰易懂，以便客户、支持人员和队友无需培训即可理解。它们应该简洁，包括打印关键变量和属性的状态/内部值，以便您可以跟踪处理逻辑。良好的日志记录是调试应用程序的基础，尤其是那些已部署的应用程序。
-
您可以将调试 JDBC 驱动程序添加到您的项目中（用于调试 - 不要实际部署它）。一个例子（我没用过）是log4jdbc。然后你需要对这个文件做一些简单的分析，看看哪些执行没有相应的关闭。如果存在潜在问题，则应突出显示打开和关闭的计数
- 监控数据库。使用 SQL Developer 的“监控 SQL”功能或Quest's TOAD 等工具监控正在运行的应用程序。 this article 中描述了监控。在监视期间，您查询打开的游标（例如从表 v$sesstat）并查看它们的 SQL。如果游标的数量在增加，并且（最重要的是）被一个相同的 SQL 语句支配，那么您就知道该 SQL 存在泄漏。搜索您的代码并查看。
其他想法
你可以使用 WeakReferences 来处理关闭连接吗？
弱引用和软引用是允许您以允许 JVM 在其认为合适的任何时间对所指对象进行垃圾收集的方式来引用对象（假设该对象没有强引用链）。
如果你将构造函数中的ReferenceQueue传递给软或弱Reference，当对象被GC'ed时，对象被放置在ReferenceQueue中（如果它发生的话）。使用这种方法，您可以与对象的最终确定进行交互，并且您可以在那一刻关闭或最终确定对象。
幻像引用有点奇怪；它们的目的只是控制终结，但你永远无法获得对原始对象的引用，因此很难在其上调用 close() 方法。
但是，尝试控制 GC 的运行时间几乎不是一个好主意（Weak、Soft 和 PhantomReferences 让您知道在对象已排队等待 GC 之后）。事实上，如果 JVM 中的内存量很大（例如 -Xmx2000m），您可能永远 GC 对象，并且您仍然会遇到 ORA-01000。如果 JVM 内存相对于您的程序要求而言较小，您可能会发现 ResultSet 和 PreparedStatement 对象在创建后立即被 GC（在您可以读取它们之前），这可能会使您的程序失败。
TL;DR：弱引用机制不是管理和关闭Statement和ResultSet对象的好方法。