Go sync.Cond 如何等待队列状态变化

消费者需要“等到队列里有数据再取”，但又不想用循环加 sleep 轮询，这正是 sync.Cond 的用武之地。正确写法不是调用一次 Wait 后就取元素，而是把条件检查放在 for 里：消费者持锁确认队列为空时等待，生产者在锁内放入数据后通知，消费者醒来后重新确认状态。

为什么醒来后还要重新检查队列

sync.Cond 不是数据容器，它只负责在某个状态可能改变时唤醒 goroutine。Go 官方文档明确建议：持有 Cond.L 时检查条件，条件不满足就调用 Wait，返回后继续检查。原因很实际：多个消费者可能同时等待，生产者只放入一个元素；即使都被广播唤醒，真正抢到锁的消费者也可能先把元素取走。

用一个并发队列串起 Wait 和 Signal

下面的队列只演示同步边界。生产者写入后通知一个等待者，消费者在锁内取出元素，最后再释放锁。代码中的注释说明了锁、状态和唤醒之间的职责。

package main

import (
	"fmt"
	"sync"
)

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

func NewQueue() *Queue {
	q := &Queue{}
	// Cond 必须使用同一把锁保护 items 和 closed。
	q.cond = sync.NewCond(&q.mu)
	return q
}

func (q *Queue) Push(item string) {
	q.mu.Lock()
	defer q.mu.Unlock()
	if q.closed {
		return
	}
	// 先改变共享状态，再通知等待者。
	q.items = append(q.items, item)
	q.cond.Signal()
}

func (q *Queue) Pop() (string, bool) {
	q.mu.Lock()
	defer q.mu.Unlock()
	// Wait 返回只表示可能有变化，不能代替条件判断。
	for len(q.items) == 0 && !q.closed {
		q.cond.Wait()
	}
	if len(q.items) == 0 {
		return "", false
	}
	item := q.items[0]
	q.items = q.items[1:]
	return item, true
}

func (q *Queue) Close() {
	q.mu.Lock()
	defer q.mu.Unlock()
	// 关闭会改变所有消费者的等待条件，因此唤醒全部等待者。
	q.closed = true
	q.cond.Broadcast()
}

func main() {
	q := NewQueue()
	q.Push("task-1")
	item, ok := q.Pop()
	fmt.Println(item, ok)
	q.Close()
}

这里的 Close 同时修改了 closed 和等待条件：已经没有数据的消费者不应再睡下去，所以要用 Broadcast 让它们都重新判断。示例的输出只是代码逻辑的说明，不代表本文在本机执行过。

Signal、Broadcast 和锁应该怎么配合

Signal 只唤醒一个等待者，适合“一次新增一个可消费元素”的场景。若一次入队一批元素，也可以按设计选择多次 Signal，或在批量更新后使用 Broadcast。后者会让所有等待者竞争同一把锁，醒来后仍需通过 for 过滤不满足条件的 goroutine。

通知函数允许在持锁或不持锁时调用，但状态的读取和修改仍应由同一把锁保护。实践中把“修改状态、通知、释放锁”放在一个临界区更容易推理；不要为了缩短临界区，把共享状态的修改移到锁外。

常见问题

Wait 会发生真正的虚假唤醒吗？

Go 文档说明，Wait 不会无缘无故返回，只会由 Signal 或 Broadcast 唤醒。但从业务角度看，返回后条件可能已被别的 goroutine 消耗，因此代码仍必须用 for，不能用一次性的 if。

什么时候直接用 channel 更合适？

如果需求只是传递任务、关闭通知或限制并发，channel 通常更直观。sync.Cond 更适合条件由多个字段共同决定、并且需要精确控制共享状态的低层同步组件。

为什么 Cond 不能在使用后复制？

Cond 内部维护等待者状态，复制会让锁和等待队列的归属变得不一致。把它放进长期存活的队列对象中，并通过指针使用即可。

把等待条件写成一句可验证的话

实现 sync.Cond 时，可以先写清楚这句话：“持锁时，队列非空即可取；队列为空且未关闭才等待；关闭后必须唤醒所有等待者。”只要 Push、Pop 和 Close 都围绕这三个状态转换编写，空取、漏唤醒和关闭后永久等待就有了明确的检查边界。