Go sync.Cond 广播后为什么还要循环判断：等待队列、伪唤醒与并发协议

线上有界队列偶尔会出现一种很难靠日志复现的现象：消费者明明被唤醒了，下一行却发现队列还是空的；如果把判断写成一次性的 if，程序甚至会取到不存在的元素。问题不在于 Broadcast “失效”，而在于唤醒只是重新竞争锁的机会，真正的条件仍要由持锁代码重新确认。

先把“唤醒”和“条件成立”分开

sync.Cond 绑定一个 Locker，通常就是保护共享状态的 *sync.Mutex。消费者发现队列为空时，在持锁状态下调用 Wait：它会暂时释放锁并进入等待；被通知后重新竞争这把锁，成功拿到锁才从 Wait 返回。

这里有个容易被忽略的时间窗口：消费者甲被唤醒后还没拿到锁，消费者乙可能先拿到锁并取走唯一一条数据。甲随后拿到锁时，“曾经有数据”是真的，“现在仍有数据”却是假的。所以返回只说明可以重新检查，不能直接推出条件成立。

用一个有界队列复现错误判断

下面的队列容量只有 1，两个消费者同时等待。生产者放入一条消息后广播，两个消费者都有机会醒来，但最终只能有一个消费者取到消息。

type Queue struct {
    mu    sync.Mutex
    notEmpty *sync.Cond
    items []string
}

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

func (q *Queue) TakeWrong() string {
    q.mu.Lock()
    defer q.mu.Unlock()
    if len(q.items) == 0 {
        q.notEmpty.Wait()
    }
    item := q.items[0]
    q.items = q.items[1:]
    return item
}

这段代码的问题不是“偶尔取不到”，而是协议本身没有覆盖“醒来后条件已被别人消费”的情况。只要两个消费者同时被广播唤醒，就可能有一个消费者在空切片上取下标。

分层检查：Wait 返回后到底发生了什么

第一层：调用 Wait 时是否持有同一把锁

Wait 必须在已经锁住关联 Locker 的情况下调用。它负责原子地释放锁并加入等待队列，返回前再把锁拿回来。若把状态检查放在锁外，检查结果和后续等待之间就可能被插入一次通知，形成丢通知窗口。

第二层：条件是否是共享状态的事实

“收到广播”不是队列状态；len(q.items) > 0 才是。条件应当由同一把锁保护，并在每次返回后重新读取。把 `notified bool` 当作条件缓存，通常会把通知事件误当成状态事实。

第三层：多个等待者是否会争抢同一资源

如果一个资源只够一个等待者，广播后的竞争是必然的；即使实现没有额外的“伪唤醒”，也不能用一次判断代替循环。Go 文档要求调用者在循环中检查等待条件，原因正是通知和条件成立并不是同一件事。

修复动作：让循环重新确认队列条件

把一次性的 if 改成 for，并让生产者在状态修改后、仍持锁时发出通知：

func (q *Queue) Take() string {
    q.mu.Lock()
    defer q.mu.Unlock()
    for len(q.items) == 0 {
        q.notEmpty.Wait()
    }
    item := q.items[0]
    q.items = q.items[1:]
    return item
}

func (q *Queue) Put(item string) {
    q.mu.Lock()
    q.items = append(q.items, item)
    q.notEmpty.Signal()
    q.mu.Unlock()
}

先改状态、再通知，是为了让被唤醒的协程重新拿到锁时能看到新状态。这里使用 Signal 就够了，因为一次 Put 只增加一个可消费元素；若一次操作补入多个元素，或者状态变化可能让多个等待者同时继续，再考虑 Broadcast。

反向验证：用竞争测试观察协议是否收敛

测试不要只覆盖“一个生产者、一个消费者”的顺滑路径。至少启动两个消费者，重复投递单条消息，再用 go test -race 检查数据竞争；测试结果应满足每条消息只被取走一次，消费者不会在空队列上继续执行取元素动作。

func TestQueueTwoConsumers(t *testing.T) {
    q := NewQueue()
    got := make(chan string, 2)
    for i := 0; i 

实际项目中不要用固定睡眠来证明并发顺序；示例里的短暂等待只是让读者看清场景。更稳妥的测试应使用启动栅栏、完成通道和测试超时，确保两个消费者确实进入等待状态，并在清理阶段关闭所有 goroutine。

三个容易混淆的边界

Signal 不是“把资源交给某个协程”

它只是通知一个等待者重新竞争锁。具体由谁拿到锁、谁再次检查成功，取决于调度和当时的共享状态，不能把通知顺序当作业务顺序。

Broadcast 不等于所有等待者都能继续

广播会让多个等待者获得重新检查的机会，但它们仍要逐个拿锁。只有条件满足的协程能离开循环，其余协程会再次调用 Wait。

通知前后是否持锁要服从同一套协议

常见做法是状态变更和通知都放在锁保护范围内，通知后再解锁。更重要的是所有读写条件的路径都遵循同一把锁；只讨论通知调用的位置，而忽略状态写入的保护范围，排查不会闭环。

把并发协议写成上线前清单

• 每个 Wait 是否都位于持有同一把锁的代码路径中？
• 等待条件是否是锁保护的共享状态，而不是一次性通知标记？
• Wait 返回后是否用 for 重新检查条件？
• 状态修改是否发生在通知之前，并且通知与状态变化使用同一把锁？
• 测试是否覆盖多个等待者、资源不足、重复唤醒和 -race 检查？

记住一句就够了：sync.Cond 传递的是“可以再来看看”的信号，真正允许业务动作继续的，始终是重新检查后仍然成立的共享条件。

相关问题

队列场景能不能直接改用 channel？

如果需求只是传递数据，channel 往往更直接；当条件由多字段状态、复杂谓词或多个操作共同决定时，sync.Cond 更容易把状态和锁放在一起管理。选择时看状态协议，而不是只看 API 长短。

为什么不用每次循环都 Broadcast？

广播会让所有等待者竞争一次锁，资源只增加一个时会造成无谓唤醒。能明确只影响一个等待者时用 Signal，无法判断受影响范围时再用 Broadcast。