HikariCP初始化连接池失败，报PostgreSQL客户端连接数过多问题解决

报错核心诱因 #

• 多连接池实例抢占PG连接配额：你将Hikari配置写在数据库类的构造函数中，如果该数据库类被多次实例化，就会生成多个独立的Hikari连接池。每个池默认最大连接数设为100，多个池累积持有的长连接数会快速超过PostgreSQL默认的max_connections阈值（默认值100）。由于连接池初始化阶段就需要建立连接，一旦PG端连接数被占满，就会触发too many clients already的池初始化失败报错。
• 配置错配导致参数完全失效：你同时使用了setDataSource(PGSimpleDataSource)和setJdbcUrl两套配置，按照Hikari的规则，一旦设置了自定义DataSource，jdbcUrl及后续通过addDataSourceProperty传入的参数（包括预编译缓存配置、max_connections属性）都不会生效。其中max_connections本身是PostgreSQL服务端的全局配置项，客户端连接时传入该参数毫无意义，根本不会调整PG的连接上限。
• 连接获取逻辑存在缺陷：你的getConnection方法在捕获到SQLException时直接返回null，上层调用方如果用try-with-resources接住这个null值，会直接触发空指针异常；同时异常被完全吞掉，会导致连接获取失败的问题被掩盖，无法及时发现连接池已经占满PG配额的问题。
• 超时参数设置不合理：你将maxLifetime和idleTimeout都设为30秒，远低于Hikari的合理推荐值，会导致池内连接被频繁销毁重建，短时间内产生大量新建连接请求，加速打满PG的连接配额。

注：你测试中快速150次直连新建连接没有触发报错，是因为直连连接用完即关，PG会立刻释放连接配额；而Hikari池持有的是长连接，哪怕闲置也不会释放PG端的连接占用，累积占用量远高于临时直连的场景。

修复调整方案 #

• 将HikariDataSource改为全局单例：整个应用生命周期只初始化一个连接池实例，绝对不要在业务类、工具类的构造函数中重复创建连接池，从根源上避免多池争抢连接的问题。
• 修正无效配置项：
  • 删除完全不生效的config.addDataSourceProperty("max_connections", "100")配置
  • 二选一保留配置路径：要么移除setDataSource配置，直接基于jdbcUrl搭建连接池；要么保留PGSimpleDataSource配置，移除setJdbcUrl，同时把预编译语句缓存的参数直接设置到PGSimpleDataSource实例上，避免参数不生效的问题。
• 调整池大小与超时参数：
  • 将maximumPoolSize从100下调到10-20区间，Hikari官方不推荐将池大小设过高，过高的连接数反而会增加数据库端的上下文切换开销，且预留足够的PG连接配额给管理员、系统后台使用，避免触达PG的连接上限。
  • 将maxLifetime调整为1800000（30分钟，需短于PG端的会话超时配置），idleTimeout调整为600000（10分钟），减少连接频繁重建带来的开销。
• 修正getConnection的实现逻辑：
  • 不要在捕获异常时返回null，直接将SQLException封装为运行时异常向外抛出，保证上层能明确感知连接获取失败的问题，同时避免空连接带来的空指针异常。
• 排查连接泄漏：
  • 你已经开启了leakDetectionThreshold=10000的泄漏检测，需要在日志中定位Hikari打印的连接泄漏堆栈，修复所有未通过try-with-resources自动归还连接的代码，避免连接被长期占用导致池内可用连接耗尽，进而触发池端不停新建连接打满PG配额的问题。
  • 现有示例代码里手动调用conn.close()的逻辑是冗余的，try-with-resources语法会自动在代码块退出时将连接归还连接池，无需重复调用。

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