2. Go并发基础回顾：goroutine、channel、sync.WaitGroup、context包在限流熔断中的应用

限流与熔断本质上是并发控制与请求生命周期管理的问题。Go 语言的原生并发原语——goroutine、channel、sync.WaitGroup 以及 context 包——恰好为构建这些骨架提供了最直接、最底层的工具。本章将回顾这些基础并发元素，并直接映射到限流熔断场景中的具体职责。

2.1 核心并发原语与限流熔断的映射关系

下表梳理了每个并发原语在限流熔断骨架中的典型角色，帮助你在后续章节中快速定位其用途。

2.2 goroutine：限流熔断的执行载体

在限流熔断系统中，每一个被保护的请求通常在一个独立的 goroutine 中执行。goroutine 的轻量特性（初始栈仅几 KB）使得系统可以同时处理成千上万个并发请求，而不会因为线程切换开销导致限流器本身成为瓶颈。

// 示例：使用 goroutine 启动后台令牌补充任务
go func() {
    ticker := time.NewTicker(100 * time.Millisecond)
    defer ticker.Stop()
    for {
        select {
        case <-ticker.C:
            // 向令牌桶补充一个令牌
            select {
            case tokenCh <- struct{}{}:
            default:
                // 桶已满，丢弃
            }
        case <-ctx.Done():
            return
        }
    }
}()

2.3 channel：令牌传递与事件通知

channel 是 Go 中 goroutine 之间通信的一等公民。在限流场景中，channel 天然适合实现令牌桶模型：令牌本身就是一个空结构体，通过带缓冲的 channel 控制并发数量。

• 有缓冲 channel：直接作为令牌桶，缓冲区大小等于桶容量。请求尝试从 channel 接收令牌，接收成功则通过，失败则触发限流。
• 无缓冲 channel：用于精确的信号同步，例如熔断器状态变更通知所有等待的 goroutine。
• select + default：实现非阻塞的限流判断，避免请求被阻塞在 channel 操作上。

// 基于 channel 的简单令牌桶限流器
type TokenBucket struct {
    tokens chan struct{}
}

func NewTokenBucket(rate int) *TokenBucket {
    tb := &TokenBucket{
        tokens: make(chan struct{}, rate),
    }
    // 初始装满令牌
    for i := 0; i < rate; i++ {
        tb.tokens <- struct{}{}
    }
    return tb
}

func (tb *TokenBucket) Allow() bool {
    select {
    case <-tb.tokens:
        return true
    default:
        return false
    }
}

2.4 sync.WaitGroup：并发任务编排

在限流熔断的初始化阶段或批量检测场景中，sync.WaitGroup 用于等待一组 goroutine 全部完成。例如，启动多个限流器实例后，需要等待所有实例预热完毕再对外提供服务；或者在熔断器关闭前，等待所有正在处理的请求完成。

// 使用 WaitGroup 等待多个限流器初始化完成
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
    wg.Add(1)
    go func(id int) {
        defer wg.Done()
        // 模拟限流器初始化
        time.Sleep(time.Duration(id) * 100 * time.Millisecond)
        fmt.Printf("限流器 %d 就绪\n", id)
    }(i)
}
wg.Wait()
fmt.Println("所有限流器已就绪，开始接受请求")

2.5 context：超时控制与请求级取消

context 包在限流熔断中承担着请求生命周期管理的核心角色。熔断器进入 Open 状态后，所有后续请求应立即取消，此时通过 context.WithCancel 派生的 context 可以快速传播取消信号。限流器等待超时时，使用 context.WithTimeout 或 context.WithDeadline 控制最大等待时间。

// 使用 context 实现可取消的限流等待
func (tb *TokenBucket) Wait(ctx context.Context) error {
    select {
    case <-tb.tokens:
        return nil
    case <-ctx.Done():
        return ctx.Err() // 返回 DeadlineExceeded 或 Canceled
    }
}

// 熔断器取消所有等待请求
func (cb *CircuitBreaker) Open() {
    cb.mu.Lock()
    defer cb.mu.Unlock()
    cb.state = StateOpen
    cb.cancel() // 取消所有通过此 context 等待的请求
    cb.ctx, cb.cancel = context.WithCancel(context.Background())
}

2.6 并发原语协作架构图

下图展示了 goroutine、channel、sync.WaitGroup 和 context 在限流熔断骨架中的协作关系。请求进入后，先经过限流器（channel 令牌判断），再进入熔断器（context 取消信号检测），最终由 goroutine 执行实际业务逻辑。

2.7 常见并发陷阱与限流熔断中的规避

在限流熔断系统中，并发原语的误用可能导致死锁、资源泄漏或限流失效。以下是三个最常见的陷阱及规避策略。

• goroutine 泄漏：启动的后台协程（如令牌补充、熔断检测）没有退出机制。必须使用 context.Done() 或 close(channel) 作为退出信号。
• channel 阻塞导致死锁：在限流器中使用无缓冲 channel 且没有 default 分支时，如果接收方未就绪，发送方会永久阻塞。始终使用 select + default 实现非阻塞操作。
• WaitGroup 计数不一致：Add() 与 Done() 调用次数不匹配，导致 Wait() 永远阻塞或提前返回。建议使用 defer wg.Done() 确保计数正确。