Oracle UCP连接池无法充分利用活跃连接问题求助

看起来你遇到了Oracle UCP连接池的一个非常棘手的矛盾问题——明明池里的总连接数已经打到上限500，还抛出了连接耗尽的错误，但实际被标记为“已借用”的连接数却只有个位数，完全没用到池里的其他连接。我来帮你梳理几个高概率的原因和对应的排查方向：

1. 对UCP统计指标的理解可能有误 #

这是最容易被忽略的核心点，先核对Oracle UCP 19.24版本的统计指标定义：

• getTotalConnectionsCount()：自连接池启动以来，累计创建过的连接总数（包括已经被销毁的连接），不是当前池内的实时连接总数！
• getCurrentConnectionsCount()：当前池内存在的所有连接数（包含已借用+空闲可用的）
• getBorrowedConnectionsCount()：当前正在被应用使用的连接数
• getAvailableConnectionsCount()：当前池内空闲、可被借用的连接数

如果你误把getTotalConnectionsCount()当成了当前池内的总连接数，那之前的现象就会出现逻辑矛盾。建议你在日志里同时打印这四个指标，观察它们的联动变化：比如当你看到“总连接数到500”时，看看getAvailableConnectionsCount()是否为0，getCurrentConnectionsCount()是否真的达到了500。

2. 自定义数据源包装类导致连接未被正确归还 #

你的MyCustomPoolDataSource作为UCP数据源的包装类，很可能在连接生命周期的处理上出了问题：

• 连接关闭逻辑未正确代理：JdbcTemplate在使用完连接后会调用Connection.close()来归还连接，但如果你的包装类返回的Connection没有把close()方法代理到原始UCP连接的close()，UCP就无法感知到连接已经被归还，会一直认为这个连接处于“已借用”状态，只能不断创建新连接直到池满。
• autoCommit设置干扰了连接复用：你在借到连接后强制设置autoCommit(true)，如果你的应用中使用了Spring事务管理（比如@Transactional），Spring会自动将连接的autoCommit设为false，事务结束后再恢复。你的强制修改可能破坏了连接的状态，导致UCP认为这个连接不可复用，只能创建新连接。

排查建议：

• 临时移除MyCustomPoolDataSource，直接用原始的PoolDataSource注入到JdbcTemplate，压测看问题是否复现。如果问题消失，100%是自定义包装类的问题。
• 对包装类返回的Connection做代理增强，在close()方法执行时打印日志，确认JdbcTemplate是否真的触发了连接归还操作。

3. 连接泄漏（连接被占用但未被标记为已借用） #

虽然你看到getBorrowedConnectionsCount很低，但可能存在连接泄漏的特殊情况：

• 某些代码路径直接从数据源获取连接后，忘记关闭（即使大部分用了JdbcTemplate，也可能有遗漏），导致连接被占用，但UCP的统计没有正确标记为“已借用”。
• UCP的连接泄漏检测未开启，无法自动回收长期未使用的连接。

排查建议：

• 开启UCP的连接泄漏检测：在数据源配置中添加

  poolDataSource.setAbandonedConnectionTimeout(30); // 30秒未使用则标记为泄漏
  poolDataSource.setRemoveAbandoned(true); // 自动回收泄漏的连接
  

• 检查所有直接使用getConnection()的代码，确保每个连接都在try-with-resources块中，或者在finally中关闭。

4. UCP连接池的配置参数不合理 #

某些UCP的默认配置或你自定义的配置可能导致连接无法被复用，只能不断创建新连接：

• maxIdleTime设置过短：空闲连接很快被销毁，UCP只能不断创建新连接来应对请求，导致累计创建数（getTotalConnectionsCount）飙升，而当前池内的可用连接不足。
• connectionValidationTimeout设置不合理：如果UCP对空闲连接的验证失败，会直接销毁该连接，而不是复用，导致连接池不断创建新连接。
• minPoolSize设置过高：如果minPoolSize设为500，UCP会在启动时就创建500个连接，但这些连接可能因为状态异常无法被复用，导致池满但借用数低。

5. Spring JdbcTemplate的连接管理逻辑冲突 #

虽然JdbcTemplate本身会正确管理连接，但如果你的数据源包装类破坏了它的预期行为：

• 比如，JdbcTemplate期望从数据源获取的连接是标准的UCP连接，但你的包装类返回的连接修改了某些核心行为，导致JdbcTemplate无法正确归还连接。
• 检查是否存在多数据源混用的情况，比如某些DAO用了原始数据源，某些用了自定义数据源，导致连接池状态混乱。

快速验证步骤：

1. 替换统计指标：把getTotalConnectionsCount()换成getCurrentConnectionsCount()，重新压测观察。
2. 移除自定义数据源：直接用原始UCP数据源创建JdbcTemplate，看问题是否消失。
3. 开启泄漏检测：配置UCP的连接泄漏参数，看是否能缓解或解决问题。

备注：内容来源于stack exchange，提问作者bula