HikariCP 连接池耗尽：一次「连接数没满却拿不到连接」事故的原理与调参

一、现象与背景

去年双11前压测，我们一个订单服务（Spring Boot 3.2，JDK 21，HikariCP 5.1.0，单实例 8C16G，前置 4 个实例）出现诡异故障：压测到 1200 QPS 时，大量请求在 30s 后超时，日志刷 SQLTransientConnectionException: Connection is not available, request timed out after 30000ms。

但诡异的是：监控里 DB 侧（MySQL 8.0.36）活跃连接数只到 42，远没到 max_connections（1500）。按直觉，「连接没满」不该报错。后来发现真正卡住的是应用侧连接池——每个实例 HikariCP maximumPoolSize=20，4 实例合计 80，而压测打满时单实例池内 20 个连接全部被「借出未归还」，新请求全在 connectionTimeout=30000ms 里排队。

影响面：4 个实例同时 100% 请求 30s 超时，持续约 7 分钟，网关侧 5xx 占比冲到 96%。这不是 bug，是连接池容量 + 慢查询 + 超时配置三者叠加的经典组合。

二、原理与根因

HikariCP 的核心不是「池子有多大」，而是**「连接被借出后多久必须还回来」**。机制拆开看：

1. 借出即占用：getConnection() 拿到连接后，该连接就从「可用池」移到「已借出」，在 close()（或 try-with-resources 结束）前不会归还。maximumPoolSize 只决定同时能借多少个。
2. 池打满 ≠ DB 满：DB 的 max_connections 是全局上限，应用池是每实例上限，两者不是一个维度。压测里 DB 只用了 42，但应用侧 80 个池连接被占满——瓶颈在应用侧。
3. 为什么借出不还：根因是一条慢 SQL。订单服务有个 SELECT ... FOR UPDATE 在大事务里跑，压测下单条 P99 从 40ms 飙到 2.8s。按 Little 的定律：并发需求 = 吞吐 × 占用时长。1200 QPS × 2.8s ≈ 需要 3360 个并发连接，而单实例池只有 20，瞬间打满，后续请求全部排队 30s 后超时。
4. 超时放大：connectionTimeout=30000ms 让每个排队请求都「等满 30 秒才失败」，于是大量线程被拖住等连接，Tomcat 工作线程（默认 200）也被耗尽，故障雪崩。

一句话根因：慢查询把单请求占用时长拉长了 70 倍，连接池容量没跟上，超时配置又把失败延迟放大成雪崩。

三、具体做法

定位与调参，按顺序做：

1. 先确认瓶颈在应用侧

# 看 DB 侧真实连接（排除 DB 满）
mysql> SHOW GLOBAL STATUS LIKE 'Threads_connected';
# 看应用池：Hikari 自带指标，接 Micrometer 暴露
# /actuator/metrics/hikaricp.active / hikaricp.pending / hikaricp.idle

关键看 hikaricp.pending（排队数）持续 >0 且 hikaricp.active 恒等于 maximumPoolSize，就是池打满。

2. 找到慢 SQL（治本）

-- MySQL 8.0 查慢查询
SET GLOBAL slow_query_log=ON;
SET GLOBAL long_query_time=0.2;

定位到那条 FOR UPDATE 大事务，把事务边界从「整个下单方法」收窄到「只包 UPDATE」，单请求 P99 从 2.8s 降回 60ms，并发需求从 3360 直接降到 72，20 的池绰绰有余。

3. 连接池参数（治标 + 兜底）

spring.datasource.hikari.maximum-pool-size=20      # 别盲目加大，见下文
spring.datasource.hikari.minimum-idle=10
spring.datasource.hikari.connection-timeout=3000   # 30s→3s，快速失败
spring.datasource.hikari.leak-detection-threshold=5000  # 借出超5s打堆栈
spring.datasource.hikari.max-lifetime=600000       # 10min，小于DB wait_timeout

leak-detection-threshold 是隐藏利器：配置后，任何借出超 5s 未归还的连接都会打印「谁借的、堆栈在哪」，我们靠它抓到了一个手动 getConnection() 后忘记 close() 的代码路径。

4. 容量公式 别拍脑袋加 maximumPoolSize。经验公式：池大小 ≈ 核心数 × 2 + 磁盘数（Hikari 作者推荐），再按 并发需求 = QPS × 单请求占用时长 校验。盲目把 20 调到 200，只会把压力转嫁给 DB，让慢查询更慢，形成死循环。

四、踩过的坑 / 反直觉之处

• 「连接没满还报错」是错觉：DB max_connections 没满不代表应用池没满，两个维度要分开看。
• 加大池子常常更糟：池越大，同时打到 DB 的并发越多，慢 SQL 被放大，整体吞吐反而下降。我们试过调到 100，P99 从 2.8s 恶化到 4.5s。
• connectionTimeout 太长是帮凶：30s 让失败变慢、线程堆积；改成 3s 后，过载请求快速失败，配合网关限流，系统反而稳定了。快速失败 > 慢慢等死。
• leak-detection 有性能代价：它靠后台线程扫描借出状态，生产长期开有开销，建议压测/排障时开、平时关，或用较大阈值（如 5s）常开。
• max-lifetime 必须小于 DB 的 wait_timeout：否则 DB 先断、应用后断，拿到已断连接报 Connection has been closed。

五、结论与可复用清单

连接池问题的本质是容量规划，不是「加个配置」。排查顺序固定：

1. 分清瓶颈在 应用池（看 hikaricp.pending/active）还是 DB（看 Threads_connected）。
2. 瓶颈在应用池 → 先找慢 SQL / 连接泄漏（治本），再谈池大小（治标）。
3. 用 并发需求 = QPS × 占用时长 校验容量，别拍脑袋。
4. 参数基线：connection-timeout=3000、leak-detection-threshold 排障时开、max-lifetime < DB wait_timeout。
5. 记住：快速失败 + 限流 比「加长超时硬扛」更能救雪崩。

关联阅读：站内有《超时与重试：高并发后端最容易翻车的两件事》《Kafka 毒消息与 DLT 静默丢失》，本文补的是「连接池」这一环，三者叠加才是一次完整的容量事故。