HikariCP日志报“Cannot acquire connection from data source”原因排查

结合你描述的场景（9个独立连接池、仅2个库出现无业务影响的随机DEBUG报错、Hikari 4.0.3 + Spring Boot 2.3.0），以下是具体原因分析：

1. 后台连接补充线程的短暂资源/网络瓶颈 #

Hikari的connection adder线程负责后台维护连接池的连接数量，当它尝试新建连接时，如果遇到：

• 数据库侧临时连接数超限（比如Oracle的SESSIONS/PROCESS达上限、PostgreSQL的max_connections占满）
• 网络层面的短暂抖动/延迟
  会触发这个DEBUG级报错，但因为业务请求使用的是池内已有的可用连接，不会受到影响，所以业务正常。
• 验证方式：检查对应时间点数据库的日志（Oracle看ORA-00018/ORA-00020，PostgreSQL看too many connections），或网络监控的丢包/延迟记录。

2. 连接超时配置的边缘触发 #

如果这两个库的connectionTimeout配置值过小，当数据库偶尔出现连接建立耗时超过该阈值时，connection adder线程的连接请求会超时失败，但池内已有足够的空闲连接支撑业务，因此不会影响业务。

• 验证方式：对比这两个库与其他正常库的spring.datasource.hikari.connection-timeout配置，查看数据库侧连接建立的耗时波动（比如Oracle的SQL*Net roundtrip time指标）。

3. 数据库侧的临时连接限制/回收 #

部分数据库的资源管控机制会临时拒绝新连接：

• Oracle：若启用了资源限制（RESOURCE_LIMIT=TRUE），当某个用户的连接配额临时耗尽，会拒绝新连接请求；或者共享池临时占满导致连接建立失败。
• PostgreSQL：当max_connections满后，新请求会进入队列，队列满则直接拒绝，刚好被connection adder线程撞上。
  这类场景都是短暂的，池内已有连接不受影响，所以业务无感知。

4. Hikari版本的日志噪音问题 #

Hikari 4.0.3存在部分边缘场景的DEBUG日志误报：当connection adder线程尝试建立连接失败，但后续重试成功时，会留下这条报错日志，但实际连接池的连接数量已经补充到位，不会影响业务。结合Spring Boot 2.3.0的适配情况，这个版本组合可能存在这类无影响的日志噪音。

• 验证方式：通过HikariMXBean获取池的activeConnections、idleConnections指标，确认报错后连接池状态正常。

内容的提问来源于stack exchange，提问作者Matthew Marion