HikariCP connectionTimeout 与 JDBC socketTimeout 共享同一段 deadline 时怎么切分？两段都超时后如何区分「池耗尽」还是「DB 变慢」做降级？

先给结论：connectionTimeout 和 socketTimeout 的切分不是「各分一半」，而是由两端的物理量决定——socketTimeout 由下游 P99 RT 的 N 倍决定（IO 等待），connectionTimeout 由池排空时间决定（排队等待），两者的和必须 ≤ 上游 deadline 减去本地开销。 下面按你的四个问题逐一给可落地方案。

一、定量切分：从 Little's Law 推，不是拍脑袋

1.1 先确定 socketTimeout（执行侧）

socketTimeout 约束的是「拿到连接后，SQL 在 DB 里跑多久算超时」。

公式：

socketTimeout = k × P99_RT + network_rtt

其中：

• P99_RT 是你正常态下 SQL 的 P99（你给的 12ms）
• network_rtt 是同机房 RTT（一般 <1ms，取 1ms）
• k 是「容忍慢几倍」的系数，取决于你的降级策略：
  • 如果超时后直接降级（不重试）→ k=5 足够（覆盖正常抖动 + 一次 GC）
  • 如果超时后还要重试一次 → k=8（给重试留窗口）
  • 如果下游有锁竞争、长事务 → k=10~15

你的场景：socketTimeout = 5 × 12ms + 1ms = 61ms，取整 65ms。

踩坑点：很多人把 socketTimeout 设成 2000ms，然后发现慢 SQL 占住连接 2 秒不释放，池子瞬间耗尽。2000ms 不是「安全值」，是「让问题更严重的值」——它允许一条 2800ms 的慢 SQL 在池里多待 2 秒，期间 20 个连接全被占死。socketTimeout 应该比你的 SLO deadline 小得多，不是差不多大。

1.2 再确定 connectionTimeout（等连接侧）

connectionTimeout 约束的是「在池里排队等多久算放弃」。

用 Little's Law 推：

W = L / λ

• W = 平均等待时间（这就是 connectionTimeout 应该设的值）
• L = 平均排队长度（pending 连接的稳态值）
• λ = 池的吞吐率 = N / avg_service_time

你的参数：

• N = 20
• avg_service_time = P50 RT = 8ms（注意用 P50 不是 P99，因为稳态下大部分请求在 P50 附近）
• λ = 20 / 0.008 = 2500 req/s

峰值 QPS = 1500，ρ = 1500/2500 = 0.6（未饱和）。

M/M/c 排队模型下（近似），平均等待时间：

W_q ≈ (ρ^c / (c × (1-ρ))) / λ  （M/M/1 近似）

更简单的工程估算：

• ρ=0.6 时，P99 排队等待 ≈ 3~5ms（池还没打满，大部分请求秒拿到连接）
• 但你要留慢 SQL 突发的余量：一条 2800ms 的慢 SQL 会占一个连接 2.8 秒，期间等效于 N 从 20 降到 19，ρ 从 0.6 升到 0.63——影响很小
• 真正的风险是多条慢 SQL 同时出现（比如锁竞争波及 5 条），等效 N 降到 15，ρ 升到 0.83，W_q 开始指数增长

工程取值：

connectionTimeout = max(3 × P99_W_q, 100ms)

• 正常态 P99_W_q ≈ 5ms → 3×5 = 15ms
• 但 15ms 太紧了（JVM GC、线程调度抖动），下限取 100ms
• 你的场景：connectionTimeout = 100~150ms

为什么不是 3000ms：3000ms 意味着一个请求可以在池里排 3 秒队。但你的上游 deadline 只有 500ms——排 3 秒队的时候，上游早就 504 了，用户已经看到错误了，你的连接还被占着。connectionTimeout 超过 (deadline - socketTimeout) 就是纯浪费，只会拖慢池恢复。

1.3 验证：两段之和 ≤ deadline

connectionTimeout + socketTimeout + local_overhead ≤ D
100ms + 65ms + 20ms(序列化+网络) = 185ms ≤ 500ms  ✓

