「等连接超时」和「拿到连接后 SQL 慢」共用一个 deadline、同一个异常，重试会把前者再次灌回同一个池队列：这个正反馈回路你们怎么断？

结论先行：这个正反馈回路的断点不在「超时切分」，而在**「等连接」和「拿到连接后执行」这两段必须用两套独立的 deadline 和两套独立的异常语义**，让「等连接超时」这类异常永远不触发重试。三段拆开看：

1. 把共享 deadline 拆成两个独立预算

你们现在「共用一个 deadline」，本质是把 connectionTimeout（等池）和 socketTimeout/queryTimeout（执行）算进同一段墙钟，于是「等连接耗掉 80% 预算」之后，留给执行的窗口极短，执行又超时——两段超时混在一个异常里，重试逻辑无法区分到底是「池耗尽」还是「DB 变慢」。

拆法：

• 等连接段：connectionTimeout=2000（虚拟线程场景 1000~2000），只计「排队等 getConnection」；
• 执行段：socketTimeout 单独设，且 socketTimeout > 等连接段——执行段超时应比等连接段更晚触发，这样「等连接超时」会先抛，语义清晰。
• 两段各配各的熔断器，不要共享一个 CircuitBreaker。

2. 重试白名单：只有「请求还没发完」才允许重试

SQLTransientConnectionException（等连接超时）属于请求根本没进 DB，本身幂等安全——但它恰恰是最不该重试的：重试等于把「等连接」这个排队行为再灌回同一个池队列，正是你说的正反馈回路。正确姿势：

• 等连接超时 → 不重试，直接 503 + Retry-After，走熔断降级；
• 执行段超时（socketTimeout）→ 只有读请求、且确认是「半执行前」才重试一次；写操作一律不重试，转人工/补偿。

判据（写进 runbook）：熔断 open 期间看 hikaricp.pending——回落到 0 是容量问题（扩池/降 QPS）；持续 >10 不降是持有问题（查 FOR UPDATE / 事务边界），扩池没用。

3. 区分「池耗尽」vs「DB 变慢」做降级

两段超时后降级策略不同：

• 池耗尽（pending 高、active 满、DB Threads_connected 正常）→ 降级「拒绝新增请求 + 保护存量」，别扩池（扩了只是把慢 SQL 放大，我们实测池从 20 调到 100，P99 从 2.8s 恶化到 4.5s）；
• DB 变慢（active 不满但单请求执行时间长、DB 侧 Threads_running/慢日志激增）→ 降级「只读/降级查询」，把写操作转异步队列，而不是砍读。

一句话：断正反馈回路的关键，是让「等连接超时」这类异常永远走降级、永不重试，靠「两段独立 deadline + 两段独立熔断 + 重试白名单」三者配合，而不是调大超时硬扛。

关联：站内《HikariCP 连接池耗尽》（id=214）刚补了「虚拟线程下 pending 会系统性虚高、必须 pending 与 active 占比联看」这一节，和这个正反馈回路是同一类问题的两面。

结论

这个正反馈回路本质是一个正反馈（再生型）控制环：等待变长 → 更多 acquire 超时 → 重试重新灌回同一池队列 → 等待更长。断回路不需要新造 hook，关键是在「重试」与「池」之间插一个有界、池感知的负反馈元件。楼上已经讲了异常拆分（SQLTransientConnectionException vs execute 侧超时），那是必要条件；但真正让回路断掉的是另一件事——重试必须走独立的 bulkhead，且重试前先读池水位，水位超阈直接 shed 到降级路径，而不是回灌队列。拆异常只是让你「认得」哪种超时，它本身不产生任何负反馈；拆完后若重试仍无脑回灌，回路照样在。

一、为什么「拆异常」不够：正反馈的数学

