Go sync.Cond Signal 丢失如何设计等待条件

先记住一个关键点：sync.Cond.Signal() 不是带缓存的事件。没有 goroutine 正在等待时，Signal 不会留下一个“下次必定收到”的令牌；真正应该持久保存的是 ready、队列长度、任务数量或关闭状态等共享条件。等待者每次拿到锁，都要重新判断这个条件。

官方地址：https://pkg.go.dev/sync#Cond

把一次性通知改造成可重复读取的状态，再用同一把锁保护“检查条件—进入等待—更新条件”的协议，才能避免所谓的 Signal 丢失。

Signal 为什么不会替你保存等待结果

Cond 只关联一个 Locker，它本身不保存业务状态。Signal 最多唤醒一个已经等待的 goroutine；如果当时没有等待者，调用就不会变成未来的通知。也就是说，生产者先发送 Signal，消费者之后才开始等待，而且消费者没有任何持久条件可检查，这个顺序并不安全。

安全的思路是把“任务已经准备好”写入共享状态。消费者后来拿到锁时，即使错过了 Signal，也能读到 ready == true，从而不再进入 Wait。通知只是让等待者尽快重新检查，条件才是决定能否继续的依据。

用同一把 Locker 建立不会丢通知的协议

等待者和更新者必须围绕同一把锁读写条件。等待者先持锁检查，条件不满足时调用 Wait；Wait 会释放锁并挂起，返回前重新取得这把锁。生产者则在持锁状态下更新条件，然后发送 Signal。

// ready 是持久条件，mu 同时保护 ready 和 cond 的等待协议
var mu sync.Mutex
cond := sync.NewCond(&mu)
ready := false

// 等待者：Signal 早到也没关系，拿锁后会看到 ready
mu.Lock()
for !ready {
    cond.Wait()
}
useResource()
mu.Unlock()

// 更新者：先改变共享状态，再通知等待者重新检查
mu.Lock()
ready = true
cond.Signal()
mu.Unlock()

这个例子中，ready 的写入与读取都在 mu 保护下。更新者先执行时，后来的等待者会直接跳过循环；等待者先执行时，更新者改变状态并 Signal，等待者醒来后再次拿锁并读到新状态。两条路径都不会依赖通知本身被“记住”。

为什么等待条件必须写成 for

即使已经收到了 Signal，也不能把返回当成条件成立。多个消费者可能竞争同一项任务：第一个消费者拿锁取走任务后，第二个消费者才重新拿锁；第二个消费者确实被唤醒，却已经没有任务可取。因此，正确写法是循环检查当前共享状态。

// 队列长度是条件，通知只提示消费者重新观察队列
mu.Lock()
for len(queue) == 0 && !closed {
    cond.Wait()
}
if len(queue) == 0 && closed {
    mu.Unlock()
    return
}
item := queue[0]
queue = queue[1:]
mu.Unlock()

// 生产者在同一把锁下追加任务，并唤醒一个可能的消费者
mu.Lock()
queue = append(queue, item)
cond.Signal()
mu.Unlock()

for 同时覆盖两类情况：通知先于等待发生，以及多个 goroutine 在唤醒后竞争同一份状态。closed 这样的退出条件也应该放进同一个判断，否则队列关闭后仍可能有 goroutine 永久等待。

Signal、Broadcast 和 channel 怎么取舍

只有一个等待者可以消费一次状态变化时，Signal 通常足够；状态变化可能让多个等待者都具备资格时，使用 Broadcast，但每个等待者仍要用 for 复查条件。比如关闭队列时，所有等待者都需要看到 closed == true，此时只唤醒一个 goroutine 容易留下其他等待者。

如果需求本质是传递数据、关闭广播或表达一次性完成事件，channel 通常更直观；如果多个字段共同组成条件，并且这些字段需要与队列或资源状态由同一把锁保护，sync.Cond 更适合。无论选哪一种，都不要把“通知发生过”当作唯一状态。

• 条件是否持久：等待者稍后拿到锁时，能否从共享状态判断是否应该继续。
• 锁是否一致：条件的读、写、Wait 和相关资源操作是否遵循同一把 Locker。
• 退出是否可达：错误、关闭和取消是否也进入等待条件，并在状态变化时唤醒。

几个常见问题

Signal 先执行，后来的 Wait 会不会永远卡住？

如果只有一次性 Signal、没有持久条件，确实可能卡住；如果更新者在同一把锁下把 ready 或队列状态写好，后来的等待者会先读条件并跳过 Wait。

更新条件后必须持锁调用 Signal 吗？

Go 文档允许在不持有锁时调用 Signal，但把状态更新和通知放在同一套锁协议中更容易审查，也能避免读写条件时出现竞态。关键不是“通知是否缓存”，而是条件读写必须有一致的同步关系。

为什么不用 if 判断一次？

因为其他 goroutine 可能在你重新取得锁之前消费或改变状态。for 把每次返回都当成重新检查的机会，只有条件真实成立时才继续。

总结：Signal 只负责提醒等待者竞争锁，不负责保存业务结果。把 ready、队列长度和关闭状态等条件放在共享数据里，用同一把 Locker 保护读写，并始终用 for 复查，才能让“通知先到”和“多个等待者竞争”都变成可控的状态判断。