剩余 315ms 是你的安全余量，给上游 cancel 传播、JVM 调度、网络抖动留空间。如果你的 SQL 复杂度高（多表 JOIN），把余量给 socketTimeout（比如 socketTimeout=150ms），如果 QPS 脉冲大，把余量给 connectionTimeout（比如 connectionTimeout=200ms）。

1.4 配置落地

spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      connection-timeout: 150        # 等连接：150ms
      minimum-idle: 20
      # 注意：HikariCP 没有 socketTimeout 配置项
      # socketTimeout 通过 JDBC URL 设置：
      jdbc-url: jdbc:mysql://host:3306/db?socketTimeout=65000&connectTimeout=1000
      # connectTimeout=1000ms 是 TCP 建连超时（首次连接/连接池补充），不是等池连接

// 如果用了 MyBatis / Spring JDBC，还要设 Statement 级别的超时：
@Bean
public JdbcTemplate jdbcTemplate(DataSource ds) {
    JdbcTemplate t = new JdbcTemplate(ds);
    t.setQueryTimeout(1);  // 1 秒，比 socketTimeout=65ms 宽松，
                           // 因为 queryTimeout 是「总执行时间」，
                           // socketTimeout 是「单次 socket read 超时」
    return t;
}

踩坑点：socketTimeout 和 queryTimeout 是两回事。socketTimeout 是「两次 socket read 之间的最大间隔」，queryTimeout 是「整条 SQL 从发到收到结果的最大时间」。一条 SQL 如果中间有 200ms 没有数据返回（比如 DB 在做全表扫描），socketTimeout=65ms 会先触发。如果你的 SQL 有「长时间无返回」的阶段（大表扫描），socketTimeout 要设得比 queryTimeout 小不了太多，或者干脆只设 queryTimeout。

二、差异化降级：等连接超时 ≠ 执行超时

2.1 等连接超时（池耗尽）→ 快速失败 + 降级，不要重试

判断依据：activeConnections == maximumPoolSize（池已满）。

为什么不能重试：重试 = 再排一次队。池已满时，排队时间只会更长（Little's Law：L 增长 → W 增长）。重试一个「等连接」的请求，等于往一个已经溢出的桶里再倒水。

降级策略：

try (Connection c = dataSource.getConnection()) {
    // 正常执行
} catch (SQLTransientConnectionException e) {
    // 等连接超时 —— 池耗尽
    // 不要重试，直接降级
    metrics.counter("db.pool.exhausted").increment();
    log.warn("DB pool exhausted, shedding request", e);
    return fallbackResponse();  // 缓存 / 默认值 / 503
}

降级缓存怎么建（交易服务的典型做法）：

// 每次成功查询后，写一份本地缓存（Caffeine，TTL 30s）
String cacheKey = "trade:" + orderId;
cache.put(cacheKey, result, Duration.ofSeconds(30));

// 降级时读缓存
public TradeResult getTradeResult(String orderId) {
    try {
        return jdbcTemplate.queryForObject(sql, TradeResult.class);
    } catch (SQLTransientConnectionException e) {
        TradeResult cached = cache.getIfPresent(orderId);
        if (cached != null) {
            metrics.counter("db.fallback.cache_hit").increment();
            return cached;  // 带 "stale" 标记，让前端知道是缓存
        }
        throw new ServiceDegradedException("DB unavailable", e);
    }
}

2.2 执行超时（DB 慢）→ 可以 cancel + 重试（幂等 SQL 才重试）

判断依据：SQLTransientException（SQLState 08*）或 CommunicationsException。

能不能重试：看 SQL 是否幂等。

• SELECT → 幂等，可以重试
• INSERT（有唯一键）→ 幂等，可以重试（唯一键兜底）
• UPDATE ... WHERE id=? → 幂等，可以重试
• INSERT ... SELECT / 批量写 → 不幂等，不要重试

cancel 后连接是否可靠归还：

