Go sync.Cond 怎样避免 Wait 丢失通知

Go 的 sync.Cond 避免丢通知，关键不是把 Signal 调得更早，而是让“共享条件的检查、状态修改和 Wait”都受同一个 Locker 保护。Signal 或 Broadcast 只负责唤醒等待者，真正决定能否继续的是条件本身。

固定写法是：持锁检查条件，条件不满足就调用 Wait，被唤醒后重新检查；生产者在同一把锁下修改条件，再选择唤醒一个或全部等待者。

参考文档：https://pkg.go.dev/sync#Cond

本文只讨论条件变量的等待与通知边界，不展开 channel 替代方案或完整调度器设计。

先分清通知与条件

sync.Cond 关联一个 Locker，通常是 *sync.Mutex。共享条件可以是“队列里有待处理任务”“服务已经关闭”或“缓冲区出现空间”。等待者不应该把一次通知当成永久事实，因为通知本身没有携带业务状态。

官方文档说明，Wait 会原子地解锁关联的 Locker 并挂起当前 goroutine，恢复后会重新加锁。因此，只要等待者在持锁期间检查条件，生产者就不能插入“修改条件但等待者还没进入 Wait”的空档。

把 Wait 放进条件循环

下面用待处理数量作为条件。pending 和 closed 都由 mu 保护；等待者只在“没有任务且尚未关闭”时休眠：

package main

import (
    "fmt"
    "sync"
)

type WorkQueue struct {
    mu      sync.Mutex
    cond    *sync.Cond
    pending int
    closed  bool
}

func NewWorkQueue() *WorkQueue {
    q := &WorkQueue{}
    // Cond 与 mu 绑定，条件字段也必须由这把锁保护。
    q.cond = sync.NewCond(&q.mu)
    return q
}

func (q *WorkQueue) Take() (bool, int) {
    q.mu.Lock()
    defer q.mu.Unlock()

    // 被唤醒后必须重新判断，不能假设任务一定还在。
    for q.pending == 0 && !q.closed {
        q.cond.Wait()
    }
    if q.pending == 0 {
        // 关闭且没有剩余任务，调用方可以结束消费。
        return false, 0
    }
    q.pending--
    return true, q.pending
}

func (q *WorkQueue) Put() {
    q.mu.Lock()
    // 先修改条件，再通知等待者，二者处于同一保护域。
    q.pending++
    q.cond.Signal()
    q.mu.Unlock()
}

func (q *WorkQueue) Close() {
    q.mu.Lock()
    // 关闭也是条件的一部分，需要唤醒所有可能正在等待的消费者。
    q.closed = true
    q.cond.Broadcast()
    q.mu.Unlock()
}

func main() {
    q := NewWorkQueue()
    q.Put()
    ok, left := q.Take()
    fmt.Println(ok, left)
}

这里的 for 有两层作用：一是被唤醒后重新确认 pending 或 closed，二是多个消费者竞争同一份任务时，某个 goroutine 取走任务后，其他 goroutine 仍需回到条件判断。if 只能检查一次，容易把“收到通知”误写成“条件已经满足”。

在状态变化处发送通知

生产者的顺序应当保持简单：拿到同一把锁，修改条件，再发通知。Signal 只唤醒一个等待者，适合一次只增加一个任务；Broadcast 唤醒全部等待者，适合关闭状态或一次变化可能让多个等待者重新判断的场景。

func (q *WorkQueue) PutMany(n int) {
    q.mu.Lock()
    defer q.mu.Unlock()

    if q.closed {
        // 关闭后不再增加任务，避免条件含义前后不一致。
        return
    }
    q.pending += n
    // 多个任务可能满足多个消费者，所以统一唤醒后让各自重新判断。
    q.cond.Broadcast()
}

通知可以在不持锁时调用，但把状态更新和通知放在同一保护域更容易审查，也能保证等待者看到的是一致的条件。需要注意的是，Signal 不会替你保存一张“通知票据”；如果当时没有等待者，后续进入的 goroutine 仍然必须依靠共享条件判断，而不是等待一条旧通知。

排查丢通知与退出边界

遇到 goroutine 长时间不醒，优先按下面的边界排查：

• 是否先解锁再等待：检查和 Wait 之间如果没有同一把锁保护，生产者可能已经修改条件并发出通知，等待者随后却仍然进入休眠。
• 是否使用了 if：唤醒只代表需要重新检查，不能直接跳过条件判断。
• 是否更新了正确的条件：生产者增加的是 pending，等待者检查的也必须是同一个受保护字段。
• 是否有退出条件：关闭、取消或错误状态应成为条件的一部分，并通过 Broadcast 让所有等待者有机会退出。

// 错误示意：检查与 Wait 之间重新解锁，可能错过状态更新通知。
q.mu.Lock()
if q.pending == 0 {
    q.mu.Unlock()
    // 生产者可能在这里 Put 并 Signal，通知不会替后续 Wait 排队。
    q.mu.Lock()
    q.cond.Wait()
}
q.mu.Unlock()

正确修复不是给 Wait 增加延时，而是恢复“持锁检查 + for 循环等待”的结构。这样即使通知发生在等待者真正挂起之前，等待者也会先看到已经改变的共享条件，不会因为一条没有排队的旧通知而永久等待。

常见追问

Wait 会无缘无故返回吗？ Go 文档说明它不会在没有 Signal 或 Broadcast 的情况下返回，但返回后条件仍应重新判断，因为其他等待者可能已经消耗了资源。

一个任务用 Signal 还是 Broadcast？ 通常一个新增任务配合 Signal 就够；关闭、批量更新或多个等待者都可能满足时，用 Broadcast，让每个 goroutine 自己检查条件。