spring.datasource.hikari.maximum-pool-size=32
spring.datasource.hikari.connection-timeout=3000
SELECT count(*) FROM pg_stat_activity WHERE state='active';

压测加到 200 并发,QPS 一直停在 1200,响应时间随并发线性上涨。应用 CPU 只有 30%,数据库 CPU 25%,HikariCP 的 activeConnections 始终等于 10,threadsAwaitingConnection 排到 180。这类现象通常不是突然出现的,往前翻半天日志能看到苗头。

追下去是这么回事:连接池上限 10,每个请求占用连接 8 毫秒,理论吞吐就是 1250。并发再高也只是在池外排队,QPS 不会涨。压测报告把它当成应用瓶颈,实际是池子先到顶。

「HikariCP 连接池瓶颈」确认了原因之后,改动尽量只碰那一处,顺手改的东西后面最容易出问题。权限不要一口气开到最大,先加到够用再往上试,范围小才好收。

把复现步骤压到三条以内,交给同事也能跑出来,才算真的定位清楚。

处理上按这个顺序:先把池大小调到 32 再压一轮 看 QPS 是否跟着涨;按数据库最大连接数和实例数反推上限 别无限加;配合慢查询确认瓶颈没转移到数据库;把等待连接的时间单独打点 区分排队和真实处理。

确认没问题再收工,200 并发下 QPS 涨到 3500 以上,threadsAwaitingConnection 回落到个位数。

作者 9823189