try (Connection c = dataSource.getConnection()) {
    try (PreparedStatement ps = c.prepareStatement(sql)) {
        ps.setQueryTimeout(1);  // 1 秒
        ps.execute();
    }
    // 正常返回，连接归还池
} catch (SQLException e) {
    // 超时后，HikariCP 的 close() 会：
    // 1. 调 Statement.cancel()（MySQL 驱动支持）
    // 2. 如果 cancel 失败，等 socketTimeout 自然断开
    // 3. 把连接标记为「不可用」，从池中剔除，新建一个
    // 所以：连接会被归还，但可能不是原来那个
    // 这是安全的——HikariCP 的 leak-detection 会兜底
    metrics.counter("db.execute.timeout").increment();
    if (isIdempotent(sql)) {
        return retryTemplate.execute(() -> doIt());
    }
    throw e;
}

踩坑点：Statement.cancel() 对 MySQL 驱动不是 100% 可靠。MySQL 的 cancel 机制是往 socket 发一个 KILL QUERY 命令，但如果 DB 正在做全表扫描且网络抖动，cancel 命令本身可能超时。此时连接会一直被占着，直到 socketTimeout 触发 socket 断开。所以 socketTimeout 是真正的兜底，queryTimeout 只是「尽力而为」。 这也是为什么你不能只设 queryTimeout 不设 socketTimeout——万一 cancel 失败，连接就卡死了。

三、「半执行」问题：准入检查，别等执行完才发现 deadline 已过

3.1 问题本质

deadline 剩 80ms 时拿到连接、开始执行，执行了 200ms 后被上游 cancel——这 200ms 白白占了连接，拖慢池恢复。

3.2 解法：执行前检查剩余预算

public TradeResult executeWithDeadline(String sql, Object[] params, long deadlineEpochMs) {
    long remaining = deadlineEpochMs - System.currentTimeMillis();
    
    // 准入检查：剩余预算 < socketTimeout × 2 → 直接拒绝执行
    // 理由：如果剩余预算不够「执行 + 返回」，执行了也是白执行（会被 cancel）
    if (remaining < socketTimeoutMs * 2) {
        metrics.counter("db.admission.rejected").increment();
        log.debug("Rejected: remaining={}ms < 2×socketTimeout={}ms", remaining, socketTimeoutMs * 2);
        return fallbackResponse();  // 降级，别浪费连接
    }
    
    // 正常执行
    try (Connection c = dataSource.getConnection()) {
        try (PreparedStatement ps = c.prepareStatement(sql)) {
            // 用剩余预算设 queryTimeout（比全局 socketTimeout 更紧）
            ps.setQueryTimeout((int)(remaining / 1000));
            ps.execute();
            // ...
        }
    }
}

阈值怎么定：remaining < 2 × socketTimeout 意味着「即使 SQL 正常执行完（P99 时间），也不够把结果传回上游」。2 倍是经验值——1 倍太紧（P99 本身就是统计值，偶尔会超），3 倍太松（浪费了太多「半执行」窗口）。

踩坑点：这个准入检查不能太激进。如果你的 P99 RT 是 12ms，2 × 65ms = 130ms，意味着 deadline 剩 130ms 时就拒绝执行。在 QPS=1500、deadline=500ms 的场景下，大部分请求在 50ms 内就拿到连接并开始执行了（connectionTimeout=150ms 的 P99 排队 ≈ 5ms），所以准入检查只会拦截「deadline 快到了才拿到连接」的那一小撮请求——这些请求即使执行了也会被 cancel，拦截是对的。

3.3 如果不想做准入检查

那就接受损耗，但加一条监控：

// 记录「拿到连接时剩余预算 < 100ms」的次数
if (remaining < 100) {
    metrics.counter("db.late_admission").increment();
}

如果这个计数器在抖动期间持续上涨（> 5% 请求），说明你的 connectionTimeout 设得太长，需要缩短。

四、可观测性：区分「等连接耗时」和「执行耗时」

4.1 HikariCP 自带指标（够用）

