setquerytimeout() 无法单独实现oracle查询全流程超时控制，必须协同sockettimeout（毫秒级，防socket阻塞）和服务端sqlnet.inbound_connect_timeout（秒级，防认证卡死），并配合连接池有效性校验（如select 1 from dual）。
单靠 setQueryTimeout() 无法覆盖 Oracle 查询全过程的超时控制，必须配合 socketTimeout 和服务端 sqlnet.inbound_connect_timeout 才能真正防住卡死。
为什么 setQueryTimeout(30) 经常失效
这个方法只对 Statement.executeQuery() 等执行动作生效，且依赖驱动发取消指令（cancel()）——但前提是连接还活着、网络通、Oracle 监听器能响应。一旦遇到以下情况，它就完全不触发：
- 数据库实例崩溃但监听进程仍在（TCP 连得上，但认证/执行卡在内核态）
- 存储过程内部死锁或全表扫描，SQL 已发出去，但 Oracle 根本没开始返回结果
- 中间防火墙静默丢包，JDBC 等不到任何 TCP ACK，
setQueryTimeout的计时器甚至没启动
此时线程会一直阻塞在 socket read 上，除非你设置了 socketTimeout。
socketTimeout 必须显式设，且单位是毫秒
Oracle JDBC Thin 驱动默认 socketTimeout=0（无限等待），这是线上最常见线程堆积根源。它控制的是“从发送请求到收到第一个字节响应”的最大等待时间，覆盖登录、查询、LOB 读取等所有 socket 层通信。
设置方式有两种，推荐后者：
- URL 参数：
jdbc:oracle:thin:@//host:1521/orcl?oracle.jdbc.readTimeout=60000（仅 Thin 驱动有效，单位毫秒） - Connection 层设置：
connection.unwrap(OracleConnection.class).setSoTimeout(60000)（更直接，绕过驱动封装）
注意：socketTimeout 必须 > queryTimeout + cancelQueryTimeout，否则 cancel 指令可能自己先超时失败。
服务端 sqlnet.inbound_connect_timeout 是最后一道防线
客户端超时再细，也拦不住 Oracle 服务端自己卡住。比如一个连接已建立，但后续认证或首次查询被阻塞在 enq: TX - row lock contention 上，客户端 socketTimeout 可能已触发，但服务端连接仍挂着。
这个参数在数据库服务器的 $ORACLE_HOME/network/admin/sqlnet.ora 中配置：
sqlnet.inbound_connect_timeout = 120
单位是秒，它约束的是“从 TCP SYN 到完成 Oracle 登录认证”的总耗时。默认 60 秒，建议调大到 120 或 300，尤其当 DB 启用了复杂密码策略或审计规则时。
别漏掉连接池的连接有效性校验
即使单次查询加了超时，连接池里长期存活的连接也可能变成 dead connection（比如 DB 重启后旧连接未断开）。光靠 socketTimeout 不够，连接池必须主动探测：
- HikariCP：配
connection-test-query=SELECT 1 FROM DUAL+connection-timeout=3000 - Druid：配
validationQuery=SELECT 1 FROM DUAL+testOnBorrow=true（慎用，有性能损耗） - 关键点：验证 SQL 必须轻量、不走计划缓存、不触发锁 ——
SELECT 1 FROM DUAL是唯一安全选择
真正容易被忽略的是：这些验证本身也受 socketTimeout 控制。如果验证 SQL 超时，连接池会丢弃该连接并重建，而不是让它继续留在池里毒害后续请求。
