当前位置：首页 > 文章列表 > Golang > Go问答 > sync.Cond 等待条件变化时的唤醒丢失排查

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

来源：17golang原创 2026-10-11 00:55:09 0浏览收藏

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

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

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

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

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

等待者、生产者、共享条件、互斥锁与 sync.Cond 的静态关系说明图 — 图1：sync.Cond 状态与通知边界说明图，展示等待者、生产者、共享条件和通知对象的关系；这是说明图，不是运行截图。

典型错误是先在锁外判断队列为空，再进入锁内等待。生产者可能恰好在这两个动作之间加入数据并发送通知，等待者随后才调用 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 时没有持锁，等待者仍可能读到不一致的状态，排障会变得非常困难。保守写法是在锁内完成修改、通知和解锁。

for 条件检查、Wait、Signal、Broadcast 与 channel 方案的静态关系说明图 — 图2：等待循环与 channel 选型说明图，展示 Cond 的条件检查边界及 channel 的替代关系；这是说明图，不是运行截图。

Signal、Broadcast 与 channel 怎么选

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

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

场景	优先方案	判断重点
传递明确的数据值	`channel`	值的所有权和缓冲容量更容易表达
多个 goroutine 观察同一共享条件	`sync.Cond`	条件读取、修改和通知是否由同一把锁协调
一次变化需要全部等待者重试	`Broadcast`	所有等待者醒来后仍需各自复查条件
一次资源只交给一个消费者	`Signal`	确认唤醒一个等待者足以处理当前状态