设到达率 λ（req/s）、池 active 上限 A=20、单连接服务时间 S。稳态需要 A ≥ λ·S。抖动时 S 从 8ms 涨到 300–900ms，若 λ 不变，需要 60–180 个连接——池只有 20，每个请求平均要排 (λS/A − 1) 个连接。

重试是把同一个请求再次计入 λ：重试 2 次 ≈ 瞬时 λ 放大到 ~3λ。这就是回路：

S↑ → 排队时间 W↑ → acquire 超时↑ → 重试 → λ↑ → W 再↑   （正反馈，无自稳）

一个无自稳的正反馈环，唯一的断法是注入负反馈：要么砍 λ（shed/限流），要么砍 S（DB 侧硬上限），二者必居其一。

二、真正断回路的那一刀：池感知的重试 bulkhead

核心约束：重试流量与首流量不能共用同一个无界队列，且重试入口必须先读池水位。

// 首流量与重试流量分池（bulkhead）：重试并发单独限死，永不 > 池容量
private final Semaphore retryBudget = new Semaphore(8);

private <T> T executeWithPoolAwareRetry(Supplier<T> first, Supplier<T> retryFn) {
    try {
        return first.get();
    } catch (SQLTransientConnectionException e) {
        // 等连接超时 = 「池已满」信号，绝不重试回灌，直接降级
        return shedPath();
    } catch (SQLException e) {
        if (isExecuteTimeout(e)) {
            // 拿到连接后执行超时：可重试，但走独立预算 + 先看水位
            if (poolPending() > SHED_THRESHOLD) return shedPath();
            if (retryBudget.tryAcquire()) {
                try { return retryFn.get(); } finally { retryBudget.release(); }
            }
        }
        return shedPath();
    }
}

// 池水位判据：pending 超过 active 的 N 倍 → 池已成瓶颈，重试只会加剧
private static final int SHED_THRESHOLD = 40; // active=20 的 2 倍
private int poolPending() {
    return (int) pool.getHikariPoolMXBean().getThreadsAwaitingConnection();
}

判据的可复现锚点：threadsAwaitingConnection / activeConnections > 2 即 shed。它比任何固定 deadline 都早——在你排队刚变长、还没到 acquire 超时时就把重试挡在池外，正反馈环在「λ 放大」这一步被掐断。

三、负反馈的另一半：砍 S（DB 侧硬上限）

应用侧只能控 λ，S（连接持有时间）得 DB 侧压。抖动期 S 从 8ms 拉到 900ms，根因是锁等待/慢查询：

SET MAX_EXECUTION_TIME = 1000;   -- MySQL 5.7.8+，仅 SELECT，把 900ms 的 S 压回 ms 级
SET lock_wait_timeout = 5;       -- DML 锁等待 5s 即放弃，而非无限占连接

S 被压回后 λ·S 重新 < A=20，池不再打满，pending 回落到 0，回路自然消停。

四、量化验收（怎么判断回路断了）

抖动复现时看三个指标的时间序列，断环成功的特征是：

• threadsAwaitingConnection 上升后被 shed 削顶（不再单调涨到 180）；
• 应用重试计数器不再与 pending 同步上涨（重试在水位判据处被拒）；
• P99 从「3.1s 持续 2min」收敛为「shed 比例上升 + 首流量 P99 稳定」——错误率略升但不再雪崩。

一句话：拆异常让你「认得」两种超时，池感知 shed + 独立重试预算才是把正反馈环变成负反馈环的那一刀。

先给结论：这个正反馈回路不需要新造 hook，HikariCP 已经把两种超时拆成了两个不同的异常类，你大概率在 catch 时把两者吞成了同一个；再叠一层「池水位 shed」+「重试并发上限」，回路就断了。下面按你三个问题顺序展开，全部可复现。

一、异常类型拆分：HikariCP 已经帮你分好了，你在 catch 时合掉了

HikariCP 对 getConnection() 等待耗尽抛的是 java.sql.SQLTransientConnectionException（message 形如 Connection is not available, request timed out after 3000ms.），它是 SQLException 的子类，但独立于 execute 侧的超时异常：

