Oracle连接中断后应用不自动恢复，主因是防火墙或SQLNET.EXPIRE_TIME导致“假活”连接；需合理配置validationQuery及validation-timeout、max-lifetime等参数，并确保与服务端超时匹配。
oracle 连接中断后应用不自动恢复，多半不是数据库挂了，而是连接池里的连接被防火墙、中间设备或 oracle 服务端主动回收（比如 sqlnet.ora 中的 sqlnet.expire_time），导致连接变成“假活”——isvalid() 返回 true，但一执行 sql 就抛 sqlexception: closed connection 或 io exception: connection reset。光配 validationquery 不够，得看你怎么用、配什么、在哪个环节校验。
validationQuery 在 HikariCP / Druid / Tomcat JDBC 中的实际作用差异
它只在「连接借出前」或「归还时」做一次简单 SQL 执行（如 SELECT 1 FROM DUAL），不保证后续业务操作一定成功。不同连接池默认行为差别很大：
- HikariCP 默认关闭借用前校验（
connection-test-before-use=false），只靠validationTimeout和keepaliveTime维护空闲连接，validationQuery实际不生效，必须显式开启connection-test-before-use=true或改用connection-init-sql - Druid 默认开启
testOnBorrow=true，此时validationQuery=SELECT 1 FROM DUAL有效；但如果设成testOnReturn=true，高频归还会导致性能下降，且 Oracle 对短连接反复执行DUAL查询有轻微解析开销 - Tomcat JDBC Pool 的
validationQuery仅在testOnBorrow或testOnConnect为true时触发，且要求查询必须返回至少一行——SELECT 1 FROM DUAL满足，但SELECT SYSDATE FROM DUAL也行，别写成SELECT * FROM DUAL WHERE 1=0（返回空集会判失败）
Oracle 场景下 validationQuery 必须满足的三个条件
不是所有能跑通的 SQL 都适合作为验证语句。Oracle 连接池校验失败常源于语句本身不兼容当前连接状态：
- 不能含事务控制：避免
COMMIT或SAVEPOINT，否则可能干扰业务事务边界 - 不能依赖 session 级对象：比如
SELECT COUNT(*) FROM USER_TABLES在某些受限用户下权限不足，应坚持用SELECT 1 FROM DUAL - 必须兼容 Oracle 兼容模式：如果用的是 Oracle 兼容的国产数据库（如 OceanBase Oracle mode、达梦），确认
DUAL表存在且可查；部分老版本 Oracle（如 10g）对空格和大小写敏感，建议统一小写：select 1 from dual
比 validationQuery 更关键的两个配置项
单独调好 validationQuery 只是基础，真正决定连接是否“可用”的是这两个参数：
-
validationInterval（Druid）或validation-timeout（HikariCP）：控制校验超时时间，默认往往 3 秒太长，网络抖动时会卡住线程；建议设为1000（1 秒），超过即丢弃该连接 -
timeBetweenEvictionRunsMillis（Druid）或idle-timeout+max-lifetime（HikariCP）：前者控制空闲连接扫描周期，后者分别限制连接最大空闲时间和总生命周期；Oracle 默认连接空闲 30 分钟断开，所以max-lifetime建议设为1800000（30 分钟），并略小于数据库侧的SQLNET.EXPIRE_TIME（比如设为 25 分钟）
最容易被忽略的是：Oracle 服务端的 SQLNET.EXPIRE_TIME 和客户端连接池的 max-lifetime 不匹配，会导致连接在池中“自然死亡”却没被及时清理，这时哪怕 validationQuery 写得再标准也没用。
立即学习“Java免费学习笔记（深入）”；
