Go sync.Cond 的 Signal 和 Broadcast 怎么选：等待条件、锁保护与丢唤醒排查

排查一个有界队列时，最容易被忽略的不是队列容量，而是“谁在等、谁该被叫醒”。Go 的 sync.Cond 只负责等待和通知，不会替你判断条件；Signal 唤醒一个等待者，Broadcast 唤醒全部等待者。真正稳妥的写法，是让等待条件始终在锁保护下检查，并用循环重新确认条件。

先把 sync.Cond 的边界说清楚

sync.Cond 不是消息队列，也不是事件缓存。它保存的是“有人正在等待”的同步关系，真正的数据状态仍然由业务变量维护。下面的例子用两个变量表达一个有界队列：

这里有一个容易混淆的点：通知本身不携带“队列非空”这样的信息。消费者被唤醒后，必须重新读取 items 和 closed，再决定是取数据、继续等待还是退出。

一个可复用的等待流程

先固定三件事：条件变量绑定哪把锁，等待者检查什么条件，状态变化由谁触发。生产者和消费者可以共用一个 Cond，也可以按不同条件拆成多个条件变量；前者代码更短，后者能减少无关唤醒。

type Queue struct {
    mu     sync.Mutex
    ready  *sync.Cond
    items  []string
    closed bool
}

func NewQueue() *Queue {
    q := &Queue{}
    q.ready = sync.NewCond(&q.mu)
    return q
}

func (q *Queue) Pop() (string, bool) {
    q.mu.Lock()
    defer q.mu.Unlock()

    for len(q.items) == 0 && !q.closed {
        q.ready.Wait()
    }
    if len(q.items) == 0 && q.closed {
        return "", false
    }
    item := q.items[0]
    q.items = q.items[1:]
    q.ready.Signal()
    return item, true
}

func (q *Queue) Push(item string) bool {
    q.mu.Lock()
    defer q.mu.Unlock()
    if q.closed {
        return false
    }
    q.items = append(q.items, item)
    q.ready.Signal()
    return true
}

注意 Wait 的调用点：先拿锁，再用 for 判断条件。Wait 会暂时释放锁并阻塞，返回时重新拿回这把锁，所以后面的切片读写仍然在同一个临界区内。

为什么不能用 if

一次唤醒只代表“可以重新检查了”，不代表轮到当前 goroutine 消费，也不代表条件一定成立。多个消费者同时等待时，另一个消费者可能先拿到锁并取走唯一元素；如果使用 if，当前调用方会直接访问空队列。

Signal 和 Broadcast 的选择看状态变化范围

Signal 适合“一个状态变化最多让一个等待者继续”的场景。队列从空变为有一个元素，通常只需要让一个消费者竞争锁；消费者取走一个元素后，也只需要让一个生产者继续。

Broadcast 适合关闭、批量状态变化或条件规则发生整体改变的场景。例如队列关闭后，所有阻塞在 Wait 的消费者都需要醒来检查 closed，否则它们可能永久等待。

func (q *Queue) Close() {
    q.mu.Lock()
    defer q.mu.Unlock()
    if q.closed {
        return
    }
    q.closed = true
    q.ready.Broadcast()
}

落地时按这条顺序排查

1. 找到条件变量绑定的锁，确认所有条件读写都在这把锁内。
2. 把每个 Wait 前的判断改成能表达完整状态的 for 条件。
3. 逐个列出状态变化：加入元素、取走元素、关闭、批量重置。
4. 判断变化最多释放一个等待者，还是要求所有等待者重新检查；前者用 Signal，后者用 Broadcast。
5. 为关闭、空队列、并发消费者和重复关闭分别写测试，并设置超时，避免测试本身永久挂住。

这里别急着把所有通知都换成 Broadcast。它通常更容易“跑通”，但会让大量 goroutine 同时醒来争锁；最终只有少数调用方能取得工作，其余调用方又回到等待，形成不必要的竞争。

三个常见误区

在锁外修改条件再通知

如果状态修改和通知不在同一个锁保护范围内，等待者可能看到不一致状态，代码也很难证明不存在竞态。先拿锁、改状态、通知、解锁，是更容易审查的顺序。

把 Cond 当成不会丢失的事件

如果通知发生时没有等待者，之后到来的等待者不会自动“消费”这次通知。因此必须把可观察状态保存在 items、closed 等变量里，而不是只依赖通知次数。

用 Broadcast 掩盖条件设计问题

所有人都被叫醒不等于所有人都能继续。先写清条件，再决定通知范围；如果每次都只能靠 Broadcast 才不挂，通常应回头检查锁和循环条件。

相关问题

Signal 会唤醒指定的 goroutine 吗？

不会。它只唤醒一个等待者，具体是哪一个由运行时调度决定，调用方不能依赖固定顺序。

Wait 返回后还需要重新 Lock 吗？

不需要。按照 sync.Cond 的约定，Wait 返回时调用方已经重新持有绑定的 Locker。

什么时候可以只用 Signal？

当一次状态变化最多让一个等待者继续，并且其他等待者在后续状态变化中仍会获得通知时，Signal 通常更合适。

关闭队列为什么常用 Broadcast？

关闭是所有等待者都必须感知的状态变化。Broadcast 让每个等待者都能醒来检查关闭标记并退出。

最后用一张表做代码评审