JDBC游标超时异常分为服务端游标回收和客户端等待超时两类，需通过分层控制生命周期、强管控资源、协同调优参数及区分异常类型响应来规避。
JDBC 游标超时异常不是单一错误，而是两类典型问题的统称：一类是数据库服务端主动回收游标（如 MySQL 的服务器端游标过期、MongoDB 的 MongoCursorNotFoundException），另一类是客户端等待游标资源太久而超时（如 HikariCP 连接池拿不到连接，间接导致后续游标操作失败）。处理的关键不在于“捕获后重试”，而在于**提前规避 + 分层控制生命周期**。
明确游标超时发生的环节
先分清超时发生在哪一层，再针对性解决：
-
数据库服务端游标超时：MySQL 启用服务器端游标（
useCursorFetch=true）后，若客户端读取太慢或中断，服务端可能在几秒到几分钟内关闭游标；Oracle 中游标长期未关闭也会被会话级限制拦截；MongoDB 默认 10 分钟无getMore即销毁游标。 -
JDBC 执行层超时：PreparedStatement 设置了
setQueryTimeout()，SQL 执行超过阈值抛出SQLTimeoutException。 -
连接池层阻塞超时：HikariCP 的
connection-timeout触发时，连获取 Connection 都失败，自然无法创建 Statement 或游标，报TimeoutException。
从代码层预防游标泄漏和空闲超时
多数“超时”本质是游标没及时关闭或长时间闲置。Java 侧必须做到资源强管控：
- 使用
try-with-resources包裹Connection、PreparedStatement、ResultSet，确保即使发生异常也能自动关闭； - 避免在循环中反复创建 PreparedStatement 却不 close —— 特别是在批量游标分页（如
WHERE id > ? ORDER BY id）时，每个分页应复用同一 PreparedStatement 实例； - 对长耗时流式读取（如百万级结果集），禁用默认的
fetchSize = 0（全缓存），改用setFetchSize(Integer.MIN_VALUE)触发 MySQL 真正的流式游标，并配合useServerPrepStmts=false防止预编译干扰； - 若需跨线程消费 ResultSet（如提交给异步任务），必须显式调用
resultSet.getStatement().getConnection().setNetworkTimeout()延长网络空闲容忍时间，或改用一次性拉取+内存分片处理。
服务端与连接池协同调优
单靠 Java 代码不够，需数据库和连接池参数对齐：
立即学习“Java免费学习笔记（深入）”；
- MySQL：设置
wait_timeout和interactive_timeout≥ 应用最长单次查询预期耗时（如设为 600 秒），并确认应用连接 URL 含useCursorFetch=true&defaultFetchSize=-2147483648（即Integer.MIN_VALUE）； - Oracle：检查
open_cursors是否被单个会话占满，用v$open_cursor定位泄漏源；若确需提高上限，同步调整应用层最大并发游标数，避免掩盖代码问题； - HikariCP：设
connection-timeout=30000（30 秒）、idle-timeout=600000（10 分钟）、max-lifetime=1800000（30 分钟），避免连接老化后游标失效；启用leak-detection-threshold=60000可主动发现未关闭 Statement/ResultSet。
异常发生时的响应策略
真遇到游标超时异常，不要静默重试——要区分场景做不同处理：
- 捕获
SQLTimeoutException：说明 SQL 执行太久，应记录慢 SQL、检查索引、拆分逻辑，而非简单重试； - 捕获
MySQLNonTransientConnectionException或CommunicationsException（含 “cursor not found” 字样）：大概率是服务端游标已销毁，此时应终止当前流式读取，从上一个游标位置（如最后读到的主键 ID）重新发起分页查询； - 捕获 HikariCP 的
TimeoutException：说明连接池枯竭，需立即限流、降级或告警，而不是重试——重试只会加剧拥塞。
