Hikari池线程创建远超设定阈值引发OOM及告警问题咨询

你观测到的线程命名中HikariPool-xx的序号是连接池实例的编号，不是单池内的连接编号，出现250个不同前缀的Hikari线程，说明你的应用累计创建了至少250个独立的Hikari连接池实例，这是线程数远超阈值的核心原因，常见诱因如下：

• 重复初始化DataSource：Spring/SpringBoot项目中最常见，配置类逻辑错误导致每次获取DataSource时都新建HikariDataSource对象，或是应用上下文反复刷新（如热部署配置错误、多上下文重复加载），每次刷新都会创建新的连接池实例，旧实例未被主动销毁，内部持有的连接线程也不会释放。
• 手动创建实例未释放：如果代码中手动实例化HikariDataSource，业务逻辑每次执行都新建实例、且用完未调用close()方法释放资源，会持续累积连接池实例和对应的连接线程。
• 配置不生效：如果maximumPoolSize参数的属性名配置错误（比如误写为maxPoolSize、maxTotal等不符合Hikari规范的名称），会导致你设置的25连接上限不生效，不过这种情况只会导致单池连接数超过预期，不会出现250个不同编号的池实例。

该告警由Hikari内部的HouseKeeper定时任务触发，该任务默认每30s执行一次，负责清理空闲连接、维护连接池状态，触发告警的场景如下：

• 线程饥饿：CPU资源被占满、或者高优先级线程持续抢占调度资源，导致HouseKeeper线程长时间拿不到CPU时间片，两次执行的间隔远大于30s，Hikari就会抛出该告警。你当前存在大量连接池线程消耗CPU、内存资源，是触发该告警的核心诱因。
• 系统时钟跳变：服务器系统时间被手动修改、或NTP同步时出现大幅时间跳转，会导致HouseKeeper判断两次执行的时间间隔异常，触发该告警。

这两个问题存在强关联：大量连接池实例占用过多系统资源导致调度卡顿，触发时钟/饥饿告警后，连接池的连接维护逻辑失效，会进一步加剧资源消耗，最终引发内存耗尽、应用卡死。

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