条件变量

结论：sync.Cond.Wait 返回，只代表当前 goroutine 被 Signal 或 Broadcast 唤醒，并不代表等待的业务条件仍然成立。正确写法是持有同一个 Locker，用 for 反复检查条件，只有条件成立后才继续读取或修改共享状态。

这条规则解决的是一个很具体的问题：多个 goroutine 共同等待队列、连接或资源时，为什么 if condition { c.Wait() } 可能在返回后继续执行错误分支。下面按“触发信号—快速判断—处理步骤—回滚复盘”的方式，把这段等待协议拆开。

Wait 返回，不等于条件已经满足

Cond 是一个等待或宣布事件发生的集合点。它绑定一个锁，改变条件和调用 Wait 时都要持有这个锁。Wait 会原子地解锁、挂起当前 goroutine；被唤醒后，它会先重新拿回锁，再返回。

关键在于，锁重新拿到的时刻和条件被通知的时刻之间，其他 goroutine 可能已经改变了共享状态。比如生产者放入一个元素后广播，两个消费者同时被唤醒；第一个消费者拿到锁并取走元素，第二个消费者随后拿到锁时，队列已经为空。如果第二个消费者只依赖一次 Wait 返回，就会读到不存在的元素。

因此“唤醒”是事件，“条件成立”是共享状态的事实，两者不能互相替代。Go 官方文档也明确说明，调用者通常不能假定 Wait 返回时条件为真。

把条件判断放进 for，才是最小正确写法

以一个只允许非空读取的队列为例，消费者先持锁，再循环检查队列长度。循环体只负责等待，循环之后才执行取值：

package main

import "sync"

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

func NewQueue() *Queue {
	q := &Queue{}
	// Cond 与队列共用同一把锁，保证条件读写和 Wait 的解锁动作一致。
	q.notEmpty = sync.NewCond(&q.mu)
	return q
}

func (q *Queue) Push(item string) {
	q.mu.Lock()
	defer q.mu.Unlock()
	// 先改变共享条件，再通知等待者关注新的队列状态。
	q.items = append(q.items, item)
	q.notEmpty.Signal()
}

func (q *Queue) Pop() string {
	q.mu.Lock()
	defer q.mu.Unlock()
	for len(q.items) == 0 {
		// 被唤醒后仍要重新检查，避免其他消费者先取走元素。
		q.notEmpty.Wait()
	}
	item := q.items[0]
	q.items = q.items[1:]
	return item
}

这里的 for 有三层作用：等待前先检查，避免条件已经满足却进入睡眠；返回后重新检查，覆盖竞争者先消费资源的情况；条件仍不满足时继续等待，而不是把空状态交给后续代码。

排障时先查锁、条件和通知的对应关系

遇到“偶尔读到空值”“偶尔卡住”或“唤醒后仍不能工作”，可以按下面的顺序判断：

1. 条件是否由同一把锁保护。读取 len(items)、修改 items 和调用 Wait 应使用同一个 Locker。如果条件在锁外读取，看到的状态就不属于这个等待协议。
2. 通知是否发生在状态变化之后。生产者应先写入队列，再调用 Signal；通知本身不是数据，也不能代替对共享状态的写入。
3. 等待方是否在返回后重查。把 if 改成 for 是第一处修复。即使当前 Go 的 Wait 不会无故返回，也必须遵循条件变量的通用契约，因为通知只说明“值得重新观察”。
4. 选择 Signal 还是 Broadcast。Signal 只唤醒一个等待者，适合一次状态变化只需要一个消费者继续；Broadcast 唤醒全部等待者，适合条件变化可能同时让多个等待者有机会继续，但每个等待者仍要独立重查。

Signal 和 Broadcast 是否必须在持锁期间调用，要服从整个共享状态协议；官方实现允许调用者不持有锁，但改变条件的操作仍必须受关联锁保护。工程上保持“改状态与通知”靠近，并明确同一把锁，通常更容易复盘。

回滚与复盘：看到 if Wait 就先停下来

代码评审中，只要出现“持锁后判断一次、Wait 一次、返回就取值”的结构，就先按风险处理：恢复为 for !condition { c.Wait() }，确认条件函数只读取受锁保护的状态，再检查通知方是否在状态变化后发送信号。

如果问题表现为持续阻塞，优先确认是否有任何路径真正改变了条件并发出通知；如果表现为空读或越界，优先确认是否漏掉了循环重查。修复后保留“条件、锁、通知方、消费者”四项复盘记录，后续增加新等待条件时也沿用同一协议。

常见问题

为什么不能用 if 包住 Cond.Wait？

因为 Wait 返回只意味着被通知并重新拿到锁，其他 goroutine 可能已经改变条件；用 if 会跳过返回后的重新判断。

Signal 是否一定要在锁里调用？

Go 文档允许 Signal 的调用者不持有关联锁，但条件的读取和修改必须由同一 Locker 保护。为了让状态变化与通知顺序清楚，通常把它们放在同一段受锁代码中。

Broadcast 后还需要 for 吗？

需要。Broadcast 只会唤醒所有等待者，不会替每个等待者保证业务条件成立；每个 goroutine 都必须重新读取共享状态。