ora-01000本质是会话级游标数超限，默认50，主因是未及时关闭statement/resultset或连接池语句缓存导致游标堆积；须用try-with-resources、禁用statementcache或调大open_cursors治本。

ora-01000 错误本质是啥？ 这不是数据库“崩了”，而是 Oracle 在每个会话里硬性限制了能同时打开的游标数量，默认值往往只有 50。一旦你的代码（比如循环里反复 createStatement()、prepareStatement() 或没关 ResultSet）没及时释放，游标就堆在内存里不退场——哪怕连接已 close，只要语句没显式关闭，游标就还挂着。查 v$open_cursor 会发现大量重复 SQL 对应同一会话，数量直逼 open_cursors 阈值，这时就报 ORA-01000。

Java 里 statement.close() 失效？检查这三处close() 看似调用了，但常因以下原因形同虚设：

• 没在 finally 块或 try-with-resources 中执行，异常一抛，close() 就跳过了
• 在 for 循环内部反复 new Statement 却只在循环外 close 一次（相当于只关了最后一个）
• 使用了连接池（如 HikariCP、DBCP），而池子启用了语句缓存（statementCacheSize > 0），这时 close() 实际只是归还到缓存，不是真销毁游标

✅ 正确做法：

• 用 try-with-resources 包住 Connection、PreparedStatement、ResultSet
• 若必须手动 close，确保每层都在独立 finally 块中，且判空（if (rs != null) rs.close();）
• 检查连接池配置，把 statementCacheSize 设为 0（尤其 WebLogic 默认是 200，极易触发问题）

改数据库参数有用吗？什么时候该动它open_cursors 是治标不治本的兜底手段，但有时不得不调：

• 查当前值：show parameter open_cursors;
• 生产环境常见安全值是 800～1200；别盲目设成 5000，虽无额外开销，但会掩盖代码缺陷
• 如果你确认应用单会话确实需要大量并发游标（如复杂报表动态拼 N 个查询），再调；否则优先修代码
• 注意：该参数需 DBA 在 init.ora 或用 ALTER SYSTEM SET open_cursors=1000 SCOPE=BOTH; 修改，重启不生效，但 SCOPE=BOTH 可热生效

C# / ODP.NET 下游标泄漏更隐蔽？禁用连接池试试 用 Oracle Instant Client + ODP.NET 时，ORA-01000 经常不是因为没关 OracleDataReader，而是连接池在背后偷偷复用连接并累积游标：

• 默认连接字符串开启连接池（Pooling=true），每个物理连接上的游标会跨多次逻辑连接持续累积
• 即使你每次都 reader.Close()、cmd.Dispose()，池子里的老连接仍持有一堆未释放游标
• ✅ 快速验证：加 Pooling=False 到连接字符串，比如：Data Source=mydb;User Id=u;Password=p;Pooling=False;
• 若游标数从 200+ 骤降到 2～3，基本锁定是池子的问题；后续应优化 SQL 复用（改用 Prepare()）、减少即席查询，而非长期关池

游标泄漏最麻烦的地方在于：它不总当场报错，可能压测跑半小时才爆，或者只在 PDB 共享环境下某个租户突然卡住——所以别等报错才查 v$open_cursor，上线前就该用 SELECT sid, user_name, COUNT(*) FROM v$open_cursor GROUP BY sid, user_name ORDER BY 2 DESC 扫一遍会话级游标分布。