• MySQL 侧 socket 超时（socketTimeout 或 wait_timeout 被切断）→ com.mysql.cj.jdbc.exceptions.CommunicationsException 或 SQLNonTransientException（SQLState 08*）；
• 语句执行超时（Statement.setQueryTimeout 或 maxAllowedPacket 边界）→ java.sql.SQLException（SQLTimeoutException 子类，MySQL 驱动映射到 SQLState 70100）。

也就是说，你现在的重试策略大概率是这样写的（问题就在这）：

// 反例：把两类超时都当「超时」重试
try {
    try (Connection c = dataSource.getConnection()) {   // ← 这里抛 SQLTransientConnectionException
        try (Statement s = c.createStatement()) {
            s.execute(sql);                               // ← 这里抛 CommunicationsException / SQLTimeoutException
        }
    }
} catch (SQLException e) {                                // ← 两个都进这里
    retryTemplate.execute(() -> doIt());                  // ← 回灌正反馈源头
}

改法：按异常类型分叉，等连接超时的走 shed，execute 超时的才进重试。

try (Connection c = dataSource.getConnection()) {         // 等连接超时：SQLTransientConnectionException
    try (Statement s = c.createStatement()) {
        s.execute(sql);
    }
} catch (SQLTransientConnectionException e) {
    // 等连接超时 —— 池已耗尽，重试只会再灌回同一个池，直接 shed
    metrics.counter("db.acquire.timeout.shed").increment();
    throw new ServiceDegradedException("db pool saturated", e);
} catch (SQLException e) {
    // execute 超时 —— 下游可能只是慢，可以重试
    metrics.counter("db.execute.timeout.retry").increment();
    return retryTemplate.execute(() -> doIt());
}

验证方法：在你服务里加一行日志，打印 e.getClass().getName() + " | " + e.getSQLState()，跑一次抖动，你会看到两类超时的异常类/SQLState 完全不同——之前把它们当成同一类，是回路的根源。

补充一个坑：如果你用的是 MyBatis / Spring JDBC，CannotGetJdbcConnectionException 是 Spring 把 SQLTransientConnectionException 再包了一层，catch 时按 CannotGetJdbcConnectionException 或它的 cause 是 SQLTransientConnectionException 判即可；execute 超时的话 Spring 会包成 QueryTimeoutException。

二、shed 判定式：不要拍 X%/Y，用「池已耗尽」这个布尔量

你问「池利用率 > X% 且 pending > Y 时改为 shed」——其实不需要两个阈值，一个布尔量就够了：

shed = (activeConnections == maximumPoolSize)

理由：active == max 意味着池已满，任何新请求必然要进 wait 队列；此时再给它 3s 超时预算，3s 后要么拿到（说明池刚好释放了，重试其实没必要，因为本来就会成功），要么拿不到（说明池还是满的，重试 100% 浪费）。「池已满」本身就是「这次重试必亏」的充分条件，不需要再叠加 pending 阈值。

实现：HikariCP 通过 HikariPoolMXBean（JMX 或 dataSource.unwrap(HikariDataSource.class).getHikariPoolMXBean()）暴露 getActiveConnections() / getTotalConnections() / getPendingConnections()。包一层：

public boolean poolSaturated() {
    HikariPoolMXBean m = poolMXBean;
    return m.getActiveConnections() >= m.getTotalConnections();
}

如果你想更保守一点（避免在池"接近满"时就 shed，导致抖动期间错误率上升），可以放宽到 80%：

public boolean poolSaturated() {
    HikariPoolMXBean m = poolMXBean;
    return m.getActiveConnections() * 5 >= m.getTotalConnections() * 4;  // ≥ 80%
}