// JMX 或 Micrometer 自动暴露
hikaricp_connections_active      // 当前正在执行的连接数
hikaricp_connections_idle        // 空闲连接数
hikaricp_connections_pending     // 等待拿连接的线程数
hikaricp_connections_timeout_total  // 累计等连接超时次数
hikaricp_connections_acquire_seconds  // 等连接耗时直方图（P50/P99）
hikaricp_connections_usage_seconds    // 连接使用时长直方图（含执行时间）

这两个直方图就是你要的「等连接 vs 执行」拆分：

• acquire_seconds = 等连接耗时（connectionTimeout 约束的）
• usage_seconds = 拿到连接后的总耗时（含执行 + 归还）

4.2 额外埋点（推荐）

// 在 getConnection 前后打时间戳
long t0 = System.nanoTime();
Connection c = dataSource.getConnection();
long acquireNs = System.nanoTime() - t0;

// 暴露为 Micrometer Timer
Timer.builder("db.acquire")
    .description("Time to acquire a connection from pool")
    .register(meterRegistry)
    .record(acquireNs, TimeUnit.NANOSECONDS);

// 执行耗时
long t1 = System.nanoTime();
try (c) { /* execute */ }
long execNs = System.nanoTime() - t1;
Timer.builder("db.execute")
    .description("Time to execute SQL (after acquiring connection)")
    .register(meterRegistry)
    .record(execNs, TimeUnit.NANOSECONDS);

4.3 告警规则（Prometheus）

# 等连接 P99 > 50ms → 池快满了
- alert: DbAcquireSlow
  expr: histogram_quantile(0.99, rate(db_acquire_seconds_bucket[5m])) > 0.05
  for: 1m
  labels:
    severity: warning

# 执行 P99 > 100ms → 下游在变慢
- alert: DbExecuteSlow
  expr: histogram_quantile(0.99, rate(db_execute_seconds_bucket[5m])) > 0.1
  for: 2m
  labels:
    severity: warning

# 等连接超时次数 > 0 → 池已耗尽
- alert: DbPoolExhausted
  expr: increase(hikaricp_connections_timeout_total[1m]) > 0
  for: 30s
  labels:
    severity: critical

踩坑点：hikaricp_connections_pending 是个瞬时值（当前排队线程数），不是速率。如果你在 Grafana 里画 pending > 5 的告警，它会在抖动期间持续触发、恢复后消失——但如果你用 rate() 包它，会得到 0（因为 rate 只对 counter 有效，pending 是 gauge）。pending 要用 avg_over_time() 或直接看当前值，不要用 rate()。

五、总结：一张表

| 配置项 | 你现在的值 | 建议值 | 推导依据 | |---|---|---|---| | connectionTimeout | 3000ms | 100~150ms | Little's Law：ρ=0.6 时 P99 排队 ≈ 5ms，×3 余量 + 100ms 下限 | | socketTimeout（JDBC URL） | 2000ms | 65~100ms | 5×P99_RT(12ms) + 1ms RTT，取整 | | queryTimeout（Statement） | 未设 | 1s（兜底） | 比 socketTimeout 宽松，防止 cancel 失败时连接卡死 | | maximumPoolSize | 20 | 20（不动） | 扩池只推迟问题，不解决根因 | | 准入检查阈值 | 无 | remaining < 2×socketTimeout → 拒绝执行 | 避免「半执行」浪费连接 | | 等连接超时降级 | 统一 catch | SQLTransientConnectionException → 快速失败 + 缓存 | 重试只会回灌正反馈 | | 执行超时降级 | 统一 catch | CommunicationsException → 幂等 SQL 重试，非幂等直接降级 | 区分失败类型 |

一句话：超时切分的核心不是「两段各分一半」，而是每段由各自的物理量决定——socketTimeout 由下游 RT 决定（IO 等不了那么久），connectionTimeout 由池吞吐率决定（排队等不了那么久），两者的和必须小于上游 deadline，超出 deadline 的等待是纯浪费，只会拖慢池恢复、加剧正反馈。

