Go 条件变量怎样避免丢失唤醒

我在排查一个偶发卡住的 Go worker 时，最先怀疑的是 goroutine 泄漏，后来才发现问题更小：等待方把一次通知当成了“条件已经成立”。sync.Cond 本身不会替你保存通知，真正需要等待的是一条受锁保护的共享谓词。要避免丢失唤醒，核心写法只有一句话：用同一把锁保护谓词检查和状态修改，等待方用 for 反复检查，通知方再按影响范围选择 Signal 或 Broadcast。

本文只讨论条件变量的三个关键点：谓词循环、Signal 和 Broadcast。不把它扩展成通用并发教程，也不把一张静态说明图当作程序运行证据。

丢失唤醒的根因不是 Signal 太快

条件变量解决的是“暂时没有满足条件的 goroutine 如何睡眠，以及状态改变后如何被叫醒”。它并不表示某个通知会像消息一样排队保存。通知发生时没有等待者，后续新来的等待者不会因为那次通知自动被唤醒。

因此，等待方不能只记住“我收到过通知”，而要在锁保护下观察一个明确的谓词，例如队列是否非空、缓冲区是否有空间、任务是否已经关闭。通知只负责让等待方重新检查这个谓词。

把通知理解成“请重新看一眼状态”，把谓词理解成“现在是否真的可以继续”。只要等待方始终检查后者，通知早到或多到都不会改变正确性。

等待方要把检查和 Wait 放进同一把锁

Cond 关联一个 Locker。调用 Wait 时，Go 会原子地释放这把锁并让当前 goroutine 暂停；被唤醒后，它会重新拿到这把锁再返回。这个原子衔接正是避免检查窗口被插入状态修改的关键。

下面的例子用一个简单的任务队列表示“有任务可取”这个谓词。代码中的注释只解释锁、谓词和资源释放的职责，重点不是模拟完整生产系统。

package main

import "sync"

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

func NewQueue() *Queue {
	q := &Queue{}
	// ready 与 mu 绑定，谓词 items/closed 只能在 mu 保护下观察或修改。
	q.ready = sync.NewCond(&q.mu)
	return q
}

func (q *Queue) Pop() (string, bool) {
	q.mu.Lock()
	defer q.mu.Unlock()

	// 必须循环检查真实谓词，不能把一次唤醒当成任务一定存在。
	for len(q.items) == 0 && !q.closed {
		q.ready.Wait()
	}

	// 关闭且没有剩余任务时，等待方才结束。
	if len(q.items) == 0 && q.closed {
		return "", false
	}
	item := q.items[0]
	q.items = q.items[1:]
	return item, true
}

这里的 for 有三层作用：被叫醒后重新确认队列状态；多个消费者同时竞争时允许只有一个拿到任务；关闭状态出现时仍能走到明确的退出分支。即使某次通知没有对应的可用任务，等待方也只会再次进入 Wait，不会读取空切片。

通知方先改变谓词，再发出通知

通知方的顺序也很重要。它应该在同一把锁下先改变共享状态，再调用通知方法。这样被唤醒的 goroutine 重新拿锁后，看到的是与通知对应的新谓词，而不是一个尚未写入的中间状态。

func (q *Queue) Push(item string) bool {
	q.mu.Lock()
	defer q.mu.Unlock()

	// 关闭后不再接收新任务，避免把关闭状态重新改回可用状态。
	if q.closed {
		return false
	}
	q.items = append(q.items, item)
	// 一个新任务只需要让一个等待者重新竞争队列。
	q.ready.Signal()
	return true
}

func (q *Queue) Close() {
	q.mu.Lock()
	defer q.mu.Unlock()

	// 先写入终止谓词，再唤醒所有可能需要退出的等待者。
	q.closed = true
	q.ready.Broadcast()
}

Push 把队列从“没有任务”改成“至少有一个任务”，所以通常只需 Signal。Close 则可能同时影响多个等待者：它们都需要重新检查 closed，因此使用 Broadcast 更符合状态变化的范围。

Signal 和 Broadcast 的区别在于等待者影响面

Signal 最多唤醒一个等待者。如果多个消费者等待同一类资源，而一次状态变化只新增一个可消费对象，唤醒一个就够了。被唤醒者拿到锁后仍须重新检查谓词，不能假设自己一定能消费成功。

Broadcast 会唤醒当前等待的所有 goroutine。它适合“状态变化可能让所有人都有资格继续判断”的情况，例如队列关闭、配置整体切换，或某个共享门闩一次性打开。它也可能带来更多锁竞争，所以不能把所有通知都写成广播。

选择时可以问自己两个问题：

• 这次状态变化只会让一个等待者获得资源，还是会让一批等待者都需要重新判断？
• 被唤醒的 goroutine 是否都能在同一把锁下看到新的谓词？

四个容易让条件变量失效的写法

1. 用 if 包住 Wait。 被唤醒不等于条件成立；多个消费者竞争时，前一个消费者可能已经取走资源。
2. 检查谓词时没有持有 Cond 关联的锁。 检查和 Wait 之间会出现空档，通知可能恰好落在这个空档里。
3. 先 Signal，再修改共享状态。 被唤醒者拿锁后可能看见旧状态，随后再次睡眠，而真正的修改没有对应的后续通知。
4. 把 Signal 当成消息队列。 没有等待者时，Signal 不会替未来的等待者保存一条待消费消息。

另外，通知调用是否必须持锁，不能脱离整体状态设计来回答。Go 文档允许调用者在持锁或不持锁时调用 Signal 和 Broadcast，但共享谓词的修改必须与等待方遵守同一套同步约束。为了让顺序容易审查，工程代码通常把“修改谓词”和“发通知”放在同一临界区里。

提交前用一张清单复查

什么时候应该改用 channel

sync.Cond 适合多个 goroutine 围绕一个共享状态等待，尤其是状态和资源模型已经存在、等待者需要在同一把锁下反复判断的场景。若需求只是“发送任务”或“广播关闭”，channel 往往更直接：发送对应单次交接，关闭对应不可逆的广播。

最终判断标准不是 API 看起来是否高级，而是能否清楚回答：等待的谓词是什么、谁修改它、哪把锁保护它、一次变化影响几个等待者。四个问题都能在代码中找到答案时，丢失唤醒通常就不再是靠运气隐藏的并发 bug。

相关问题

Wait 返回后还需要再次加锁吗？

不需要手动再加同一把锁；Wait 返回前会重新锁住关联的 Locker。调用方仍要保持临界区语义，并在退出前解锁。

一个任务到来时能不能直接 Broadcast？

可以调用，但通常会让多个消费者同时醒来争抢一份资源，造成额外锁竞争。单个任务到来时优先考虑 Signal，除非业务状态明确要求所有等待者都重新判断。

为什么不把谓词改成一个 bool 就结束？

谓词可以是 bool，也可以是队列长度、关闭状态、容量和多个字段的组合。关键是它描述“现在能否继续”，并且所有相关字段都受到一致的同步保护。