Go sync.Cond 的 Signal 和 Broadcast 怎么按等待者数量选择

在 Go 的生产者消费者代码里，sync.Cond.Signal 和 Broadcast 不是“一个更快、一个更安全”的替代关系。判断标准是共享条件改变后，需要几个等待者重新竞争：只新增一个可消费任务时用 Signal；队列关闭、配置整体变化或所有等待者都必须重新判断时用 Broadcast。两者都必须配合锁和条件循环使用。

一个小型任务队列如何使用 Signal

先做一个只关心通知语义的任务队列。消费者没有任务时等待，生产者每放入一个任务只需要让一个消费者醒来；如果唤醒全部消费者，它们会一起抢锁，最后只有一个拿到任务，其余 goroutine 又回到等待状态。

package main

import (
    "fmt"
    "sync"
)

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

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

func (q *Queue) Add(job string) {
    q.mu.Lock()
    defer q.mu.Unlock() // 保证入队和通知期间共享状态不会被并发改写
    if q.closed {
        return
    }
    q.jobs = append(q.jobs, job)
    q.cond.Signal() // 一次只增加一个任务，唤醒一个消费者即可
}

func (q *Queue) Get() (string, bool) {
    q.mu.Lock()
    defer q.mu.Unlock() // 返回前释放队列锁，避免消费者长期占用
    for len(q.jobs) == 0 && !q.closed {
        q.cond.Wait() // Wait 会暂时释放 mu，返回后重新持有 mu
    }
    if len(q.jobs) == 0 {
        return "", false // 关闭且无任务，通知消费者退出
    }
    job := q.jobs[0]
    q.jobs = q.jobs[1:]
    return job, true
}

func (q *Queue) Close() {
    q.mu.Lock()
    defer q.mu.Unlock()
    q.closed = true
    q.cond.Broadcast() // 所有等待者都要看到 closed 并结束等待
}

func main() {
    q := NewQueue()
    go func() {
        for {
            job, ok := q.Get()
            if !ok {
                return
            }
            fmt.Println(job)
        }
    }()
    q.Add("compile")
    q.Close()
}

这里的关键不是 Signal 绝对只让一个 goroutine 执行，而是它只保证唤醒一个等待者；被唤醒者重新拿到锁后仍要检查队列。Close 则改变了所有消费者都关心的条件，所以使用 Broadcast。

为什么 Wait 必须放在 for 循环里

Wait 返回只代表收到了一次 Signal 或 Broadcast，不代表当前 goroutine 一定能消费资源。多个消费者被 Broadcast 唤醒时，先拿到锁的消费者可能已经取走任务；另一个消费者恢复后仍然看到空队列。因此不能写成一次 if 判断后直接取值。

生产代码还要把“状态修改”和“通知”放在同一把锁保护下。先把任务放入队列再通知，消费者醒来后才可能读到新状态；关闭时先写入 closed，再广播，消费者才能在循环里判断是否退出。官方文档也明确建议在循环中等待，并指出 Broadcast 的调用成本会随等待者数量增长。

按等待者数量选择通知策略

不要用等待者数量去推导公平性。Signal 不改变调度优先级，其他正在竞争锁的 goroutine 可能先获得锁；如果业务需要严格顺序或任务分发，应该改用带明确语义的 channel 或队列设计。

常见问题

Signal 会不会唤醒多个等待者？

API 语义是唤醒一个等待者。被唤醒者重新竞争锁后，仍应通过条件循环确认自己是否能继续。

Broadcast 一定要在持锁时调用吗？

Go 文档允许调用者不持有关联锁，但实际代码通常在修改共享条件的同一临界区内广播，这样状态和通知更容易保持一致。

简单场景能不能不用 Cond？

可以。官方文档建议许多简单用例优先考虑 channel：关闭 channel 类似广播，向 channel 发送值更接近单次通知。