Go sync.Cond怎样唤醒等待队列中的全部协程怎样完成一个可复用的最小示例

如果多个 goroutine 都在等同一个“闸门打开”条件，Go 的 sync.Cond 应该这样用：先用互斥锁保护条件变量，等待方在锁内循环检查条件并调用 Wait()，状态改变后由持锁方把条件设为成立，再调用 Broadcast()，最后解锁。Broadcast 会通知当前等待队列中的全部协程，但它不替你修改共享状态，也不保证每个协程醒来后条件仍然成立。

官方资料：https://pkg.go.dev/sync

先把等待条件和锁边界设计清楚

sync.Cond 适合“大家等待一个状态变化”的场景，例如配置加载完成、队列从空变为可读、批次闸门开放。它本身没有“完成”状态，通常要和一个布尔值、计数器或队列长度组合使用。

等待者先拿锁，再检查条件；条件不满足才进入等待。Wait() 会在内部释放锁并阻塞，收到通知后重新拿回锁再返回，所以调用者不能在没有锁的情况下直接调用它。通知方也要在同一把锁保护下更新条件，避免“先通知、后改状态”造成竞态。

用 sync.Cond 封装可复用的 Gate

下面的 Gate 只表达一个方向：从关闭变为开放。多个协程可以重复调用 Wait()，调用一次 OpenAll() 后，等待队列中的协程都能继续。

package main

import (
	"fmt"
	"sync"
)

// Gate 把共享条件和对应的通知器封装在一起，避免调用方遗漏锁边界。
type Gate struct {
	mu   sync.Mutex
	open bool
	cond *sync.Cond
}

// NewGate 必须用同一把 mu 创建 Cond，Wait 与 Broadcast 才能保护同一个条件。
func NewGate() *Gate {
	g := &Gate{}
	g.cond = sync.NewCond(&g.mu)
	return g
}

// Wait 只在 open 成立时返回；循环是为了处理醒来后条件被其他协程改变的情况。
func (g *Gate) Wait() {
	g.mu.Lock()
	defer g.mu.Unlock() // 无论正常返回还是后续扩展，都保证释放锁。
	for !g.open {
		g.cond.Wait()
	}
}

// OpenAll 先发布共享状态，再广播；这样被唤醒的协程重新拿锁后能看到新状态。
func (g *Gate) OpenAll() {
	g.mu.Lock()
	g.open = true
	g.cond.Broadcast()
	g.mu.Unlock()
}

func main() {
	gate := NewGate()
	var wg sync.WaitGroup
	for i := 1; i 

这个例子里，Broadcast 只是让等待者从阻塞处重新竞争 mu。真正让它们通过的是 g.open = true。因此，不能把 Broadcast 当作“自动修改状态”的操作。

理解 Broadcast、Signal 与循环检查的差别

三者的职责可以按下面的表来记：

如果条件是“队列里新增了一个任务”，每次只增加一个任务时使用 Signal 更贴合语义；如果条件是“初始化完成，所有消费者都可以开始”，就使用 Broadcast。无论哪一种，等待方都不应把一次通知等同于条件永久成立。

补上生命周期和适用边界

生产代码至少检查四件事：第一，Wait 和状态读取使用同一把锁；第二，状态更新发生在通知之前；第三，开放操作是否允许重复调用，必要时做成幂等；第四，是否存在永远不会满足的条件。若等待需要超时或取消，通常可以把 channel、context 或定时器纳入更高层的协调逻辑，因为 sync.Cond 没有自带超时参数。

当需求只是“一个事件发生后广播给所有订阅者”，关闭一个 channel 往往更直观；当需要反复等待、反复修改条件，并且希望显式控制锁与共享状态时，sync.Cond 更合适。选择的关键不是谁更快，而是状态是否需要被重复检查和重新开放。

常见问题

Broadcast 调用后为什么还有协程没有立刻打印？

它们被唤醒后还要重新竞争互斥锁，拿到锁后才能从 Wait 返回；调度顺序不等于唤醒顺序。

可以把 Wait 放进 if 里吗？

不建议。条件可能在等待者醒来前被其他协程消费或修改，使用 for 才能保证返回前重新确认共享状态。

什么时候用 Signal 而不是 Broadcast？

当一次状态变化只允许一个等待者消费资源时用 Signal；当同一状态变化对所有等待者都有效时用 Broadcast。