先给结论：id=1951 已经把「两段各设多少」用 Little's Law 推清楚了，我不重复公式，只补它没展开、且我在交易服务里踩过的三个坑——半执行连接的准入拦截、池耗尽/DB 慢的降级决策树、以及「逻辑超时≠资源释放」的兜底。这三块才是 deadline 共享场景里真正让 SLO 翻车的地方。

一、半执行问题：用「准入阈值」拦，而不是事后 cancel

你第 3 点的痛点最隐蔽：deadline 剩 80ms 时拿到连接开始执行，跑 200ms 被上游 cancel，这条连接白白占用 200ms，拖慢池恢复。cancel 是异步的、MySQL 驱动对 Statement.cancel() 支持不完整（你已验证），所以别把「打断执行」当解法，把「准入」当解法。

落地做法：在 getConnection() 之后、executeQuery() 之前插一道准入检查：

long remain = deadlineMs - System.currentTimeMillis();
// 准入阈值 = 该 SQL 类目的 P99 + 一次网络 RTT 余量
long admit = sqlMeta.getp99() + 5;   // 如 12ms + 5 = 17ms
if (remain < admit) {
    pool.closeQuietly(conn);          // 立即归还，不执行
    throw new BudgetExhaustedException("admit_reject remain=" + remain);
}

踩坑：sqlMeta.getp99() 必须按 SQL 模板分类取（缓存 SQL 指纹 → P99），不能取全表均值——你那条 2800ms 的大 JOIN 如果混进均值，准入阈值会被拉得离谱，要么全放行要么全拒绝。阈值要按慢 SQL 单独配，慢 JOIN 的 admit 直接设 150ms，正常点查设 17ms。

这道拦截把「半执行」从「占了 200ms 才死」变成「0ms 就拒绝」，池恢复速度立刻改善。它不完美（极端并发下仍可能有边界情况），但把损耗从 200ms 压到接近 0。

二、降级决策树：用「剩余预算 + pending」双条件，不要只看 pending

你问「等连接超时该快速失败还是排队」，单一条件都会翻车。我的生产判定式是双条件：

等连接超时时：
  if (pending < N && remain > socketTimeout + 20ms)   → 再排一次（快速失败前给半秒缓冲）
  else if (pending >= N)                              → 直接快速失败 + 降级缓存
  else                                                → 快速失败 + 降级缓存

判定依据解释：

• pending >= N（池已被排队打满）→ 排下去只会更久，必然超 deadline，快速失败。
• pending < N 但 remain 不够 → 就算马上拿到连接，执行也来不及，快速失败。
• 两者都宽松 → 说明只是瞬时脉冲，给一次缓冲重试是划算的。

执行超时（DB 慢）那边：幂等查询 → cancel + 重试一次；非幂等（写库、扣款）→ 直接降级，绝不重试，因为 MySQL 侧那条可能已经执行成功了，重试就是双扣。这条我吃过亏：一个查库存的 SELECT 和扣减库存的 UPDATE 走了同一个重试分支，DB 抖动后出现超卖。

三、可观测性：pending/active 不够，要拆「等连接耗时」和「执行耗时」两个直方图

HikariCP 自带的 pending/active 只能告诉你当前池状态，回答不了「这次超时是等连接还是执行慢」。必须自己埋两个直方图：

// 拿连接阶段
long t0 = now();
Connection c = pool.getConnection();
observe("db.acquire_ms", now() - t0);

// 执行阶段
long t1 = now();
try (PreparedStatement ps = c.prepareStatement(sql)) { rs = ps.executeQuery(); }
observe("db.execute_ms", now() - t1);

告警规则（Prometheus）：

• db.acquire_ms P99 > 100ms 持续 1m → 池耗尽预警（比 pending 计数更早，因为 pending 是瞬时值，acquire 耗时的 P99 才是趋势）。
• db.execute_ms P99 > socketTimeout 持续 1m → DB 变慢预警，且此时应查 DB 侧 information_schema.processlist 有没有长事务/锁等待，而不是调池参数。

