Go sync.Cond.Signal 为什么不能替代 Broadcast：等待谓词、锁顺序与丢唤醒

线上导入任务偶尔卡住时，最容易被怀疑的是 goroutine 没有收到通知。用 sync.Cond 时，真正要先问的是：共享状态有没有在锁内改变，等待者醒来后有没有重新检查谓词，以及这次状态变化到底只需要叫醒一个消费者还是全部消费者。Signal 和 Broadcast 不是可以随手互换的两个按钮。

如果一次状态变化最多只让一个等待者继续工作，用 Signal；如果所有等待者都可能因同一状态变化获得进展，才用 Broadcast。无论哪种通知，Wait 返回后都必须回到循环重新检查条件。

先看卡住现场：通知发生了，任务却没有继续

假设有一个容量为 2 的任务队列，消费者在队列为空时等待，生产者把任务放入队列后通知消费者。下面这段结构的重点不是队列本身，而是三件事的先后关系：修改 queue、调用 Signal、释放 mu。

type Queue struct {
    mu    sync.Mutex
    cond  *sync.Cond
    queue []Task
}

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

func (q *Queue) Push(task Task) {
    q.mu.Lock()
    q.queue = append(q.queue, task)
    q.cond.Signal()
    q.mu.Unlock()
}

func (q *Queue) Pop() Task {
    q.mu.Lock()
    for len(q.queue) == 0 {
        q.cond.Wait()
    }
    task := q.queue[0]
    q.queue = q.queue[1:]
    q.mu.Unlock()
    return task
}

这里的可见状态是 len(q.queue) == 0。Wait 让出锁并暂停当前 goroutine；它返回时重新持有锁，所以 Pop 可以安全地再次检查队列。把 Signal 放到解锁之后，表面上仍像是“通知了”，但会让状态变更、通知和抢锁之间出现难以验证的窗口。

为什么 Signal 只代表一次机会

Signal 的语义是唤醒一个等待者；它不承诺由程序指定某个 goroutine，也不替你判断哪个等待者最合适。对于一个入队动作，如果只新增了一个任务，唤醒一个消费者正好匹配状态变化的规模。

消费者醒来后仍然要经过 for len(q.queue) == 0。可能在它重新拿到锁之前，另一个消费者已经取走了唯一的任务，也可能队列被其他逻辑清空。通知没有把任务“保留”给被唤醒者，队列状态才是事实。

锁顺序是排查的第一条证据

生产者的顺序应当是“持锁、修改共享状态、通知、解锁”。消费者的顺序应当是“持锁、检查谓词、不满足就 Wait、满足后取值、解锁”。如果日志只打印了“Signal 已调用”，却没有同时打印队列长度，定位会缺一半证据。

什么时候必须 Broadcast：同一个变化影响所有等待者

把队列扩展成“关闭”状态后，消费者的等待条件不再只是队列为空，而是“队列为空且未关闭”。关闭动作会改变所有等待者的未来判断：它们都应该醒来，决定退出还是处理剩余任务。这时只调用一次 Signal，其余 goroutine 可能永久等待。

func (q *Queue) Close() {
    q.mu.Lock()
    q.closed = true
    q.cond.Broadcast()
    q.mu.Unlock()
}

func (q *Queue) Pop() (Task, bool) {
    q.mu.Lock()
    defer q.mu.Unlock()
    for len(q.queue) == 0 && !q.closed {
        q.cond.Wait()
    }
    if len(q.queue) == 0 && q.closed {
        return Task{}, false
    }
    task := q.queue[0]
    q.queue = q.queue[1:]
    return task, true
}

图中 Close 改变的是全体等待者共享的 closed 状态，所以通知范围也应扩大。注意这不等于“Broadcast 更安全”：如果每次只新增一个任务却广播十个消费者，所有 goroutine 都会争抢同一把锁，再逐个发现队列仍为空。

三种常见写错方式，怎样反向验证

把 if 写成等待判断

if len(q.queue) == 0 { q.cond.Wait() } 只检查一次。醒来时条件可能已被别的消费者改变，取值就会越界或读到错误状态。修复后用多个消费者、单个任务和高频入队组合测试，日志至少记录等待前后的队列长度。

未持锁就修改并通知

共享字段、通知和谓词检查没有共同的锁保护时，测试可能偶尔通过，压力上来才暴露丢唤醒。把 go test -race 作为第一轮检查；它不能证明通知逻辑正确，但能先排除明显的数据竞争。

用 Broadcast 掩盖状态设计问题

广播只能扩大唤醒范围，不能修复没有关闭状态、没有退出路径或谓词含义含混的问题。给队列补上明确的 closed 字段，并让 Pop 返回 bool，通常比无条件广播更容易验收。

一份可以留在代码评审里的检查清单

• 调用 Wait、Signal、Broadcast 时是否持有同一把锁。
• 等待条件是否写在 for 中，且循环体只负责等待。
• 通知前是否已经修改了共享状态。
• 一次变化只影响一个消费者，还是影响所有等待者。
• 关闭、取消和错误路径是否能唤醒并退出全部等待者。

相关问题

Wait 返回后还需要再次加锁吗？

不需要。按 sync.Cond 的约定，Wait 返回时已经重新持有与条件变量关联的锁，但仍要继续执行循环谓词检查。

Signal 会保证最早等待的 goroutine 先醒吗？

不会把调度顺序当成业务契约。代码应依赖共享状态和谓词，不应依赖某个等待者获得通知。

只有一个消费者时能不能一直 Broadcast？

功能上可能没有多唤醒成本，但这会掩盖通知范围设计。按状态变化选择通知方式，后续扩展消费者时更容易保持性能和语义。

把判断留给状态，而不是留给运气

sync.Cond 难排查的地方，不在 API 数量，而在它把“等待”和“状态变化”分开了。把共享状态放在锁内维护，用 for 包住 Wait，再根据一次变化影响的人数选择 Signal 或 Broadcast，这套规则足以覆盖大多数任务队列和关闭通知场景。