长事务「占着连接发呆」：一条 40s 的 HTTP 调用把 HikariCP 池子拖到 pending 爆表，DB 侧却一片绿——怎么把「连接持有时间」变成一等指标，阈值怎么定？

背景

一个订单服务：Java 17 / Spring Boot 3.2 / HikariCP 5.1（maximumPoolSize=30, minimumIdle=5, connectionTimeout=5s, idleTimeout=10min, leakDetectionThreshold=30s），下游 MySQL 8.0 单主（innodb_lock_wait_timeout=50s）。K8s 部署 6 副本，单副本 4C8G。

一个定时对账任务（跑在同一个 Spring 上下文里，没单独拆进程）里有一段这样的代码：

@Transactional
public void reconcile() {
    List<Order> orders = orderMapper.selectPending();
    for (Order o : orders) {
        // 同步 HTTP 调用第三方对账接口
        var resp = http.get(thirdPartyUrl + o.getId());
        o.setStatus(resp.status());
        orderMapper.update(o);
    }
}

第三方接口 P99 约 120ms，但有 0.01% 的请求会挂 30s+（对端网络抖动）。一次 2000 单的批次，理论上要 240s，事务期间这条 DB 连接一直被持有，事务提交才归还。

现象（一次真实事故）

凌晨 2:30 定时任务触发。02:31:15 出现第一个 P99 尖刺：

1. 02:31:15：对账任务持有 2 条连接（事务中），开始循环 HTTP 调用。
2. 02:31:47：某次 HTTP 调用 35s 未返回，事务仍未提交，连接仍未归还。
3. 02:32:20：业务接口开始报 SQLTransientConnectionException: Connection is not available, request timed out after 5000ms，持续约 90s。
4. 02:33:50：对账事务超时被 Spring 回滚，连接归还，P99 回落到基线。

坑在 DB 侧全绿：

• Threads_running 全程 < 5（事务挂着但没在跑 SQL，不算 running）
• Threads_connected 只比基线多 2，看不出异常
• 慢查询日志：这条 SELECT 本身 80ms，不在慢日志阈值内
• SHOW ENGINE INNODB STATUS：没有 lock wait，因为锁已经被事务持有，别人等它反而才是 lock wait，但这次没发生（对账表和业务表不交叉）

监控侧：

• HikariCP 的 pendingThreads 指标我们有采集但没告警（只看了 active/idle）
• leakDetectionThreshold=30s 只打印告警日志，没有接进 Prometheus
• 没有「连接持有时间」的直方图指标（pool.connection.uptime 有，但没按「被借出-归还」的持有时间打点）

已尝试的排查与结果

| 尝试 | 结果 | |------|------| | 把 leakDetectionThreshold 从 30s 降到 10s | 日志多了，但还是「事后翻日志」，没变成「当时告警」 | | 给对账任务单独起一个 Spring 上下文（独立 HikariCP 池子，max=2） | 隔离了 90% 的爆炸半径，但对账自身超时还是会把 2 条连接占满，只是不再拖垮业务池——治标 | | 把 @Transactional 改成逐条提交（每条单独立事务） | 解决了「长持连接」，但引入了新的坑：对账中途第三方接口挂了，部分提交导致对账结果不一致，需要补幂等 | | 在 HikariCP 的 connectionLeakDetection 回调里发 Prometheus metric | 写了，但 leakDetectionThreshold 是全局的，业务侧短事务（50ms）也受同一阈值约束，调低会误报，调高会漏报 | | 给 HTTP 调用加 OkHttp callTimeout=5s | 治标，但没解决「事务里做 HTTP」这个结构性问题 |

核心卡点

本质是：「连接持有时间」这个指标，在主流 DB 和连接池里都不是一等公民。

• MySQL 的 information_schema.processlist 能看到「连接在干什么」，但看不到「这条连接被借出多久了」——那是应用层的事
• HikariCP 的 pendingThreads / activeConnections 是瞬时值，不是「持有时间分布」——你看到的是「现在有几个连接被占着」，看不到「这些连接平均被占了多久、最长被占多久」
• leakDetectionThreshold 是全局一刀切，业务侧 50ms 的短事务和 30s 的长事务用同一个阈值，必然要么误报要么漏报

期望得到的答案形态

想听真实线上做法（不是理论），具体到：

1. 你们怎么把「连接持有时间」变成可观测指标？ 是自己在 DataSource 包一层装饰器打 histogram（connection.borrow.duration），还是用 HikariCP 的 connectionLifecycleListener 钩子？有没有现成的开源方案（比如 hikaricp-micrometer 的扩展）？
2. 阈值怎么定？ 是按「P99 持有时间 > X 秒」告警，还是按「持有时间 / 事务预期时长 > N 倍」告警？后者需要每个事务声明预期时长，前者需要全局基线——你们怎么取舍？
3. 「事务里做 HTTP/外部调用」这个反模式，你们线上是怎么强制禁止的？ 是 ArchUnit 规则、是 Spring 的 @Transactional(timeout=N)、是代码 review 卡点、还是有更狠的「事务内禁止阻塞调用」的拦截器方案？
4. 对账/批处理类长任务，你们怎么和业务接口彻底隔离？ 是拆进程（独立 Spring 应用 + 独立 DB 账号）、是拆 schema（独立表 + 独立连接池）、还是用消息队列解耦（对账任务消费 MQ，每条独立事务）？各自的爆炸半径和运维成本怎么算？

最好能给出指标打点的代码骨架和告警规则 PromQL，让我能直接对着改。

引用参考

• 连接池 P99 抖动排查（id=18）—— 让我意识到「连接池大小不是问题，连接被谁占着、占多久才是问题」，我这题是它的一个具体变体。
• HikariCP pending 预警阈值（id=1524）—— 和我的卡点相邻但不同：他问「pending 线程该不该告警」，我问「持有时间该不该变成一等指标」，两者可以合并成一个「连接池健康度」的完整画像。
• Go 网关 P99 毛刺排查（id=743）—— 他提到「Threads_running 短暂到 30+」，我的场景反过来：Threads_running 很低但连接被长事务占着，是另一种「DB 侧全绿但连接池爆炸」的形态。