Go sync.Cond Broadcast 丢失唤醒时如何安排状态检查

Go 里的 sync.Cond.Broadcast 看起来像“丢失唤醒”，通常不是 Broadcast 没有执行，而是把“有人被唤醒”误当成了“条件已经成立”。多个 goroutine 同时等待时，某个 goroutine 先拿到锁并改变共享状态，其他 goroutine 即使都被唤醒，也必须重新检查条件；不满足就继续 Wait。可靠写法是：用同一把锁保护条件，先加锁，再用 for 循环检查，生产者在锁内更新状态后再通知。

先把 Broadcast 和共享条件分开理解

Cond 关联一个 Locker。等待者持锁观察条件，条件不满足时调用 Wait；这个调用会原子地释放锁并挂起，返回前再把锁拿回来。Broadcast 只表示“等待集合可以重新竞争锁并检查了”，不承诺 ready == true、队列一定非空或资源仍归当前 goroutine。

例如两个消费者都等待 queueLen > 0。生产者放入一个任务并广播，两个消费者都可能被唤醒，但只有一个能先拿到锁取走任务。另一个随后拿锁时，队列又为空。如果它把一次返回直接当成成功，就会读到错误状态；这正是最常见的“Broadcast 丢失唤醒”错觉。

等待者必须用 for 循环回到条件检查

把条件检查、Wait 和消费动作放到同一个临界区。下面的例子模拟有界任务队列：生产者更新队列后广播，消费者被唤醒后再次判断队列长度。

package main

import (
    "fmt"
    "sync"
)

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

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

func (q *Queue) Get() string {
    q.mu.Lock()
    defer q.mu.Unlock() // 确保读取或等待结束后释放共享锁
    for len(q.items) == 0 {
        q.cond.Wait() // 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.cond.Broadcast()               // 多个消费者都要重新检查队列
    q.mu.Unlock()
}

func main() {
    q := NewQueue()
    q.Put("job-1")
    fmt.Println(q.Get())
}

这里的 for 同时解决两个边界：多个等待者竞争同一个任务，以及通知到达后条件又被别的 goroutine 改变。若只等待一个消费者，可以评估 Signal；只要不确定有几个等待者需要重新观察状态，Broadcast 配合循环更直观。

生产者按“改状态、再通知”安排同步边界

生产者应使用与等待者相同的 Locker 保护条件的读写。常见顺序是加锁、写入队列或设置 ready、调用 Signal/Broadcast、解锁。这样等待者重新获得锁后看到的是一致的共享状态。官方文档允许在调用 Broadcast 时不持有锁，但把状态更新和通知放在同一临界区更容易审查，也避免通知与条件写入之间出现难以解释的窗口。

日志不要只记录“Broadcast called”。建议同时记录通知前后的队列长度、等待者重新检查时的条件结果和实际消费对象，例如 notify queue_len=1、recheck queue_len=0。这样能区分“没有广播”“另一个消费者先消费”和“条件根本没有变为真”。

排查丢失唤醒的三个检查点

1. 看等待代码是否是 for !condition { cond.Wait() }，而不是 if。后者只检查一次，最容易把竞争误判成丢通知。
2. 看条件的所有读写是否使用同一个 Locker。如果生产者在锁外写共享字段，通知和状态就没有清晰的同步边界。
3. 看是否把 Broadcast 当成事件队列。它不会替你保存任务；需要保存事件时，应把任务放进受保护的队列，或考虑关闭 channel、发送 channel 等更贴合语义的方案。

相关问答

Broadcast 后 Wait 还会阻塞，是不是 Go 的 bug？
通常不是。它可能被唤醒后发现条件已被其他 goroutine 消费，按循环逻辑再次等待。只有在条件写入、锁使用或生命周期管理本身错误时，才需要继续追查。

什么时候用 Signal 而不是 Broadcast？
当一次状态变化只需要一个等待者处理，并且条件与任务模型能保证其他等待者不需要同时重试时，可以用 Signal。若多个等待者都可能因状态变化获益，或条件复杂，使用 Broadcast 并保留循环通常更稳妥。