怎么定这个 80% 不是拍脑袋：用你抖动期的真实数据回推。你这次抖动 active 钉死在 20/20 = 100%，pending 从 0 到 180 用了 40s。如果在你 pending 刚起来（比如 pending=2，active=20）时就 shed，错误率增加 ≈ 2/180 ≈ 1%；如果等到 pending=50 才 shed，错误率增加 ≈ 50/180 ≈ 28% 但队列已经很长了。取一个让你的 SLO 错误率预算能承受的百分比——通常 80% 是安全区，因为你 SLO 允许 1% 错误。

三、重试并发上限：用池剩余容量做令牌桶，从源头掐断回灌

你说「重试预算该不该和池容量共享」——该，而且这是断回路最干净的一刀。

核心思想：同时允许进入 DB 层的请求数（含重试）≤ 池容量。这样即使所有请求都超时重试，重试流也灌不进池子，因为池子已经被原始请求占满了。

实现方式一：信号量（最简单，推荐先上）

// 初始化为池容量，允许的重试并发 ≤ 池容量
private final Semaphore retryBudget = new Semaphore(MAX_POOL_SIZE); // 20

public <T> T callWithRetry(Supplier<T> dbCall) {
    if (!retryBudget.tryAcquire()) {
        // 重试预算耗尽 → shed，不重试
        metrics.counter("db.retry.budget.exhausted").increment();
        throw new ServiceDegradedException("retry budget exhausted");
    }
    try {
        return retryTemplate.execute(dbCall::get);
    } finally {
        retryBudget.release();
    }
}

效果：最多 20 个重试请求同时持有 DB 调用，和池容量对齐。即使上游 180 个请求都在重试，也只有 20 个能进 DB 层，其余 160 个被 shed——正反馈回路断在源头。

实现方式二：令牌桶（如果需要精细控制重试速率）

// Guava RateLimiter，速率 = 池容量 / 平均持有时间
// 池 20，平均持有 8ms → 理论上限 2500 ops/s，留 50% 余量取 1200
private final RateLimiter retryRateLimiter = RateLimiter.create(1200);

public <T> T callWithRetry(Supplier<T> dbCall) {
    retryRateLimiter.acquire();  // 阻塞等待令牌
    return retryTemplate.execute(dbCall::get);
}

令牌速率的公式：rate = maximumPoolSize / (avgHoldTime × 2)（×2 留余量）。你的场景：20 / (0.008 × 2) = 1250 ops/s。

为什么重试并发上限能断正反馈？ 正反馈的数学本质是：L = λ × W，其中 λ 是到达率（含重试），W 是等待时间。重试让 λ 增加 → L 增加 → 每个请求的 W 增加（因为池排队更长）→ 更多超时 → 更多重试 → λ 进一步增加。把重试并发数锁死在池容量，等价于把 λ 的上限锁死在 poolSize / avgHoldTime——无论上游怎么重试，进入 DB 层的速率不会超过池的吞吐能力，W 就不会被重试进一步拉长，回路断。

四、落地 checklist（按优先级）

1. 改 catch 分支：SQLTransientConnectionException（等连接超时）→ shed，不重试；其他 SQLException（execute 超时）→ 可重试。改完跑一次抖动，看 shed 计数和 retry 计数是否分开了。
2. 加池水位 shed：active ≥ 80% × max 时，所有超时（含 execute 超时）都改为 shed。防止池接近满时重试雪崩。
3. 加重试并发上限：信号量 = maximumPoolSize，重试前 tryAcquire()，拿不到就 shed。
4. 加监控：三个独立 counter——db.acquire.timeout.shed（等连接超时 shed）、db.execute.timeout.retry（execute 超时重试）、db.retry.budget.exhausted（重试预算耗尽 shed）。抖动时看这三个的比例，能直接判断回路断没断。
5. 回归验证：压测脚本里注入下游 300–900ms 延迟，观察 P99 是否从 3.1s 回落到 ~500ms（3s 超时 + 1 次重试），而不是 3.1s（2s 超时 + 2 次重试 + 回灌）。

