Go sync.Cond 怎样等待队列从空变为可消费

当消费者需要从共享队列取任务，而队列暂时为空时，正确做法不是循环加锁轮询。可以让消费者持有保护队列的锁，在条件不满足时调用 sync.Cond.Wait；生产者完成入队后发出通知。关键点是：Wait 返回只代表 goroutine 被唤醒，不代表队列一定非空，所以必须继续在条件循环中检查。

把“队列是否可消费”写成受锁保护的条件谓词：消费者在 for len(queue) == 0 中等待，生产者在锁内入队后调用 Signal。这样既避免忙等，也不会把一次唤醒错误地当成条件成立。

先确认触发信号：消费者看到的是空队列

这个场景通常有三个角色：消费者读取共享队列，生产者追加任务，互斥锁保护队列切片及其长度。sync.Cond 不是队列本身，而是“条件可能发生变化”的等待点；它必须绑定到同一个 Locker 上。

如果消费者只是不断调用 Lock、检查长度、Unlock，再立刻重试，就会把 CPU 时间花在没有结果的轮询上。判断条件应该与实际共享状态一致，例如 len(queue) > 0，而不是另设一个可能失真的布尔标记。

消费者要在条件循环里调用 Wait

Wait 的调用者必须先持有关联锁。它会原子地释放锁并挂起当前 goroutine；被 Signal 或 Broadcast 唤醒后，返回前会重新获得这把锁。因此，消费者可以在等待期间让生产者进入临界区。

package main

import "sync"

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

func NewQueue() *Queue {
	q := &Queue{}
	// Cond 使用同一把锁保护队列状态和 Wait 调用。
	q.ready = sync.NewCond(&q.mu)
	return q
}

func (q *Queue) Get() string {
	q.mu.Lock()
	defer q.mu.Unlock()

	// 条件不满足时等待；醒来后必须重新检查队列长度。
	for len(q.items) == 0 {
		q.ready.Wait()
	}

	item := q.items[0]
	q.items = q.items[1:]
	return item
}

这里的 for 有两个作用：第一，多个消费者竞争同一批任务时，先醒来的消费者可能已经取走任务；第二，通知只表示共享状态可能变化，不能替代对谓词的判断。即使代码路径看起来只会由生产者通知，也不要把循环简化成一次 if。

生产者先修改队列，再通知等待者

生产者应在同一把锁内完成“追加任务”和“发出通知”。这样消费者重新拿到锁后，看到的是与通知对应的队列状态。

func (q *Queue) Put(item string) {
	q.mu.Lock()
	defer q.mu.Unlock()

	// 先让条件从“空”变成“可消费”，再唤醒一个消费者。
	q.items = append(q.items, item)
	q.ready.Signal()
}

Signal 只唤醒一个等待中的 goroutine，适合一次入队只需要一个消费者继续工作的情况。若一次状态变化可能让多个独立条件都成立，或生产者一次性放入多项任务，可以使用 Broadcast，但所有被唤醒者仍需重新竞争锁并检查自己的条件。

快速判断：通知发生了，为什么消费者还不能取数

排查时先看条件谓词，而不是只看是否调用过 Signal。常见情况如下：

回滚与退出：不要让 Cond 变成永久阻塞点

队列需要停止服务时，不能只设置一个关闭字段然后等待消费者自己发现。关闭字段同样要受锁保护，并在状态改变后通知等待者。消费者醒来后先判断关闭和队列是否都已经没有工作，再决定返回。

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

func (q *Queue) Close() {
	q.mu.Lock()
	defer q.mu.Unlock()

	// 关闭状态也要唤醒等待者，避免退出时永久睡眠。
	q.closed = true
	q.ready.Broadcast()
}

func (q *Queue) GetOrStop() (string, bool) {
	q.mu.Lock()
	defer q.mu.Unlock()

	// 队列为空且未关闭时等待；关闭后仍允许先消费遗留任务。
	for len(q.items) == 0 && !q.closed {
		q.ready.Wait()
	}
	if len(q.items) == 0 {
		return "", false
	}
	item := q.items[0]
	q.items = q.items[1:]
	return item, true
}

这里的“回滚”不是撤销一次通知，而是让状态机回到可解释的状态：关闭时广播、等待者重新判断、没有遗留任务时返回。若业务还需要超时或取消，应把它们放在队列生命周期控制层，不能在未持锁时直接读取共享字段。

告警确认与复盘项

上线后可以围绕三个信号复查：空队列等待时长是否异常增长、消费者是否频繁被唤醒却拿不到任务、关闭流程是否能让所有等待者返回。若第二项持续升高，优先检查通知粒度和条件循环；若第一项和生产端延迟同时升高，再看生产者是否真的入队，而不是盲目增加 Broadcast。

复盘时至少保留这些信息：条件谓词是什么、修改谓词时由哪把锁保护、何时调用 Signal 或 Broadcast、关闭状态如何唤醒等待者。这样可以把“偶尔卡住”还原成可检查的状态转移。

常见追问

sync.Cond.Wait 能不能不放在 for 里？

不建议。唤醒后条件可能已经被其他 goroutine 消耗，必须重新获取锁并检查条件。

Signal 要不要持有锁调用？

Go 文档允许调用者在调用 Signal 时不持有 L，但把状态修改和通知放在同一临界区通常更容易维护，也能清楚表达通知对应的状态变化。

什么时候用 Broadcast？

当一次状态变化可能让多个等待者继续，或者关闭队列需要让所有等待者退出时使用。被唤醒的 goroutine 仍然要回到自己的条件循环中。

总结起来，空队列等待的核心不是“调用一次通知”，而是维护一个受锁保护的条件：消费者用 for 等待，生产者先入队再通知，关闭流程广播并让等待者有明确出口。