Go sync.Cond 为什么 Wait 必须放在循环里

Go 的 sync.Cond.Wait 放在循环里，不是因为它会随机“虚假唤醒”，而是因为它返回时只说明等待者被 Signal 或 Broadcast 唤醒，不能保证共享条件仍然成立。等待期间 c.L 会被释放，其他 goroutine 可能先取走资源、改变队列或再次让条件变为假，所以正确写法始终是“持锁检查条件，不满足就 Wait，返回后重新检查”。

一、Wait 返回不代表条件成立

把 sync.Cond 想成“有人可能改变状态时的等待入口”更准确。假设多个消费者等待队列非空：消费者 A 收到通知后还没重新拿到锁，消费者 B 先拿到锁并取走唯一一条数据，A 随后拿到锁时，队列已经再次为空。如果 A 用 if 判断，接下来就会在没有数据时继续读取。

这也是循环必要的核心：Wait 返回后，代码处在一个新的共享状态快照上。通知只负责让 goroutine 有机会继续观察，真正决定能否继续的是条件表达式。

二、用循环包住条件检查和 Wait

下面的最小队列只保留与问题相关的边界：items 和条件由同一把互斥锁保护，Pop 在锁内循环等待，Push 修改队列后发出通知。

package main

import "sync"

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

func NewQueue() *Queue {
	q := &Queue{}
	// Cond 绑定同一把锁，读写 items 时使用这条锁边界。
	q.cond = sync.NewCond(&q.mu)
	return q
}

func (q *Queue) Pop() string {
	q.mu.Lock()
	defer q.mu.Unlock()
	// Wait 返回后必须重查，通知不等于队列一定有数据。
	for len(q.items) == 0 {
		q.cond.Wait()
	}
	item := q.items[0]
	q.items = q.items[1:]
	return item
}

func (q *Queue) Push(item string) {
	q.mu.Lock()
	q.items = append(q.items, item)
	// 条件已改变，唤醒一个可能可以继续消费的等待者。
	q.cond.Signal()
	q.mu.Unlock()
}

这里的顺序很重要：调用 Wait 前必须持有 c.L；Wait 会释放它，让生产者能够进入；返回前又会重新加锁，因此循环里的条件读取仍受同一把锁保护。若把 if len(q.items) == 0 改成一次性判断，就丢失了“通知后重新确认”的安全边界。

三、让 Signal 和 Broadcast 只负责通知

Signal 只唤醒一个等待 goroutine，适合一次新增一个可消费资源的场景；Broadcast 唤醒全部等待者，适合状态一次性变化、多个等待者都需要重新评估的场景。无论选哪一个，等待方都要回到循环判断自己的条件。

通知前后是否持有锁有更细的性能取舍，但共享条件的修改必须与等待方使用同一套锁边界。生产者可以先修改 items，再 Signal，最后解锁；这样被唤醒的消费者拿到锁后，能看到已经发布的状态。通知本身不会替消费者排队，也不会替它完成资源检查。

四、按清单检查 Cond 的常见错误

• 调用 Wait 时没有持有 c.L，导致锁边界不完整。
• 把 Wait 写在 if 中，返回后没有重新确认队列、计数或状态。
• 复制已经使用过的 sync.Cond；官方文档明确要求 Cond 首次使用后不能复制。
• 多个简单通知场景直接上 Cond，却忽略 channel 可能更直观；官方文档也把 channel 列为许多简单场景的更高层选择。

相关问题

Wait 会发生传统意义上的虚假唤醒吗？

Go 文档说明它不会无故返回，必须由 Signal 或 Broadcast 唤醒；但条件仍可能在等待期间被其他 goroutine 改变，所以循环仍然必需。

Signal 后能不能立刻解锁？

可以。关键是先在同一锁保护下改变共享条件；解锁后等待者会重新竞争这把锁，并在循环中确认条件。

什么时候使用 Broadcast？

当一次状态变化可能让多个等待者都有机会继续，或所有等待者都需要重新评估条件时使用。每个等待者仍需独立判断。

Cond 能完全替代 channel 吗？

不能简单画等号。对于明确的消息传递，channel 往往更直接；Cond 更适合围绕受锁保护的共享状态等待条件变化。