一、现象与背景
去年双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 的核心不是「池子有多大」，而是**「连接被借出后多久必须还回来」**。机制拆开看：
- 借出即占用：
getConnection()拿到连接后，该连接就从「可用池」移到「已借出」，在close()（或 try-with-resources 结束）前不会归还。maximumPoolSize只决定同时能借多少个。 - 池打满 ≠ DB 满：DB 的
max_connections是全局上限，应用池是每实例上限，两者不是一个维度。压测里 DB 只用了 42，但应用侧 80 个池连接被占满——瓶颈在应用侧。 - 为什么借出不还：根因是一条慢 SQL。订单服务有个
SELECT ... FOR UPDATE在大事务里跑，压测下单条 P99 从 40ms 飙到 2.8s。按 Little 的定律：并发需求 = 吞吐 × 占用时长。1200 QPS × 2.8s ≈ 需要 3360 个并发连接，而单实例池只有 20，瞬间打满，后续请求全部排队 30s 后超时。 - 超时放大：
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. 快速失败必须配「不对连接池异常做无脑重试」（最容易漏的一步）
connectionTimeout 从 30s 降到 2~3s 后，SQLTransientConnectionException 的抛出频率从「30s 一次」变成「2s 一次」。如果上游（Tomcat 工作线程 / 网关）直接裸重试，等于把「等 30s 才失败」换成「2s 失败 ×N 次」，对下游 DB 是更密的冲击——快速失败本身会变成放大器。正确姿势：
- 把「获取连接超时」这一类异常单独圈出来，走熔断（Resilience4j CircuitBreaker 的
recordException或 Sentinel），不对连接池类异常重试，直接降级返回 503 +Retry-After: 2； - 只对「请求还没发完」的幂等场景重试一次，对「服务端可能已处理」的写操作绝不重试。
判据（建议写进 runbook）：熔断 open 期间观察 hikaricp_connections_pending——
- pending 回落到 0 → 是「容量不够」（扩池或降 QPS）；
- pending 持续 >10 不降 → 是「持有问题」（查事务边界 / 慢 SQL），扩池没用。
这个「熔断后看 pending 是否回落」的判据，比单纯看 active/max 占比更能区分两种根因。
5. 容量公式
别拍脑袋加 maximumPoolSize。经验公式：池大小 ≈ 核心数 × 2 + 磁盘数（Hikari 作者推荐），再按 并发需求 = QPS × 单请求占用时长 校验。盲目把 20 调到 200，只会把压力转嫁给 DB，让慢查询更慢，形成死循环。
四、踩过的坑 / 反直觉之处
- 「连接没满还报错」是错觉：DB
max_connections没满不代表应用池没满，两个维度要分开看。 - 加大池子常常更糟：池越大，同时打到 DB 的并发越多，慢 SQL 被放大，整体吞吐反而下降。我们试过调到 100，P99 从 2.8s 恶化到 4.5s。
- connectionTimeout 太长是帮凶：30s 让失败变慢、线程堆积；改成 3s 后，过载请求快速失败，配合网关限流，系统反而稳定了。快速失败 > 慢慢等死——但前提是配上第 4 步的「不对连接池异常重试」，否则快速失败会放大故障。
- leak-detection 有性能代价：它靠后台线程扫描借出状态，生产长期开有开销，建议压测/排障时开、平时关，或用较大阈值（如 5s）常开。
- max-lifetime 必须小于 DB 的 wait_timeout：否则 DB 先断、应用后断，拿到已断连接报
Connection has been closed。 - 虚拟线程下
hikaricp.pending会系统性虚高，别和平台线程时代的阈值直接比：平台线程里 pending≈「真正卡住的请求数」，被 Tomcat 200 封顶；换成虚拟线程后，pending 统计的是「等待 getConnection 的虚拟线程数」，会逼近QPS × 等待时长，一个量级跳上去——但这不代表 DB 真的慢，很多只是虚拟线程 park 在等待队列上，carrier 线程（默认=核数）并没被占满。判据要联看：pending高 且active/maximumPoolSize ≈ 100%持续不回落 → 真持有（慢 SQL / 事务边界），扩池没用，查 FOR UPDATE；pending高但active占比正常、且-Djdk.tracePinnedThreads=full抓不到 pin 栈 → 大概率是虚拟线程等待堆积 + carrier 有限导致的调度放大，该调的是 carrier 数（jdk.virtualThreadScheduler.parallelism）和超时预算（虚拟线程下 connectionTimeout 建议更短，1~2s），不是连接池。一句话：平台线程时代「看 pending 就够」，虚拟线程时代必须 pending 和 active 占比联看，否则会把「调度问题」误判成「容量问题」，扩了池反而放大等待窗口。
五、结论与可复用清单
连接池问题的本质是容量规划，不是「加个配置」。排查顺序固定：
- 分清瓶颈在 应用池（看
hikaricp.pending/active）还是 DB（看Threads_connected）。 - 瓶颈在应用池 → 先找慢 SQL / 连接泄漏（治本），再谈池大小（治标）。
- 用
并发需求 = QPS × 占用时长校验容量，别拍脑袋。 - 参数基线：
connection-timeout=3000、leak-detection-threshold排障时开、max-lifetime < DB wait_timeout。 - 记住：快速失败 + 限流 比「加长超时硬扛」更能救雪崩——但快速失败必须配「不对连接池异常做无脑重试」，并用「熔断后看 pending 是否回落」区分容量问题 vs 持有问题。
- 虚拟线程场景：pending 会虚高，必须 pending 与 active 占比联看，必要时调 carrier 数与更短超时，而不是盲目扩池。
关联阅读：站内有《超时与重试：高并发后端最容易翻车的两件事》《Kafka 毒消息与 DLT 静默丢失》，本文补的是「连接池」这一环，三者叠加才是一次完整的容量事故。