Oracle数据库IDLE_TIME配置会强制终止空闲连接，导致JDBC连接池在首次执行SQL时抛出SQLRecoverableException: IO Error: Connection reset；需用DBA账号查询DBA_PROFILES确认限制值，临时可重置用户profile，长期应调整对应profile的IDLE_TIME并配合连接池心跳机制（如HikariCP的keepalive-time与validation-timeout）协同防御。
检查Oracle数据库端IDLE_TIME配置
oracle用户配置中的idle_time会强制终止空闲连接，而jdbc连接池若未及时使用该连接，就会在首次执行sql时触发sqlrecoverableexception: io error: connection reset。这不是网络问题，而是服务端主动踢掉的“合法断连”。
- 用DBA账号查当前用户的资源限制：
SELECT LIMIT FROM DBA_PROFILES p JOIN DBA_USERS u ON p.PROFILE = u.PROFILE WHERE u.USERNAME = 'YOUR_USER' AND p.RESOURCE_NAME = 'IDLE_TIME'; - 若返回
UNLIMITED以外的数值（如30），说明空闲30分钟后连接会被KILL - 临时绕过：用
ALTER USER your_user PROFILE DEFAULT;重置为默认profile（通常IDLE_TIME=UNLIMITED） - 长期方案：修改对应profile：
ALTER PROFILE your_profile LIMIT IDLE_TIME UNLIMITED;（需评估安全策略是否允许）
连接池必须启用有效的心跳检测
光靠testOnBorrow或validationQuery不够——如果验证查询发出去时连接已被Oracle关闭，仍会抛出Connection reset。关键是要在连接被回收前、且尚未被服务端销毁时主动探测。
- HikariCP推荐组合：
connection-test-query=SELECT 1 FROM DUAL+validation-timeout=2000+keepalive-time=30000（注意不是idle-timeout） - Druid需显式开启：
test-while-idle=true+time-between-eviction-runs-millis=30000+min-evictable-idle-time-millis=60000（确保驱逐周期短于IDLE_TIME） - 避免用
SELECT SYSDATE FROM DUAL这类可能受NLS影响的语句，SELECT 1 FROM DUAL最轻量、最稳定 - 不要依赖
testOnReturn：它发生在归还连接池之后，此时异常已无法拦截到业务线程
为什么TCP KeepAlive不能替代数据库心跳
操作系统级的TCP KeepAlive只探测链路层是否存活，对Oracle监听器和PMON进程无感知。即使KeepAlive成功，Oracle仍可能因IDLE_TIME或SQLNET.EXPIRE_TIME在应用层断开连接。
-
SQLNET.EXPIRE_TIME=10（单位分钟）会让服务端每10分钟发一次探测包，但这是单向的，且不保证客户端能及时响应 - JVM启动参数
-Dsun.net.client.defaultReadTimeout=30000只影响HTTP类连接，对Oracle JDBC Thin驱动无效 - 真正起作用的是连接池自身的保活机制：它在连接被借出前完成一次完整往返（connect → query → close cursor），覆盖了网络、监听器、实例三层面
容易被忽略的时区与随机数陷阱
某些Linux服务器在低熵环境下，Oracle JDBC驱动初始化SSL握手时卡在/dev/random读取，超时后连接直接reset——现象是启动阶段偶发失败，且仅出现在特定机器。
- 确认是否触发此问题：
strace -e trace=open,read java -jar your-app.jar 2>&1 | grep random，若看到阻塞在/dev/random则命中 - 安全修复方式（非软链接）：
-Djava.security.egd=file:/dev/./urandom加到JVM参数，比修改java.security文件更可控 - Spring Boot用户可在
application.yml中配spring.jmx.enabled=false减少初始化时的随机数消耗（JMX默认启用SecureRandom）
IDLE_TIME在等你，也可能是/dev/random在拖后腿，更可能是连接池没抢在PMON之前发出那条SELECT 1 FROM DUAL。盯住这三个点，比盲目调大超时更有用。 