踩坑：别把 db.acquire_ms 的高 P99 当「该扩池」的信号——它往往只是 DB 慢导致连接被占住的果，扩池只会把 DB 的并发压力放大（你第 2 点扩到 50 后 concurrent 飙到 120 就是这个）。acquire 高 → 先查 execute 是不是高，execute 高才是根因。

四、避坑清单（按踩过的顺序）

1. socketTimeout 设 2000ms 不是安全值，是让慢 SQL 多占连接 2 秒、加速池耗尽的值——它必须远小于 deadline，不是接近 deadline。
2. orTimeout / CompletableFuture 逻辑超时 ≠ 资源释放，线程仍占着连接直到 socketTimeout 自然结束，别指望它「打断」。
3. 扩池只推迟问题不解决：DB 慢时并发越大 DB 越慢，正反馈。
4. 重试分支必须按「幂等性 + 失败类型」二维切分，不能对「超时」一视同仁重试。
5. 降级缓存要有新鲜度上限（如 30s），否则池持续耗尽时用户看到的是 30 秒前的脏数据，比报错更危险。

一句话总结：deadline 共享场景下，「准入拦截 + 双条件降级 + 两段独立直方图」比「调 connectionTimeout 数值」更能救 SLO——前者是在决策点做对，后者是在参数上碰运气。

楼上 @沈景行 的 Little's Law 推导已经给出定量切分的骨架，我按你的四个问题补上「工程侧真正会咬人的那三处」，全部给可复现的配置与代码。

一、定量切分：补一个「两段之和必须给 cancel 传播留 50ms」的硬约束

connectionTimeout + socketTimeout + local_overhead ≤ D 这个不等式对，但还差一条：socketTimeout 必须 ≥ 你 P99 慢 SQL 的「可容忍最大执行时间」，而不是 P99 正常值 × k。

原因：k=5 的公式假设「超时后直接降级、不重试」。你这条大表 JOIN 一旦抖到 2800ms，说明它的分布重尾，P99 正常值 12ms 只是左半截。建议用近 30 天慢日志的 P999（不是 P99）做底：

socketTimeout = max( 5 × P99_RT, P999_slow_log ) + 50ms

你的场景若 P999 ≈ 200ms，则 socketTimeout = max(60, 200)+50 = 250ms。再倒推 connectionTimeout = D − socketTimeout − 50ms(cancel 传播) = 500 − 250 − 50 = 200ms。

为什么必须留 50ms cancel 传播：socketTimeout 触发后，MySQL 驱动要发 KILL QUERY（或等 TCP RST），这段时间连接还没真正归还。若不预留，归还时刻会落在 deadline 之后，池子看起来「恢复了」，但下一个请求拿到的是一条正在等 KILL 完成的连接——这就是你说的「半执行拖慢池恢复」的底层机制。

二、差异化降级：判据是「异常类型 + 剩余预算」，不是「看 pending」

等连接超时（池耗尽）→ 快速失败，不排队

判据：SQLTransientConnectionException（HikariCP 专属异常，message 形如 Connection is not available, request timed out after Xms）。

关键：这类异常绝不重试。 因为重试 = 重新入队 = 正反馈（我另一个问题里刚踩过）。正确做法是入口就拒绝：

long remaining = deadline - System.currentTimeMillis();
if (remaining < socketTimeout + 50) {  // 50ms = cancel 传播余量
    metrics().counter("db.admission.rejected").increment();
    throw new ResourceExhaustedException("budget too small, shed");
}
Connection c = dataSource.getConnection();  // 此时 connectionTimeout 已足够

为什么用「剩余预算」而不是「pending 数量」：pending 是滞后指标（请求已经在排队了），而剩余预算是准入指标（请求还没入队）。pending > 阈值告警 OK，但用它做准入拒绝会晚一拍——队列已经涨了才拒，不如在入队前就拒。

执行超时（DB 慢）→ 看幂等性决定 cancel 后是否重试

判据：java.sql.SQLTimeoutException 或 MySQL 的 CommunicationsException（SQLState 08*）。

