Go sync.Cond 等待为什么会错过通知

使用 Go 的 sync.Cond 时，最容易误判的一幕是：一个 goroutine 调用了 Signal，另一个 goroutine 后面进入 Wait，结果后者一直等不到。真正要保存的不是通知，而是“条件已经满足”的共享状态。只要条件检查、进入等待和修改状态由同一把锁保护，通知先到达也不会让正确的等待者永久丢失。

下面按一个最小工作流拆开这个问题：先看通知窗口，再写出正确的等待协议，最后用锁、条件和唤醒范围逐项排查。

先区分“通知丢了”和“状态没有保存”

Signal 只负责唤醒当时正在等待的一个 goroutine；它不是带容量的消息队列。如果调用通知时没有等待者，这次通知不会替未来的等待者排队。因此，下面这种思路本身就不可靠：

// 错误示意：通知本身没有保存“已经打开”的状态。
cond.Signal()
// 另一个 goroutine 稍后才调用 cond.Wait，可能继续等待。

可靠协议是把“是否已经打开”放在共享变量里。等待者先锁住状态，条件已经满足就直接继续；只有条件不满足时才调用 Wait。这样，即使通知发生在等待者到达之前，等待者也能从状态变量读到结果，而不依赖一条已经过去的 Signal。

把条件检查和 Wait 放进同一把锁

官方文档要求：改变条件以及调用 Wait 时都要持有关联的 Locker。一个可复用的门闩示例可以这样组织：

package gate

import "sync"

type Gate struct {
    mu    sync.Mutex
    cond  *sync.Cond
    ready bool
}

func New() *Gate {
    g := &Gate{}
    // Cond 复用同一把锁，保证条件读写与等待协议一致。
    g.cond = sync.NewCond(&g.mu)
    return g
}

func (g *Gate) Wait() {
    g.mu.Lock()
    defer g.mu.Unlock()
    // 条件已经满足时不进入 Wait，避免依赖过去的通知。
    for !g.ready {
        g.cond.Wait()
    }
}

func (g *Gate) Open() {
    g.mu.Lock()
    // 先写入共享状态，再通知等待者。
    g.ready = true
    g.cond.Broadcast()
    g.mu.Unlock()
}

这里的关键不是 Broadcast 本身，而是 ready 的生命周期：Wait 读它，Open 写它，二者都经过 mu。因此通知早到时，后来的等待者会直接跳过等待。

为什么必须用 for，以及何时用 Signal

Wait 返回后，调用方重新拿到锁，但条件可能已经被其他 goroutine 改变。另一个等待者可能先消费了资源，或者生产者只发布了一份结果，所以不能把返回当成“条件必然成立”。for 会让等待者重新读取真实状态：

// 条件变量只负责唤醒，是否能继续由共享状态决定。
g.mu.Lock()
for g.remaining == 0 {
    // Wait 返回前会重新获得 g.mu，返回后仍需再次判断。
    g.cond.Wait()
}
g.remaining-- // 在锁内消费资源，避免多个等待者重复消费。
g.mu.Unlock()

如果一次状态变化只允许一个等待者继续，使用 Signal；如果状态变化可能让所有等待者都重新满足条件，使用 Broadcast。Signal 也不保证被唤醒的 goroutine 立即运行，其他竞争同一把锁的 goroutine 可能先拿到锁，所以不要把调度顺序写进业务假设。

用四个位置快速定位问题

1. 锁是否一致：检查条件变量关联的 Locker，确认条件读写没有绕开这把锁。
2. 是否先检查条件：等待代码应是“加锁—循环检查—Wait”，不要无条件调用 Wait。
3. 通知前是否先写状态：先修改 ready、计数或队列状态，再调用 Signal/Broadcast。
4. 唤醒范围是否匹配：一个资源配一个消费者通常用 Signal；全局状态变化再考虑 Broadcast。

如果代码只是等待一次性的事件，先问自己是否真的需要条件变量。Go 官方文档也提醒，许多简单场景使用 channel 会更直接；但当共享条件由锁保护、等待者需要反复检查时，sync.Cond 仍然适合。

小结：不要让 Signal 承担状态存储

“等待错过通知”的根因通常不是 Go 随机丢唤醒，而是把 Signal 当成了会排队的事件。正确做法可以压缩成一句话：用同一把锁保护条件，在 for 循环里等待，先更新状态再选择 Signal 或 Broadcast。这样排查时，优先看状态和锁的边界，而不是先猜 goroutine 调度。

相关问题

Signal 和 Broadcast 的区别是什么？Signal 唤醒一个等待者，Broadcast 唤醒全部等待者；最终能否继续仍由共享条件决定。

Wait 能不能写在 if 里？不建议。Wait 返回后条件可能已被其他 goroutine 改变，应使用 for 重新检查。