HikariCP在Java 17+Oracle 19c下性能瓶颈不在池本身，而在于maximumPoolSize、connectionTimeout及Oracle驱动参数（implicitCachingEnabled=true、statementCacheSize=50、useServerPrepStmts=false）未对齐，且需匹配数据库processes限制并规避sqlnet.expire_time。
Java 17 + Oracle 19c 下，HikariCP 本身几乎不会成为性能瓶颈；真正卡住连接、拖慢响应、引发 ORA-12516/ORA-00020 的，是 maximumPoolSize、Oracle 驱动参数和数据库侧资源限制三者的错配。
必须用 ojdbc8 并启用 implicitCachingEnabled=true
ojdbc7 在 Java 17 上无法加载，ojdbc8（如 com.oracle.database.jdbc:ojdbc8:21.10.0.0）是唯一兼容且稳定的选择。光换驱动不够，Oracle 自身的语句缓存必须显式打开：
-
implicitCachingEnabled=true：启用客户端隐式缓存，避免与 HikariCP 的cachePrepStmts冗余冲突 -
statementCacheSize=50：设在 30–100 之间，过高会吃内存，过低起不到效果 -
useServerPrepStmts=false：Oracle 不支持服务端预编译，设为true会静默降级并打 warning，还可能干扰绑定变量行为
这些必须通过 config.addDataSourceProperty() 设置，拼在 JDBC URL 里无效。
maximumPoolSize 要小于 (processes × 0.7) ÷ 实例数
Oracle 的 processes 是全局上限，包含后台进程、RMAN、SQL*Plus 等。真实能分给应用的通常只有 200–250。如果你设 maximumPoolSize=50，又部署了 4 个实例，总连接数就可能冲到 200+，再叠加 DBA 维护操作，极易触发 ORA-12516（监听器无可用处理器）或 ORA-00020（最大进程数已达）。
- 单实例推荐值：
maximumPoolSize = Math.min(50, (processes × 0.7) / instanceCount) - 务必查数据库确认：
SELECT * FROM v$resource_limit WHERE resource_name = 'processes'; - 别信 “CPU 核数 × 2” 公式——Oracle 连接开销远高于 MySQL，该公式在此场景下普遍偏高
idleTimeout 和 maxLifetime 必须绕开 sqlnet.expire_time
Oracle 19c 默认启用死连接检测：sqlnet.expire_time=10（单位分钟），即空闲 10 分钟的 TCP 连接会被数据库主动断开。若 HikariCP 的 idleTimeout 或 maxLifetime 大于这个值，连接会在归还池后被 DB 端悄无声息地 kill，下次取出时抛 SQLException 或卡住。
-
idleTimeout建议设为540000（9 分钟） -
maxLifetime建议设为1500000（25 分钟） - 这两个值必须严格小于
sqlnet.expire_time × 60000，留出缓冲余量
connection-test-query 必须改成 SELECT 1 FROM DUAL
HikariCP 默认用 connection-test-query=SELECT 1，但在 Oracle 下会直接报 SQLSyntaxErrorException，导致连接池初始化失败或连接被误判为失效。这不是驱动 bug，而是 Oracle 遵循 SQL 标准更严格——DUAL 是唯一保证存在的单行表。
- 正确配置：
connection-test-query=SELECT 1 FROM DUAL - 更稳妥的做法是关掉它（不设该参数），改用
validation-timeout=5000+idle-timeout+max-lifetime组合保活 - 注意：
isValid()在 HikariCP 5.0+ 已默认启用，无需额外配connection-test-query
最容易被忽略的是：LOB/ARRAY 类型结果集必须显式调用 .free()，否则连接归还后仍持有大对象句柄，造成连接泄漏和内存缓慢增长——这和 HikariCP 参数无关，但会彻底掩盖你调优的所有努力。
