Go sync.Cond 为什么容易写错：Wait 前加锁、Signal 丢失与退出协议

第一次用 sync.Cond 写任务队列时，最容易把它当成“发一条通知，另一个 goroutine 收一次”。实际上，Cond 不保存通知，也不替你保存业务条件。它只负责让等待者睡眠、在状态变化后把等待者叫醒；真正决定能不能继续的是共享状态本身。

Wait 必须在持有同一把锁时调用，并且要放在检查条件的 for 循环里。生产者先修改队列状态，再调用 Signal；退出时要把关闭状态也作为条件的一部分。

sync.Cond 的 Wait 到底等待什么

下面是一个只保存任务切片和关闭标志的队列。sync.Cond 绑定的是 mu，生产者和消费者都必须围绕这把锁读写状态：

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

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

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

Wait 返回时，当前 goroutine 已经重新持有 mu。所以条件判断必须写在循环里，而不是写成一次 if。唤醒只代表“共享状态可能变了”，不代表“轮到你消费了”。

为什么 Signal 会丢：通知不是队列里的消息

错误写法通常是生产者先通知，再写入任务：

q.mu.Lock()
q.cond.Signal()
q.jobs = append(q.jobs, job)
q.mu.Unlock()

如果消费者此时刚好检查到空队列并准备等待，生产者的通知没有被 Cond 保存，消费者仍可能睡眠。正确顺序是先把状态改到满足条件，再通知：

q.mu.Lock()
q.jobs = append(q.jobs, job)
q.cond.Signal()
q.mu.Unlock()

这里的通知只是在缩短等待时间，安全性仍来自锁保护下的 len(q.jobs) 检查。即使多个消费者同时醒来，没有任务的消费者也会重新回到 for。

常见误区：三个看似能跑的写法

Wait 前没有持有锁

这是协议错误，不是性能问题。Wait 需要在内部释放并重新获取关联锁；没有先持锁，代码可能直接触发运行时错误，也无法保证条件检查和入睡之间没有空档。

用 if 替代 for

一次唤醒可能是其他消费者抢走了任务，也可能只是关闭状态发生变化。用 if 会让空切片、越界或错误返回混进正常路径。

只用 Signal 处理关闭

关闭时可能有多个消费者同时等待。只唤醒一个 goroutine，其他人会一直睡着。关闭操作应设置 closed = true，然后调用 Broadcast，让每个等待者都重新判断退出条件。

把关闭和退出写进同一个条件

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

func (q *Queue) Push(job Job) bool {
    q.mu.Lock()
    defer q.mu.Unlock()
    if q.closed {
        return false
    }
    q.jobs = append(q.jobs, job)
    q.cond.Signal()
    return true
}

消费者醒来后，如果队列为空且已经关闭，就返回 false；如果关闭时仍有任务，则先把任务取完，再在下一轮退出。这个顺序比“关闭立即丢弃全部任务”更适合需要优雅停机的 worker。

相关问题

Signal 应该在解锁前还是解锁后调用？

常见写法是在持锁修改完状态后立即调用 Signal，再解锁。这样状态变化和通知处于同一段临界区，读者也更容易核对协议。

Broadcast 会不会让所有 goroutine 同时抢锁？

会产生一轮竞争，但它只在关闭或全量状态变化时使用。只需唤醒一个消费者时用 Signal，不要把所有普通入队都改成广播。

sync.Cond 能替代 channel 吗？

不能简单替代。channel 自带消息或关闭语义，Cond 更适合“复杂共享条件已经存在，只需要等待条件变化”的场景。任务队列若用 channel 能清晰表达，就优先使用 channel。

最后检查一遍 Cond 协议

排查 Cond 卡死时，可以按四件事检查：Wait 是否持有同一把锁，条件是否用 for 重判，状态是否先于通知更新，关闭时是否唤醒了全部等待者。少了任何一项，代码都可能在低并发测试里正常，却在停机或多个消费者同时运行时卡住。