Go sync.Cond 为什么等不到广播：谓词循环、Signal 时机与唤醒边界

任务队列明明已经放进了一条数据，等待中的 goroutine 却没有继续处理。日志里能看到生产者调用过 Broadcast，消费者也确实进入过 Wait，问题最后落在一个很小的顺序上：共享状态没有和唤醒动作放在同一把锁保护的时间线上。

sync.Cond 不保存“通知次数”，它只负责让等待者重新获得运行机会。真正决定能不能继续的是受锁保护的条件，所以 Wait 必须放进谓词循环，生产者要先改状态再唤醒。

为什么调用了 Broadcast，消费者仍然不工作

先看一个缩小后的队列。生产者把任务写入 jobs，消费者在队列为空时等待：

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

func NewQueue() *Queue {
	q := &Queue{}
	q.cond = sync.NewCond(&q.mu)
	return q
}

最容易写成的是“等一次就继续”。这段代码在第一次运行时可能没问题，但它把一次唤醒误当成了条件成立：

q.mu.Lock()
if len(q.jobs) == 0 {
	q.cond.Wait()
}
job := q.jobs[0]
q.mu.Unlock()

等待者被唤醒后还要重新拿锁。等它拿到锁时，另一个消费者可能已经取走任务，或者队列正在关闭。Wait 返回只说明“可以再次检查”，不说明 len(q.jobs) > 0。

正确写法：状态变化和唤醒保持同一条时间线

消费者要用 for 保护谓词。生产者则在同一把锁内追加任务，再通知等待者：

func (q *Queue) Push(job string) {
	q.mu.Lock()
	q.jobs = append(q.jobs, job)
	q.cond.Signal()
	q.mu.Unlock()
}

func (q *Queue) Pop() string {
	q.mu.Lock()
	defer q.mu.Unlock()
	for len(q.jobs) == 0 {
		q.cond.Wait()
	}
	job := q.jobs[0]
	q.jobs = q.jobs[1:]
	return job
}

这里有两个容易被忽略的检查点。第一，Wait 前已经持有 q.mu，它会在等待期间释放锁，返回前重新加锁。第二，Push 先改变 jobs，再发信号；消费者醒来后拿到锁，就能看到这次状态变化。

如果一个任务到来时有多个消费者在等，Signal 只唤醒一个更合适。若一次批量写入了很多任务，可以在追加完成后调用 Broadcast，让所有等待者重新竞争；没有拿到任务的 goroutine 会回到 for 里继续等。

三个看起来合理、实际上会出问题的写法

先通知，再修改队列

如果先 Signal 后 append，消费者醒来后仍然看见空队列，只能重新等待。通知没有被“缓存”，后面的 append 也不会自动再次通知，最终就会出现任务已经存在但没人处理的假象。

把 if 改成 for，却把状态读取放在锁外

for 只能保护受锁约束的读取。如果先解锁再读取 jobs，生产者和消费者仍可能同时改动切片，既有数据竞争，也可能读到不一致的状态。条件判断、取出任务和关闭判断应该在同一把锁下完成。

用 Broadcast 解决所有并发问题

Broadcast 不是队列，也不是消息缓存。没有等待者时调用它不会留下待消费的通知；有很多等待者时，它还会制造一轮锁竞争。应先定义状态条件，再决定唤醒一个还是全部。

关闭队列时，为什么更适合用 done 条件一起唤醒

真实队列不仅有“有任务”一种状态，还要处理关闭。一个等待者如果只检查 len(q.jobs) == 0，关闭后可能永远睡着。可以把关闭标记纳入同一条谓词：

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

func (q *Queue) Close() {
	q.mu.Lock()
	q.closed = true
	q.cond.Broadcast()
	q.mu.Unlock()
}

func (q *Queue) Pop() (string, bool) {
	q.mu.Lock()
	defer q.mu.Unlock()
	for len(q.jobs) == 0 && !q.closed {
		q.cond.Wait()
	}
	if len(q.jobs) == 0 {
		return "", false
	}
	job := q.jobs[0]
	q.jobs = q.jobs[1:]
	return job, true
}

关闭时使用 Broadcast 是因为每个等待者都需要观察到 closed=true，并从等待循环中退出。已经排队的任务仍然可以先被取完；是否允许关闭后继续接收新任务，则应在 Push 内明确返回错误，而不是依赖通知顺序猜测。

用一个小测试复查等待和关闭边界

并发同步代码不要只看“测试没有卡住”。至少验证三件事：任务能被取出，空队列会等待，关闭能唤醒等待者。运行测试时可以加上竞态检测：

go test -race ./...

如果测试偶发卡住，先给测试设置超时并打印等待者的状态，不要直接把 Broadcast 到处补一遍。大多数问题不是“通知太少”，而是谓词没有完整描述退出条件，或者修改状态时绕开了保护它的锁。

相关问题

Signal 和 Broadcast 应该怎么选？

一个状态变化只会让一个等待者继续时用 Signal；关闭、配置整体刷新或批量状态变化需要所有等待者重新判断时用 Broadcast。

Wait 能不能放在锁外？

不能。调用 Wait 时必须持有与条件关联的 Locker，否则无法建立“检查条件—释放锁—等待”的原子衔接。

为什么唤醒后还要再判断一次？

多个 goroutine 可能同时醒来，真正拿到锁时条件已经变化；而且通知本身不携带任务内容，只有共享状态才是事实来源。

把 sync.Cond 用稳的判断标准

把 sync.Cond 想成“状态变化后的重新排队入口”会更准确：条件由锁保护，等待放进 for，生产者先写状态后通知，关闭则让所有等待者有机会退出。若状态流转已经能自然表达成 channel，优先用 channel；只有在共享内存条件更直接、且需要精确控制等待者时，再保留 sync.Cond。