Oracle连接超时需分三层排查：客户端网络层（如防火墙、TCP连接）、JDBC驱动层（socketTimeout必须显式设置且大于queryTimeout）、数据库服务端（sqlnet.inbound_connect_timeout控制总认证时长，默认60秒）。
oracle连接超时不是改一个参数就能解决的，它至少横跨客户端网络层、jdbc驱动层、数据库服务端三层。单纯调大 logintimeout 可能完全无效，因为卡住的位置根本不在连接建立阶段。
ORA-12170 出现时，loginTimeout 基本不起作用
当看到 ORA-12170: TNS:Connect timeout occurred 或客户端卡在 “Connecting” 状态 60 秒后失败，问题大概率出在 Oracle 客户端底层 TCP 连接环节，而非 JDBC 驱动的登录逻辑。此时 DriverManager.setLoginTimeout(30) 不会生效——驱动甚至还没开始走认证流程，就被网络或服务端拦截了。
-
sqlnet.inbound_connect_timeout（服务端 sqlnet.ora）才是控制“从发起 TCP SYN 到完成 Oracle 认证”总时长的关键，默认 60 秒，建议设为120或300 - 防火墙、负载均衡器（如 F5、Nginx）的空闲超时设置常为 60 秒，若未透传或未启用 keepalive，也会触发该错误
- JDBC URL 中加
?connectTimeout=30000对 thin 驱动无效（Oracle 官方明确不支持），别白费力气
socketTimeout 必须显式设置，且要大于 queryTimeout
很多线上死锁、线程堆积问题，根源是 socketTimeout=0（默认值）。一旦数据库进程僵死、网络中断或中间设备静默丢包，JDBC 会无限等待 socket read 返回，线程永远卡住。
-
socketTimeout是 TCP 层级的读超时（单位：毫秒），适用于所有通信，包括登录响应、结果集传输、LOB 流读取 -
queryTimeout是 SQL 执行级超时（单位：秒），只对Statement.executeQuery()等操作生效，超时后驱动发取消指令，但不关闭连接 - 必须确保：
socketTimeout > (queryTimeout + cancelQueryTimeout)，否则可能在 cancel 过程中就触发 socket 断连，导致状态不可控 - 推荐组合：
socketTimeout=60000、queryTimeout=30、cancelQueryTimeout=10
存储过程长时间运行，光调超时没用
如果 CallableStatement.execute() 卡住，大概率不是超时设置太小，而是存储过程本身存在隐式锁等待、全表扫描、大事务回滚段争用等问题。盲目加大 queryTimeout 只会让故障更隐蔽。
- 先确认是否真卡在 DB：用
v$session查该 SID 的EVENT和SQL_ID，看是否在等enq: TX - row lock contention或db file sequential read - JDBC 层可加
oracle.jdbc.readTimeout=30000（仅对 thin 驱动有效，单位毫秒），但它只管“接收响应”的耗时，不管存储过程内部执行 - 避免在事务中混合 DML 和长耗时存储过程调用；超时后务必手动
connection.rollback()，否则连接池归还的连接可能带着未提交变更
Java 启动慢 / 连接时快时慢，检查 /dev/random 阻塞
Oracle 11g+ JDBC 驱动初始化时需强随机数，若 JVM 使用 /dev/random 且系统熵池不足（常见于虚拟机、容器），会导致连接建立随机延迟几十秒甚至卡住。
立即学习“Java免费学习笔记（深入）”；
- 验证方式：启动时加
-Djava.security.debug=securerandom，看日志是否卡在SecureRandom初始化 - 临时修复：JVM 启动参数加
-Djava.security.egd=file:/dev/urandom - 永久修复：修改
$JAVA_HOME/jre/lib/security/java.security中的securerandom.source行为file:/dev/urandom - 注意：此问题与超时参数无关，但会伪装成“连接超时”，排查时容易误判
真正难处理的不是参数本身，而是超时发生后连接状态的不确定性——驱动可能已发 cancel 但服务端未响应，连接池可能回收了半残缺连接，而应用层还在用它做后续操作。这类边界情况必须靠主动 rollback + 连接有效性校验（如 isValid(2)）来兜底，不能依赖超时机制自动清理。