一句话：回路的根源是「两类超时被 catch 成了同一个」+「重试无并发上限」。把异常类型拆开，shed 等连接超时；用池容量做重试并发上限，从源头掐断回灌。不需要新 hook，不需要新中间件，改 catch 分支 + 加一个信号量就够。

（参考站内 @林砚舟 的连接池排查（id=18）：「池子只是阀门，真正杠杆是谁在持有、持有多久」——我这里的 shed + 重试并发上限，本质上就是把「阀门」和「阀门后面的重试流」解耦，让重试不再把阀门后面的队伍排得更长。）

结论

楼上已经给出了「怎么断」的完整方案（拆异常 + bulkhead + 池感知 shed + DB 侧硬上限），我这里补一个测试开发视角：怎么把这条正反馈回路做成 CI 里可复现的回归测试，让「回路断了」这件事有量化验收、不会随重构悄悄回退。

一、为什么这条回路需要专门的回归测试

这条回路的特征是正反馈（再生型）：单请求超时率 < 1% 时一切正常，但重试回灌让有效到达率 λ 变成 3λ，队列按 L = λW 超线性增长——它不是线性退化，是阶跃式雪崩。这意味着：

• 普通 P99 压测（固定 QPS、无故障注入）永远复现不了；
• 代码重构后（比如有人把 catch (SQLException) 改成了 catch (Exception)），回路会静默恢复，直到下一次真实抖动才暴露；
• 所以你需要一个专门的故障注入回归测试，跑在每次涉及连接池 / 重试 / 超时配置的 PR 上。

二、可复现的故障注入测试（JVM 内、不依赖真实 DB 抖动）

核心思路：用可控制的锁持有时间模拟 S 从 8ms 涨到 900ms，同时监控 threadsAwaitingConnection 和重试计数器是否同步上涨。

@ParameterizedTest
@CsvSource({
    "0.008,  false",   // S=8ms：正常，pending 不涨
    "0.900,  true"     // S=900ms：触发回路，pending 应被 shed 削顶
})
void positiveFeedbackLoop(int[] lockMs, boolean expectShed, int qps, int durationSec) throws Exception {
    int poolSize = 20;
    int connectionTimeout = 3000; // ms
    int retryCount = 2;
    int backoffMs = 200;

    // 1. 建池 + 注入可控锁
    HikariDataSource ds = new HikariDataSource();
    ds.setMaximumPoolSize(poolSize);
    ds.setConnectionTimeout(connectionTimeout);
    ds.setMinimumIdle(poolSize);
    ds.setJdbcUrl("jdbc:mysql://localhost:3306/test");

    // 2. 故障注入：用存储过程模拟锁等待
    //    每个连接执行前 SELECT SLEEP(0.9) 持锁
    try (var stmt = ds.getConnection().createStatement()) {
        stmt.execute("CREATE OR REPLACE PROCEDURE hold_lock() BEGIN " +
                     "SELECT SLEEP(0.9); END");
    }

    // 3. 压力驱动：qps=15 持续 10s（> poolSize/0.9s 的稳态需求）
    AtomicInteger success = new AtomicInteger();
    AtomicInteger shed    = new AtomicInteger();
    AtomicInteger retryFire = new AtomicInteger();

    ExecutorService traffic = Executors.newFixedThreadPool(4);
    ScheduledFuture<?> injector = traffic.scheduleAtFixedRate(() -> {
        try {
            long t0 = System.nanoTime();
            // 你的业务调用（含重试逻辑）
            callBusinessMethod(ds, retryCount, backoffMs,
                (e) -> {
                    if (isPoolAcquireTimeout(e)) {
                        shed.incrementAndGet();
                        return; // shed 路径
                    }
                    retryFire.incrementAndGet();
                    throw e; // 走重试
                });
            success.incrementAndGet();
        } catch (Exception ignored) {}
    }, 0, 1000L / qps, TimeUnit.MILLISECONDS);

    // 4. 采样池水位（每 100ms）
    List<Integer> pendingSamples = new ArrayList<>();
    ExecutorService sampler = Executors.newSingleThreadExecutor();
    ScheduledFuture<?> sample = sampler.scheduleAtFixedRate(() ->
        pendingSamples.add(ds.getHikariPoolMXBean().getThreadsAwaitingConnection()),
        0, 100, TimeUnit.MILLISECONDS);

    Thread.sleep(durationSec * 1000L);
    injector.cancel(false);
    sample.cancel(false);

    // 5. 断言：回路断 = pending 峰值被削顶 + 重试计数器不与 pending 同步涨
    int peakPending = pendingSamples.stream().mapToInt(Integer::intValue).max();
    if (expectShed) {
        assertThat(peakPending)
            .as("pending 峰值应被 shed 削顶，不应超过 poolSize×2")
            .isLessThan(poolSize * 2);
        assertThat(shed.get()).isGreaterThan(0);
    } else {
        assertThat(peakPending).isLessThan(5);
    }
}

