HikariCP 在 Oracle 中不支持 keepaliveTime 或 keepalive-time，真正有效的是 connection-test-query（设为 SELECT 1 FROM DUAL）、validation-timeout（建议 3000ms）、max-lifetime（须比 sqlnet.expire_time 小至少 2 分钟）和 minimum-idle > 0（触发周期性健康检查）。
keepalivetime 不是 hikaricp 的有效配置项 —— oracle 场景下它根本不存在，也不起作用。
HikariCP 官方从 v4.0.3 开始支持的是 keepalive-time（带连字符），且仅对 MySQL 8.0.23+ 及部分 PostgreSQL 驱动有实际效果；Oracle JDBC 驱动（ojdbc8.jar 或 ojdbc11.jar）至今不支持该参数，设了也白设。
真正起效的，是连接池自身的健康检查机制 + 数据库端配合，而不是靠“保活心跳”。
connection-test-query 在 Oracle 中必须显式配置
Oracle 没有像 MySQL 那样的轻量级 SELECT 1，它的标准健康检测语句是：
SELECT 1 FROM DUAL
立即学习“Java免费学习笔记（深入）”；
- 如果不配
connection-test-query，HikariCP 默认用isValid(1)方法检测连接，但 Oracle 的isValid实际会发一次 TCP 探测，在连接已断但 TCP 状态未及时更新时可能返回 true，导致脏连接被误用 - 显式配置后，每次从池中取连接前都会执行该 SQL，失败则丢弃并重建
- 注意：Spring Boot 2.4+ 默认禁用
connection-test-query，必须手动打开
spring:
datasource:
hikari:
connection-test-query: SELECT 1 FROM DUAL
validation-timeout: 3000
-
validation-timeout建议设为 3000ms，避免慢查询拖垮连接获取 - 不要设成 0 或过长（如 10s），否则阻塞线程
max-lifetime 必须比 Oracle 的 sqlnet.expire_time 小至少 2 分钟
Oracle 服务端若启用了 Dead Connection Detection（DCD），通常通过 sqlnet.ora 中的：
SQLNET.EXPIRE_TIME = 10（单位：分钟）
这意味着空闲 10 分钟的连接会被服务端主动 RST。
- 若 HikariCP 的
max-lifetime设为默认的 1800000ms（30 分钟），就远超 DCD 时限，连接大概率在归还池中时已被 Oracle 关闭 - 正确做法是：
- 查清数据库侧的
SQLNET.EXPIRE_TIME（联系 DBA 或查$ORACLE_HOME/network/admin/sqlnet.ora） - 将
max-lifetime设为(EXPIRE_TIME × 60 − 120) × 1000，例如 EXPIRE_TIME=10 → 设max-lifetime: 588000（9.8 分钟）
- 查清数据库侧的
spring:
datasource:
hikari:
max-lifetime: 588000
idle-timeout: 600000
-
idle-timeout可设为略大于max-lifetime，避免空闲连接早于生命周期被踢出
minimum-idle > 0 是健康检查生效的前提
HikariCP 的后台“连接回收线程”只在 minimum-idle > 0 时才定期扫描空闲连接并验证。
- 若设
minimum-idle: 0（常见于低流量场景），空闲连接永远不会被检测，断连后只能等下次业务请求触发失败再重建 —— 这不是“自动重连”，是“被动兜底” - 生产环境建议设为
minimum-idle: 2~5，确保池中始终有少量常驻连接接受周期性验证
spring:
datasource:
hikari:
minimum-idle: 3
maximum-pool-size: 15
- 不必和
maximum-pool-size拉平，Oracle 连接资源较重，保持适度弹性更稳妥
Oracle 的连接失效往往发生在网络抖动、防火墙超时或 RAC 节点切换后，这些场景下没有真正的“TCP keepalive 级别保活”，只有靠连接池主动探测 + 合理生命周期控制。别信 keepaliveTime 这类拼写错误或版本错配的参数，它们在 Oracle 上既不生效，也不报错，最容易让人误以为“已经配好”。
