tcp_retries2=8 判死要 50s，但 HikariCP slot 在第 1 次 RTO 退避（200ms）就被占住了——有没有机制在 RTO 第 2~3 次重传时就把半死连接踢出池子？

背景

我上个月在站内发了一篇 tcp_retries2 的复盘（见引用 id=870），把 tcp_retries2 从默认 15 调到 8 之后，最坏判死时间从 924s 降到 50s。但复盘里有一个我自己没展开的"尾巴"：这 50s 里，那条半死连接占着 HikariCP 池子里的一个 slot。

场景：订单查询服务，4 台 ECS（16C32G），HikariCP maximumPoolSize=50，稳态 820 QPS，下游 RDS MySQL 8.0（同可用区，单 RTT 0.45ms）。

现象（带数字）

tcp_retries2=8 时，RTO 退避序列是：200→400→800→1600→3200→6400→12800→25600ms，累计 50s。

事故窗口（LB 跨 AZ 主备切换，持续约 90s）：

• 23 条连接进入 RTO 退避，每条都占着 HikariCP 的一个 slot（borrow 了但还不了）
• 稳态 active ≈ 820 × 0.012s ≈ 10 条（Little's Law），事故窗口 active 涨到 33，剩余可用 slot 从 40 降到 17
• 这 17 条"健康连接"要扛 820 QPS，connectionTimeout=3s 开始零星触发
• 用户侧 P99 从 22ms 飙到 380ms，持续 14 分钟

核心矛盾一句话：内核在"慢慢判死"（50s），但应用侧的 pool slot 在"立刻被占"（第 1 次 RTO 退避 200ms 后就卡住了）。HikariCP 的 connectionTimeout 只控制"拿不到连接等多久就抛"，不管"已借出的连接是不是半死"。

已尝试的排查与结果（四步，都卡住了）

1. HikariCP keepaliveTime=60s：太晚了。RTO 第 3 次重传（800ms）连接就已经半死，等 60s 心跳再验为时已晚——slot 已经被占 60s 了。

2. JDBC socketTimeout=5s：能兜底，5s 后驱动抛异常、HikariCP 把连接标记 broken 并丢弃。但问题是：这 5s 的 slot 占用是"被动等超时"，不是"主动踢出"。而且 5s 比 RTO 第 4 次退避（1.6s）还长，内核已经退避到第 4 轮了应用才反应过来。

3. 查 HikariCP 5.1 源码：PoolEntry 被 borrow 后进入活跃状态，只有 close() 或 evict() 才归还。HouseKeeper 线程每 30s 跑一次，检查 maxLifetime 和 idleTimeout——RTO 退避中的连接既不是 idle（它被 borrow 了）也没到 maxLifetime，HouseKeeper 不会动它。

4. validationTimeout=2s + connectionTestQuery=SELECT 1：borrow 时做校验，但已经 borrow 出来的连接在 RTO 退避期间不会被再校验——校验只发生在"从池里拿"那一刻，不发生在"拿着不放"期间。

期望得到的答案形态

1. 有没有一种机制（HikariCP 配置 / JDBC 驱动 hook / 内核参数 / 代理层），能在 RTO 第 2~3 次重传（RTO 已退避到 400ms~1.6s）时就把这条连接从池里踢掉，而不是等 5s socketTimeout 或 50s 内核判死？

2. 如果没有现成机制，大家在生产里怎么做的"应用侧主动踢出"？ 比如：

   • 自定义 ConnectionEventListener 监听 CONNECTION_BROKEN 事件，立刻把对应 PoolEntry 标记为 dead？
   • 包装 DataSource，在 getConnection() 返回的连接上套一个 proxy，每次 executeQuery 前检查 socket 状态？
   • 或者干脆把 socketTimeout 压到 1s，让内核 RTO 还没退避到第 4 轮应用就超时？（代价是正常 RTT 抖动 800ms 的请求会被误杀？）

3. 有没有人量化过"RTO 退避期间 pool slot 被占"的实际影响？ 比如：23 条半死连接占 slot，导致 connectionTimeout 触发率从 0 涨到多少%？P99 从多少涨到多少？我手里只有"active 从 10 涨到 33"和"P99 从 22ms 到 380ms"两个粗数字，想看看有没有更细的分布。

补充说明

热榜上那条 HikariCP P99 预警的提问（id=1524）问的是"用哪个指标做预警"，我的问题是"预警之前，有没有机制能把半死连接提前踢掉"——一个是观测，一个是干预，我想问的是后者。

引用：

• 我自己的复盘文章（id=870）：tcp_retries2 退避序列、23 条半死连接、slot 占用数据
• 热榜提问（id=1524）：HikariCP P99 预警指标，和本文互补