Go sync.Cond 为什么不是 channel 替代品：广播等待队列的边界

有一类 Go 并发场景看起来很像“等一个通知”：库存没准备好时先挂起，批量任务攒够阈值后再统一放行，配置热更新后让一批等待的协程继续运行。很多人写代码第一反应是塞一个 channel，但如果真正要等待的是一份会被多个 goroutine 共同读取的状态，sync.Cond 往往更贴合问题的本质。

channel 传递的是值或事件，sync.Cond 等待的是“某个受锁保护的条件变为真”。条件变量不会替你保存业务状态，也不自带关闭语义；每次唤醒后都必须重新加锁检查条件。

库存闸门场景：等待的到底是消息还是状态

假设一个批处理服务有 slots 个可用执行名额。请求到达时如果没有空闲名额，调用方不需要反复轮询；名额归还之后，等待中的请求可以重新检查共享计数。

这个场景不存在“每个请求对应专属一条消息”的设定。真正核心的是 slots > 0 这件事。名额从 0 变成 8 时，直接唤醒一批 goroutine 比手动构造 8 个通知值更自然，最终能不能继续执行，还是由每个 goroutine 抢锁之后判断。

原架构的坑：用 channel 硬套共享状态逻辑

用 channel 也能实现简化版的闸门逻辑：发送令牌代表拿到名额，用完归还时再塞回 channel 里。这种写法很适合固定数量的令牌场景，但一旦业务还要读取实时配置、动态扩容、批量唤醒或者区分“服务关闭”和“名额不足”两种状态，channel 里很快就会混入多种语义，维护成本陡增。

type Gate struct {
	mu    sync.Mutex
	cond  *sync.Cond
	slots int
}

func NewGate(n int) *Gate {
	g := &Gate{slots: n}
	g.cond = sync.NewCond(&g.mu)
	return g
}

func (g *Gate) Acquire() {
	g.mu.Lock()
	defer g.mu.Unlock()
	for g.slots == 0 {
		g.cond.Wait()
	}
	g.slots--
}

func (g *Gate) Release(n int) {
	g.mu.Lock()
	g.slots += n
	g.mu.Unlock()
	g.cond.Broadcast()
}

Wait 做了两个核心动作：把当前 goroutine 放入等待队列，同时原子释放关联的锁；等被唤醒之后，它会重新抢到锁才返回。所以条件检查必须写成 for，不能用一次性的 if。

新架构：条件变量只负责唤醒，状态全程由锁保护

把模块边界拆开之后，逻辑会清晰很多：slots 是客观事实，mu 保护事实的读写一致性，cond 只负责让等待者不需要做无效的轮询。Broadcast 会唤醒所有等待队列里的协程，但它们仍旧要排队抢锁；只有抢到锁并且确认 slots > 0 的 goroutine 才能继续往下走。

如果一次只释放一个名额，调用 Signal 可以减少不必要的无效唤醒；如果一次配置变更之后，多个等待者都有机会继续运行，用 Broadcast 会更稳妥。选哪个方法取决于实际的状态变化，而不是“哪个函数看起来性能更好”。

channel 的优势：消息、背压和关闭语义都更原生

批量任务队列是另一种典型场景。生产者提交的是一条条独立任务，消费者需要按顺序或者按容量把任务取走处理，这时候 channel 自带的发送、接收和缓冲语义就非常适配。

jobs := make(chan Job, 64)

go func() {
	defer close(jobs)
	for _, job := range pending {
		jobs 

这里关闭 channel 代表“不会再有新消息”的事实，接收方用 range 的语法就能自然退出。sync.Cond 没有对应的内置关闭操作；如果等待条件依赖服务生命周期，就要把 closed 纳入同一把锁保护的状态里，每次等待循环都同步检查它。

上线时怎么选：看共享状态和事件数量

• 选择 sync.Cond：等待者关心共享状态的变化，比如剩余名额、配置版本、缓存是否预热完成；一次状态变更可能放行多个等待者。
• 选择 channel：生产者生成独立消息，消费者逐条处理；需要缓冲、排队、关闭或者直接把数据转发给另一个 goroutine。
• 选择两者组合：用 channel 负责接收任务，用锁和条件变量限制共享资源的可用名额，但要提前明确每份状态的归属方。

别在 Cond.Wait 里执行耗时操作，也不要在持锁状态下调用外部服务。实际业务处理逻辑要放在解锁之后执行，否则一个慢任务会卡主所有其他等待者，看起来就像完全没被唤醒过。

验证与边界：让等待队列真的能正常收尾

最小测试用例至少要覆盖三条路径：初始 slots=0 时调用方确实会进入等待；Release 后等待者能正常恢复执行；多个等待者竞争有限名额时，不会出现计数为负的异常。测试结束前还要确认没有 goroutine 被卡在等待队列里泄露。

func TestGateRelease(t *testing.T) {
	g := NewGate(0)
	done := make(chan struct{})
	go func() {
		g.Acquire()
		close(done)
	}()

	select {
	case 

再执行 go test -race ./...，重点确认所有状态读写都经过同一把锁保护。如果业务需要支持超时等待，建议把等待条件改成带截止时间的外层协调逻辑，或者直接用支持取消的 channel/队列实现；不要把一个不可取消的 Cond.Wait 封装成支持取消的操作。

常见问题

sync.Cond.Broadcast 会不会保证所有 goroutine 都拿到资源？

不会。它只负责唤醒所有等待者，资源竞争和条件判断的逻辑仍旧由锁和 for 循环保障。

为什么 Cond.Wait 不能放在 if 语句里？

因为协程被唤醒之后，对应条件可能已经被别的 goroutine 抢占消耗了，它只是收到通知要重新检查状态。用 for 才能在重新拿到锁之后再次确认当前状态是否符合预期。

sync.Cond 能像 channel 一样直接关闭吗？

它没有内置的关闭语义。需要退出等待的时候，把 closed 或者错误状态纳入同一把锁保护的条件范围，让等待循环每次都检查这个标记即可。

只有一个等待者时应该用 Signal 还是 Broadcast？

单个明确等待者的场景可以用 Signal，但如果后续等待者数量可能发生变化，先梳理清楚状态不变量和补充完对应测试，再决定要不要做这个优化。

小结：先把等待条件描述清楚，再选合适的同步工具

把模糊的“等通知”改写成一句可以直接验证的陈述句，通常就能选对同步工具：如果句子是“等某个共享状态的值变为真”，用锁保护状态再配合 sync.Cond；如果句子是“等下一条任务到来”，直接用 channel。两种工具可以搭配协作，但不要让一个 channel 同时承担状态传递、队列缓存、关闭通知和错误传播四种不同职责。