HikariCP + Java 17 + Oracle 19c：性能瓶颈不在池子，在参数对齐
先说结论：HikariCP 在 Java 17 搭配 Oracle 19c 这套组合上，性能瓶颈几乎不会出在连接池本身。真正让你头疼的，是 maximumPoolSize、connectionTimeout 和 Oracle 驱动层几个关键参数有没有对齐。配置不对，麻烦就来了——连接卡死、超时堆积、甚至连接泄漏，而不是“慢”这种模糊问题。
驱动选择：ojdbc8 和 implicit caching 是标配
Java 17 不支持 ojdbc7，所以 ojdbc8 是唯一兼容且稳定的选择（com.oracle.database.jdbc:ojdbc8:21.10.0.0 或更高版本）。但光换驱动还不够，必须显式开启 Oracle 自身的语句缓存：
implicitCachingEnabled=true—— 启用 Oracle 客户端隐式缓存，避免 HikariCP 的cachePrepStmts与 Oracle 冗余冲突statementCacheSize=50—— 建议设在 30–100 之间，过高反而增加内存压力- 禁用
useServerPrepStmts（Oracle 不支持服务端预编译，设为true会静默降级并抛 warning）
放到具体配置上，大致是这样：
config.addDataSourceProperty("implicitCachingEnabled", "true");
config.addDataSourceProperty("statementCacheSize", "50");
maximumPoolSize 要小于 Oracle 的 processes 参数
Oracle 19c 默认 processes=300，但这是全局上限，包含后台进程、RMAN、SQL*Plus 等。真实可用给应用的通常只有 200–250。假设 HikariCP 的 maximumPoolSize 设为 50，但你有 4 个微服务实例，总连接数就可能冲到 200+，再叠加 DBA 的维护操作，很容易触发 ORA-12516 或 ORA-00020。
- 单实例推荐值：
maximumPoolSize = min(50, (Oracle processes × 0.7) ÷ 实例数) - 必须同步检查数据库侧：
SELECT * FROM v$resource_limit WHERE resource_name = 'processes'; - 别信“CPU 核数 × 2”公式——Oracle 连接开销远高于 MySQL，这个公式在 Oracle 场景下普遍偏高
超时配置：绕开 Oracle 的 sqlnet.expire_time
Oracle 19c 默认启用了死连接检测（sqlnet.expire_time=10，单位分钟），也就是空闲 10 分钟的 TCP 连接会被数据库主动断开。如果 HikariCP 的 idleTimeout 或 maxLifetime 大于 600000ms（10 分钟），连接归还后仍留在池中，下次取出时大概率报 IO Error: Connection reset 或 Socket read timed out。
idleTimeout建议设为540000（9 分钟）maxLifetime建议设为1500000（25 分钟），确保在 DB 主动 kill 前主动刷新- 务必确认数据库未设置
sqlnet.expire_time=0（禁用），否则健康检查会失效；也不要设为过小（如 60），增加无谓心跳开销
Oracle 特有的泄漏风险点：LOB 和 ARRAY 类型不自动关闭
HikariCP 的 leakDetectionThreshold 能发现连接未归还，但 Oracle 的 BLOB、CLOB、ARRAY 对象即使连接已归还，若没显式调用 .free()，底层物理连接仍被持有，最终表现为“活跃连接数持续上涨但无 SQL 执行”。
- 所有获取
oracle.sql.BLOB/CLOB的地方，必须用 try-with-resources 或手动blob.free(); clob.free(); - ORM 框架（如 MyBatis）需确认是否自动处理；Hibernate 5.6+ 已修复，但老版本需加
@Lob+ 自定义AttributeConverter - 开发期强制开启：
leakDetectionThreshold=60000（60 秒），上线前必须清零，否则影响性能
最易忽略的是：Oracle 连接池的“健康”不等于“可用”。一个连接能连上，不代表它能执行 SELECT 1 后还能读取 CLOB 字段——这种细粒度状态 HikariCP 不校验，得靠业务代码兜底。
