UCP连接池不直接提速，但正确配置可显著减少连接开销、避免冷启动抖动、支撑高并发；错配connectionFactoryClassName、initialPoolSize为零或事务中误用getPhysicalConnection会导致性能恶化甚至启动失败。
ucp 连接池本身不直接“提速”，但能显著减少连接建立开销、避免冷启动抖动、支撑高并发请求——前提是配置不踩坑。错配 setconnectionfactoryclassname 或漏设 setinitialpoolsize，反而会让响应更慢。
必须显式设置 connectionFactoryClassName
UCP 初始化时若没调用 setConnectionFactoryClassName，会直接抛 java.lang.IllegalStateException: connection factory class name is not set。这不是警告，是启动失败级错误。
- 正确写法：
pool.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource") - 别写成
"oracle.jdbc.driver.OracleDriver"——那是 Driver 类，UCP 无法实例化 DataSource，运行时报ClassNotFoundException或类型转换异常 - Oracle 21c+ 可用
"oracle.ucp.jdbc.PoolDataSourceFactory"，但效果与前者一致，无升级必要
初始连接数必须非零，否则首请求卡顿
UCP 没有 “minIdle” 概念，setMinPoolSize 仅控制空闲下限，真正决定“启动即可用连接数”的是 setInitialPoolSize。只设 setMaxPoolSize(20) 而不设初始值，应用启动后连接数为 0，第一个请求需同步创建连接，延迟陡增。
- 生产环境建议：
setInitialPoolSize(5)+setMaxPoolSize(20) -
setMinPoolSize(5)可显式声明（默认等于 initial 值），设为 0 表示允许连接彻底归零，适合低峰期节电，但再起量时延迟上升 - 不要照搬 Druid 的
maxActive思维——UCP 是两个独立参数协同控制，不是单值映射
事务中必须用 getConnection()，禁用 getPhysicalConnection()
在 Spring @Transactional 或手动管理事务时，若误调 getPhysicalConnection()，返回的是裸 OracleConnection，绕过 UCP 生命周期管理。后果是连接不归还、泄露、事务上下文错乱，pool.getAvailableConnectionsCount() 持续下跌，最终阻塞新请求。
- 所有业务代码统一走
pool.getConnection() -
getPhysicalConnection()仅用于底层诊断或特殊驱动层操作，绝不用于事务逻辑 - 现象典型：连接数缓慢上涨、日志里反复出现
UCP相关警告、活跃连接数长期高于预期
高可用场景下 FCF 必须显式启用
在 RAC 环境中，仅靠 JDBC URL 加 oracle.jdbc.fanEnabled=true 不生效。UCP 的快速连接故障转移（FCF）是独立开关，必须调用 setFastConnectionFailoverEnabled(true)，否则节点宕机后仍持续发请求，报 ORA-03113 或连接重置，重试间隔长达 20–30 秒。
立即学习“Java免费学习笔记（深入）”；
- 必须验证服务端已启用 FAN：
srvctl config service显示FAILOVER_TYPE=SELECT - ONS 连通性需提前确认：
onsctl ping -h rac1-vip -p 6200 - tnsnames.ora 中删掉所有
FAILOVER=ON、LOAD_BALANCE=ON、FAILOVER_MODE块——FCF 与 TNS 层重试互斥
UCP 的性能收益高度依赖初始化阶段的参数组合，而不是运行时自动优化。最容易被忽略的是：连接工厂类名未设、初始连接数为零、事务中混用物理连接——这三处任一出错，都会让响应速度比不用连接池还差。
