3. Closed 状态详解：正常调用流程、计数器机制、滑动窗口算法原理

Closed 状态是 Circuit Breaker 的初始状态，也是系统正常运行时的默认状态。在此状态下，断路器允许所有请求通过，并持续监控请求的成功/失败比率。当失败率超过预设阈值时，断路器将触发状态转换至 Open 状态。理解 Closed 状态的核心机制，是进行性能调优和压测分析的基础。

3.1 正常调用流程

在 Closed 状态下，每一次外部调用都遵循以下标准流程：

1. 请求到达：客户端发起远程调用（如 RPC、HTTP 请求）。
2. 计数器记录：断路器拦截请求，将本次调用计入“总请求数”计数器。
3. 执行调用：请求被转发至下游服务或资源。
4. 结果判定：根据调用结果（成功/失败/超时/异常），更新对应的成功或失败计数器。
5. 阈值检查：每次调用结束后，断路器检查当前时间窗口内的失败率是否超过阈值。
6. 状态维持或转换：若失败率低于阈值，保持 Closed 状态；若超过阈值，则切换至 Open 状态。

3.2 计数器机制

计数器是 Closed 状态最基础的实现方式。它维护两个核心指标：

计数器机制的判定逻辑如下：

// 伪代码：计数器模式阈值判定
long totalCount = requestCounter.get();
long failCount = failureCounter.get();

// 只有当总请求数达到最小请求数时，才进行阈值判定
if (totalCount >= MINIMUM_REQUEST_THRESHOLD) {
    double failureRate = (double) failCount / totalCount;
    if (failureRate > FAILURE_RATE_THRESHOLD) {
        // 切换到 Open 状态
        stateTransition(State.OPEN);
    }
}

3.3 滑动窗口算法原理

滑动窗口算法将时间划分为多个细粒度的时间片（Bucket），每个 Bucket 独立记录该时间段内的请求数据。窗口随时间向前滑动，丢弃过期 Bucket 的数据，从而更平滑地反映最近的系统状态。

3.4 滑动窗口 vs 计数器：性能与准确性对比

3.5 滑动窗口的 Bucket 轮换策略

滑动窗口的核心在于 Bucket 的创建与过期管理。常见的实现策略有两种：

• 定时轮换：使用后台线程定期（如每 100ms）创建新 Bucket，并丢弃最旧的 Bucket。实现简单，但存在时间片对齐问题。
• 懒创建 + 时间戳对齐：仅在请求到达时检查当前时间戳，若已进入新的时间片则创建新 Bucket。更精确，但需处理并发创建问题。

3.6 压测场景下的关键参数配置

在性能压测中，Closed 状态的以下参数直接影响系统行为和稳定性：