条件变量

来源：17golang原创 2026-11-11 16:35:41 0浏览收藏

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

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

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

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

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

sync.Cond 中 Wait、Locker、条件谓词与 Signal Broadcast 的静态关系说明图 — 图1：条件变量结构说明图，展示唤醒通知与业务条件之间的边界；这是静态说明图，不是运行截图。

因此“唤醒”是事件，“条件成立”是共享状态的事实，两者不能互相替代。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 有三层作用：等待前先检查，避免条件已经满足却进入睡眠；返回后重新检查，覆盖竞争者先消费资源的情况；条件仍不满足时继续等待，而不是把空状态交给后续代码。

Go 队列生产者、消费者、notEmpty 条件和共享锁的静态结构图 — 图2：队列等待结构图，展示生产者更新 items、消费者重查条件和共享 Locker 的关系；这是原创结构说明图。

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

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

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