连接池全绿却偶发卡 30s：keepalive 与中间件 idle timeout 错配导致的「连接假死」治理
一、现象与背景
一条读多写少的商品详情服务（Java 17 + Spring Boot 3.1 + HikariCP 5.1.0，后端 MySQL 8.0.35，中间隔了一层云 RDS Proxy / SLB），QPS 稳定 600，P50 8ms，但每天稳定出现 20~50 次「拿到连接后卡满 30s 才抛异常」的请求，日志里是：
com.mysql.cj.jdbc.exceptions.CommunicationsException:
Communications link failure
The last packet successfully received from the server was 30,112 milliseconds ago.
最迷惑的地方在于：出问题时监控全绿——
| 指标 | 数值 |
|---|---|
| HikariCP active | 12 / 40（远没满） |
| HikariCP pending | 0（没有线程在排队） |
| Threads_connected | 41 / 1500 |
| CPU / GC / 慢日志 | 全部正常 |
按「连接池没打满 = 没问题」的直觉，池子根本不该背锅。但 30s 这个精确到毫秒级的卡点，恰恰暴露了它。
二、原理与根因分析
根因：三层「空闲回收」的 timeout 没有对齐，制造了一批「应用以为活着、中间件早已单方面 RST 掉」的半开连接。
三个相关超时，各自为政：
- MySQL 服务端：
wait_timeout = 28800s（默认 8 小时），本身几乎不会主动断空闲连接； - 中间件（RDS Proxy / SLB）：空闲连接 idle timeout 默认 600s，到点它会对这条 TCP 连接发
RST（或FIN）并回收，但应用侧内核不一定立刻感知； - 应用侧 HikariCP：
maxLifetime默认 1800000ms = 30min，keepaliveTime默认 0（关闭，从不主动探活）。
于是出现一个致命窗口：一条连接空闲了 620s。中间件在 600s 时已单方面把它杀掉，但这条连接此刻还在 HikariCP 池里、状态是「idle、健康」。下一个请求 getConnection() 秒拿到它（所以 pending=0、active 也不涨），write() 成功（数据进了内核发送缓冲，TCP 层还没暴露对端已死），然后 read() 等响应——等 30s（JDBC socketTimeout）后超时。
这就是「池子全绿却卡 30s」的完整机制：故障不在「拿不到连接」，而在「拿到了一条已经死了的连接」。这也解释了为什么它每天固定 20~50 次——正好等于池里那些空闲时间恰好越过中间件 idle 阈值的连接数。
一个必须点破的认知误区：HikariCP 的 connectionTimeout（默认 30000ms）只约束「从池里等一个空闲连接」的时间，完全不约束「用一条死连接做读写」的耗时。很多人调了 connectionTimeout 以为兜住了 30s，其实兜错了地方。
三、具体做法（可复现）
核心原则一句话：客户端侧的「探活/回收」周期，必须严格短于中间件的 idle timeout，让连接在中间件杀它之前就被主动刷新或回收。
1）HikariCP 关键三项（单位 ms）：
# 主动探活：每 30s 对空闲连接发一次 ping，必须 << 中间件 idle(600s)
spring.datasource.hikari.keepalive-time=30000
# 连接最大寿命：9.9min，必须 < 中间件 idle(600s=10min)，让它先于中间件回收
spring.datasource.hikari.max-lifetime=594000
# 从池取连接时的校验：用一次轻量 ping 确认连接活着
spring.datasource.hikari.connection-test-query=SELECT 1
# 池内空闲下限，避免连接长期闲置正好踩进 idle 窗口
spring.datasource.hikari.minimum-idle=10
2）JDBC URL 兜底（让死连接在 socket 层快速暴露，而不是干等）：
jdbc:mysql://host:3306/db?tcpKeepAlive=true&connectTimeout=5000&socketTimeout=8000
socketTimeout=8000 把「用死连接读」的最坏等待从 30s 压到 8s，配合 tcpKeepAlive 让内核级 keepalive 更早探测到对端已 RST。
3）核对中间件与服务端 timeout，保证「客户端 < 中间件 < 服务端」链条成立：
-- 服务端确认（一般不用动，默认 8h 足够长，反而不是问题源头）
SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';
到云控制台把 RDS Proxy / SLB 的 idle timeout 查出来，确保它 > 你的 keepalive-time。我们最终对齐成：keepalive 30s < 中间件 600s < 服务端 28800s。
4）验证判据：
- 压测里人为让连接空闲 620s 再发请求，改造前必现 30s 超时，改造后 P99 < 20ms；
jstack抓超时瞬间，改造前能看到线程卡在NativePark / read0等 socket，改造后无此栈；- 观察一周，
Communications link failure从每天 20~50 次降到 0。
四、踩过的坑 / 反直觉之处
- 最反直觉：故障发生在池指标「全绿」时。连接池打满（active 满、pending 高）是显性故障，一眼能看出；而「连接假死」恰恰是 active/pending 都正常、只有个别请求卡死——监控面板越绿，越容易让人放过它。
maxLifetime=30min的默认值就是坑：它比中间件 600s 长得多，等于「这条连接本该被回收却苟活了 24 倍于中间件的寿命」，正好把大量连接送进 idle 窗口。- 别只调
connectionTimeout：它管「拿连接」不管「用连接」，调它对这个故障是无效安慰剂。 tcpKeepAlive不是万能的：Linux 默认 keepalive 探测间隔是 7200s、10 次，等于基本不工作；真正兜底的是应用层keepalive-time+socketTimeout，内核 keepalive 只是最后一道保险。- 若你走的是长连接池 + 负载均衡 + 网关三层，每一层都有自己的 idle timeout，要逐层核对，最短板那一层才是凶手。
五、结论与可复用清单
一句话结论：偶发「拿到连接却卡固定时长（=socketTimeout）」且池指标全绿，第一嫌疑不是慢 SQL、不是池大小，而是「连接假死」——某一层中间件的 idle timeout 单方面杀了连接而应用不知情。
排查顺序（可直接抄）：
- 看超时日志里的「last packet received N ms ago」——若 N ≈ 你的
socketTimeout，基本锁定假死； - 列出这条链路上每一层的 idle timeout（网关 / LB / Proxy / 服务端
wait_timeout）； - 把客户端
keepalive-time压到最小那层 idle 的 1/10 以内，max-lifetime压到最小 idle 的 90% 以内； - JDBC 加
socketTimeout（建议 5~10s）+tcpKeepAlive，让死连接快速暴露； - 空闲复现压测 + 一周日志观察，确认
Communications link failure归零。
边界：这套解法针对「中间件/代理单方面回收空闲连接」的场景。如果你的连接根本没经过任何代理、直连 MySQL 且 wait_timeout 极短，那凶手在服务端 wait_timeout 侧，需反向对齐（把服务端 idle 调长或客户端探活调短）。另外，connection-test-query=SELECT 1 会增加每次取连接的极小开销（<1ms），高并发下可改用 JDBC ping 或依赖 keepalive-time 主动探活来替代。