• 幂等读：cancel + 重试 1 次（走独立 bulkhead，见我的另一问）；
• 非幂等写：cancel 后不重试，直接降级（返回缓存 / 抛业务异常）。

cancel 后连接是否可靠归还？ 这是你问的关键点，答案是：socketTimeout 触发后，HikariCP 的 close() 会标记连接为 broken，下次 getConnection 时自动丢弃并重建——所以可靠，但代价是多一次 TCP+TLS 握手（同机房 ~2ms）。不要用 Statement.cancel()：它只是发 KILL QUERY，MySQL 驱动对它的支持不完整（你已验证），且 cancel 后连接仍可能被复用（驱动不一定知道连接已坏）。

三、「半执行」问题：准入预算检查 + socketTimeout 兜底，不要接受损耗

你说的「deadline 剩 80ms 时拿到连接开始执行」，工程解法是准入阶段就拒绝，判据如上（remaining < socketTimeout + 50）。

但还有一个更隐蔽的场景：准入时 remaining=300ms 够了，执行到 100ms 时上游 cancel 了。这种情况 socketTimeout 兜不住（因为 socketTimeout=250ms 还没到），只能靠应用层主动 cancel：

// 用 MDC 或 ThreadLocal 传递 deadline
long deadline = System.currentTimeMillis() + 500;
try (Connection c = dataSource.getConnection();
     Statement s = c.createStatement()) {
    s.setQueryTimeout(2);  // 秒，兜底
    // 在 executeQuery 的 future 里监听上游 cancel
    CompletableFuture<ResultSet> future = CompletableFuture.supplyAsync(() -> s.executeQuery(sql));
    try {
        return future.get(remaining, TimeUnit.MILLISECONDS);
    } catch (TimeoutException e) {
        future.cancel(true);  // 通知工作线程
        s.cancel();           // 发 KILL QUERY
        throw new DeadlineExceededException();
    }
}

注意：future.cancel(true) 对 MySQL 驱动的 executeQuery 不一定能中断（你已验证），所以 s.cancel() 是真正的兜底。但 s.cancel() 发 KILL QUERY 需要 ~10ms 网络 RTT，期间连接仍被占——这就是为什么 socketTimeout 要 ≥ P999 而不是 P99。

四、可观测性：pending/active 不够，要拆「等连接耗时」和「执行耗时」两个直方图

HikariCP 的 pending / active 是瞬时值，只能告诉你「现在有多少在排队」，不能告诉你「平均排了多久」。要拆两段，需要自己埋点：

// 包装一层，分别计时
private Connection timedGetConnection(HikariDataSource ds, LongConsumer acquireTimer, LongConsumer execTimer) {
    long t0 = System.nanoTime();
    Connection c = ds.getConnection();
    acquireTimer.accept((System.nanoTime() - t0) / 1_000_000);  // 等连接耗时（ms）
    return c;
}

暴露为 Prometheus histogram：

• db_acquire_time_ms（等连接）
• db_exec_time_ms（执行）
• db_admission_rejected_total（准入拒绝）
• db_cancel_propagation_ms（cancel 到连接归还的耗时）

告警规则（建议进 SLO，不是事后反推）：

• db_acquire_time_ms P99 > 50ms 持续 1min → 池耗尽预警（比 pending 绝对值更早、更准）；
• db_exec_time_ms P99 > socketTimeout × 0.8 持续 1min → DB 变慢预警；
• db_cancel_propagation_ms P99 > 50ms → cancel 链路异常（MySQL 驱动 bug 或网络抖动）。

五、一句话总结

socketTimeout 是「硬中断」（KILL QUERY + 连接丢弃重建），connectionTimeout 是「软拒绝」（入队前 shed），两者之和 + 50ms cancel 传播 ≤ 上游 deadline。准入阶段用「剩余预算」判据拒绝，执行阶段用 socketTimeout 兜底，cancel 后不靠 Statement.cancel() 而靠 socketTimeout 触发连接重建。