sync.Cond 等待条件变化时的唤醒丢失排查

我排查 sync.Cond 卡住问题时，最先怀疑的是 Signal 是否“丢了”。后来发现，真正容易出错的通常不是通知函数，而是共享条件没有和 Wait 使用同一把锁保护：生产者改了状态，等待者却在锁外读取旧状态，或者通知与状态更新不在同一个临界区。稳定写法是让等待者在锁内用 for 检查条件，生产者在同一把锁下更新条件后再通知。

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

下面的示例只讨论 Go 标准库的条件变量排障，不把静态配图当成运行截图；代码中的每个锁和通知边界都应结合自己的共享状态重新确认。

先把“唤醒丢失”拆成状态和通知两条线

sync.Cond 本身不是一个保存业务数据的队列，它只是等待者和通知者之间的集合点。真正决定程序能否继续的是“共享条件”，例如队列是否非空、资源是否可用、关闭标记是否已经设置。Cond 关联一个 Locker，官方文档要求改变条件和调用 Wait 时持有这把锁。

典型错误是先在锁外判断队列为空，再进入锁内等待。生产者可能恰好在这两个动作之间加入数据并发送通知，等待者随后才调用 Wait，于是它把一次已经发生的状态变化当成了未来事件。修复重点不是让 Signal 更频繁，而是把“检查条件、进入等待、修改条件”放回同一套锁保护下。

正确写法：Wait 必须放在条件循环里

我现在会先写出共享状态，再决定通知方式。下面的队列故意保持简单：消费者只在锁内判断 len(queue) == 0，生产者也在同一把锁内追加数据。Wait 返回后不能直接拿元素，因为其他消费者可能已经先一步改变了条件，所以必须回到 for 头部重新检查。

package main

import "sync"

type Queue struct {
	mu    sync.Mutex
	cond  *sync.Cond
	items []string
}

func NewQueue() *Queue {
	q := &Queue{}
	// Cond 与共享队列绑定同一把锁，保证条件读取和修改使用相同边界。
	q.cond = sync.NewCond(&q.mu)
	return q
}

func (q *Queue) Push(item string) {
	q.mu.Lock()
	// 先改变“队列非空”这个条件，再通知等待者观察新状态。
	q.items = append(q.items, item)
	q.cond.Signal()
	q.mu.Unlock()
}

func (q *Queue) Pop() string {
	q.mu.Lock()
	defer q.mu.Unlock()
	for len(q.items) == 0 {
		// Wait 会暂时释放 mu；返回时会重新持有 mu，条件仍需复查。
		q.cond.Wait()
	}
	item := q.items[0]
	q.items = q.items[1:]
	return item
}

这里的关键顺序不是“必须先 Signal 再解锁”的口诀，而是状态变化和条件判断必须共享同一个互斥边界。官方文档允许调用 Signal 时不持有锁，但如果生产者修改 items 时没有持锁，等待者仍可能读到不一致的状态，排障会变得非常困难。保守写法是在锁内完成修改、通知和解锁。

Signal、Broadcast 与 channel 怎么选

Signal 只唤醒一个等待者，适合一次状态变化只需要一个消费者处理的队列；如果一次更新会让所有观察者都需要重新检查条件，使用 Broadcast 更直观。无论哪一种，唤醒都只是让 goroutine 获得重新检查的机会，不等于它回来时条件一定仍然成立。

如果需求本质上是“发送一个值，另一个 goroutine 接收这个值”，我通常优先选 channel。Go 官方把 Broadcast 类比为关闭 channel，把 Signal 类比为发送到 channel；Cond 更适合共享状态已经存在，只需要等待状态变化的场景，例如多个消费者共同观察一个由锁保护的条件。

卡住时按这张清单排查

1. 确认所有读取和修改共享条件的代码是否都持有 Cond.L，不要只检查通知函数附近的锁。
2. 确认 Wait 是否位于 for 循环中，而不是用一次 if 判断后直接继续。
3. 确认生产者改变状态后是否真的调用了对应的 Signal 或 Broadcast，并检查是否通知了错误的 Cond 实例。
4. 确认 sync.Cond 没有在首次使用后被复制；复制锁或 Cond 会让排查陷入未定义的对象关系。
5. 如果只是值传递，重新评估 channel 是否能把状态和通知合并成更容易观察的通信路径。

我的经验是，遇到“偶尔不醒”时先画出共享条件和锁的边界，再追通知时序。只盯着 Signal 的调用次数，往往会把真正的竞态藏起来。

相关问题

Wait 会出现无缘无故的返回吗？

Go 的 Cond.Wait 不能在没有 Signal 或 Broadcast 的情况下返回，但它返回时条件可能已经被其他 goroutine 改变，所以仍然必须循环检查。

Signal 一定要在锁内调用吗？

官方文档允许不持有锁调用 Signal，但共享条件的修改必须有一致的锁保护。把修改和通知都放在锁内通常更容易维护，也更容易从代码结构上排除竞态。

为什么不直接用一个布尔值表示已通知？

通知不是业务状态，真正应保存的是队列非空、资源可用或关闭标记等条件。等待者每次被唤醒都重新读取业务状态，才能避免把一次通知误当成永久事实。