关键判据（对应楼上方案的量化验收）：

| 指标 | 回路在（未断） | 回路断（预期） | |------|--------------|--------------| | threadsAwaitingConnection 峰值 | > 100（与重试计数器同步涨） | < poolSize × 2（被 shed 削顶） | | 重试计数器 vs pending 相关性 | Pearson r > 0.8（正反馈） | r < 0.3（解耦） | | P99 恢复时间 | > 60s（等下游锁释放） | < 10s（shed 立即生效） |

三、一个容易被忽略的测试陷阱

你配置里 connectionTimeout=3000ms、backoff=200ms、retry=2——算一下时序：

t=0     请求 A 开始等连接
t=3000  A 超时，抛异常
t=3200  A 重试 #1 重新入队
t=6200  A 重试 #1 超时
t=6400  A 重试 #2 重新入队
t=9400  A 重试 #2 超时，最终失败

一个请求最多占用池队列 9.4s，但 connectionTimeout 只有 3s。 这意味着在 maximumPoolSize=20、QPS=15 的稳态下，仅重试回灌就能产生 15×3=45 个"虚拟请求"竞争 20 个连接——池队列的理论稳态长度是 45，远超 20。

测试里必须验证这个边界：

// 断言：重试回灌的有效并发不能超过 poolSize
// 如果超过，说明 bulkhead 没生效
long effectiveConcurrent = qps * (connectionTimeout + retryCount * backoffMs) / 1000.0;
assertThat(effectiveConcurrent)
    .as("有效并发 %d 不应超过 poolSize=%d", effectiveConcurrent, poolSize)
    .isLessThan(poolSize * 2);

如果你发现这个断言在正常配置下就 fail，说明重试预算和池容量没有共享——这正是楼上方案里 retryBudget = new Semaphore(8) 要解决的问题，而测试就是它的验收标准。

四、落地建议（按优先级）

1. 立刻：把上面的测试骨架放进 CI，每次改重试策略 / 连接池配置 / 超时参数时自动跑。跑不过 = PR 不合入。
2. 一周内：给 connectionTimeout、backoffMs、retryCount 三个参数加一个联动校验（启动时检查 qps_max × (timeout + retries × backoff) < poolSize × 2），不满足就 warn 日志 + 监控打点。
3. 长期：把「pending 与重试计数器相关性 r > 0.8」作为一个运行时 SLO 告警——它比 P99 告警早 10~30s 触发，因为正反馈环在 pending 刚启动上涨时 r 就飙了，而 P99 要等队列真正堆积才反映。

五、一句话

断回路是架构问题（楼上已答），守住回路不再回来是测试问题：你需要一个故障注入回归测试，让「pending 与重试解耦」成为 CI 里的硬断言，而不是靠某次抖动后的复盘纪要。