真正取消Oracle SQL需三者协同：驱动发cancel指令（配oracle.jdbc.cancelQueryTimeout=10）、网络通路允许RST包到达、数据库启用resource_limit=TRUE且sqlnet.expire_time≠0；ORA-01013是唯一确认服务端已处理cancel的信号。
Java里怎么真正取消正在执行的Oracle SQL
单纯调用Statement.cancel()不保证SQL真被终止——Oracle底层是否响应、驱动是否发指令、网络是否通路，三者缺一不可。很多场景下cancel只是“发了个请求”，DB端根本没收到或拒绝处理。
- 必须确保JDBC URL中包含
oracle.jdbc.cancelQueryTimeout=10（单位秒），否则cancel()可能无限等待驱动内部确认 -
queryTimeout设为30秒，cancelQueryTimeout必须小于它（比如10秒），否则cancel过程自己先超时，连接状态陷入未知 - Oracle 12c+ 要求数据库参数
resource_limit=TRUE且sql_trace=FALSE，否则cancel指令可能被忽略 - 不要在finally块里无条件调用
cancel()：如果SQL已自然结束，再cancel会抛SQLException（SQLState: 72000, ORA-1013）
ORA-01013出现时，cancel到底生效没？
ORA-01013: user requested cancel of current operation是唯一能确认cancel被Oracle接收并处理的信号。但注意：这个错误只在cancel成功后由服务端主动返回，不是客户端抛出的异常。
- 如果
cancel()调用后，executeQuery()仍长时间阻塞，说明cancel未送达或DB未响应 - 查
v$session中对应SID的EVENT字段：若仍是SQL*Net message from client，说明客户端还在等响应；若变成PGA memory bound或cursor: pin S wait on X，说明cancel已触发但资源释放卡住 - 别依赖
Thread.interrupt()：JDBC底层是native socket读写，中断线程对TCP连接无效
存储过程卡住时cancel为什么经常失效
CallableStatement.execute()挂住，大概率不是SQL没取消，而是PL/SQL引擎仍在执行循环、等待锁、或做大量内存分配。cancel指令只能中断SQL层调度，进不去PL/SQL运行时栈。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 优先用
v$session_longops查该SID的OPNAME和TIME_REMAINING，确认是否真在跑PL/SQL逻辑 - 对长时间存储过程，应在PL/SQL代码里加
DBMS_APPLICATION_INFO.SET_CLIENT_INFO打标，便于事后定位 - 避免在存储过程中做隐式类型转换或动态SQL拼接——这两类操作会让cancel延迟数秒甚至失效
- 生产环境建议对关键存储过程加
PRAGMA AUTONOMOUS_TRANSACTION拆分事务边界，降低cancel影响范围
cancel失败后最该检查的三个地方
cancel不生效时，90%的问题藏在这三层：驱动配置、网络设备、数据库参数。别急着改Java代码。
立即学习“Java免费学习笔记（深入）”；
- 检查JDBC驱动版本是否匹配数据库版本：
ojdbc8.jar连Oracle 19c没问题，但连11g可能因协议差异导致cancel静默丢弃 - 确认防火墙或F5负载均衡器没截断RST包：cancel本质是发一个TCP RST，若中间设备过滤了RST，DB永远收不到
- 查数据库
sqlnet.ora里是否有SQLNET.EXPIRE_TIME=0：设为0会禁用死连接检测，cancel指令可能被当成无效包丢弃
try-catch-cancel复杂。最容易被忽略的是：cancel不是“停止”，而是“请求停止”——它依赖整个链路的协同响应。任何一环静默失败，Java线程就卡在那里，既不报错也不返回。 
