Go sync.Cond 等待条件变化时怎么避免虚假唤醒逻辑

使用 sync.Cond 等待队列、缓存或资源状态变化时，Wait() 返回并不代表条件已经成立。可靠写法是：先持有同一个 Locker，用 for 检查共享条件，不满足时调用 Wait()；生产者修改状态后再发送通知。这样即使多个 goroutine 被唤醒、通知与消费之间发生竞争，也不会把不满足条件的数据当成可用。

把 Signal 或 Broadcast 理解成“请重新检查”，而不是“条件已经为真”。Wait 会原子地解锁并挂起，返回前重新加锁；返回后必须再次读取受保护的共享状态。

为什么 Wait 返回后还要重新检查条件

条件变量解决的是“没有工作时先睡眠，状态变化后再唤醒”的等待成本，不替调用方保存业务判断。Wait 等待期间不会持有 c.L；被唤醒后，它会在返回前重新锁住这把锁。此时另一个 goroutine 可能已经先拿到锁并取走了唯一任务，所以刚被唤醒的 goroutine 看到的条件仍然可能是 false。

另外，Broadcast 会唤醒所有等待者。多个消费者竞争同一个队列时，只有第一个拿到锁并取走任务的消费者能继续，其他消费者必须回到循环继续等待。这里的“虚假唤醒逻辑”通常不是 Cond 无故返回，而是代码把“收到通知”错误地当成了“条件成立”。

一段可复用的条件队列写法

下面的队列同时处理“为空”“已满”和“关闭”三种状态。消费者和生产者都在循环中检查自己的条件，通知发生在状态修改之后。示例里的注释只解释关键边界，便于直接改造成内存队列或任务池。

package main

import (
	"fmt"
	"sync"
)

type Queue struct {
	mu       sync.Mutex
	notEmpty *sync.Cond
	notFull  *sync.Cond
	items    []int
	capacity int
	closed   bool
}

func NewQueue(capacity int) *Queue {
	q := &Queue{capacity: capacity}
	// 两个 Cond 共享同一把锁，只等待不同的业务条件。
	q.notEmpty = sync.NewCond(&q.mu)
	q.notFull = sync.NewCond(&q.mu)
	return q
}

func (q *Queue) Put(v int) bool {
	q.mu.Lock()
	defer q.mu.Unlock()
	// 队列满或已关闭都不能继续写入；Wait 返回后仍要复查。
	for len(q.items) == q.capacity && !q.closed {
		q.notFull.Wait()
	}
	if q.closed {
		return false
	}
	q.items = append(q.items, v)
	// 状态已经改变，再通知可能等待数据的消费者。
	q.notEmpty.Signal()
	return true
}

func (q *Queue) Get() (int, bool) {
	q.mu.Lock()
	defer q.mu.Unlock()
	// 关闭后仍可取完残留数据，所以条件是“为空且未关闭”。
	for len(q.items) == 0 && !q.closed {
		q.notEmpty.Wait()
	}
	if len(q.items) == 0 {
		return 0, false
	}
	v := q.items[0]
	q.items = q.items[1:]
	// 腾出一个容量位置，唤醒可能等待空间的生产者。
	q.notFull.Signal()
	return v, true
}

func (q *Queue) Close() {
	q.mu.Lock()
	q.closed = true
	// 关闭是所有等待者都必须观察到的状态，使用广播。
	q.notEmpty.Broadcast()
	q.notFull.Broadcast()
	q.mu.Unlock()
}

func main() {
	q := NewQueue(2)
	q.Put(7)
	v, ok := q.Get()
	fmt.Println(v, ok)
}

几个细节容易漏掉：Cond 不能在首次使用后复制；Signal 只唤醒一个等待者，不保证调度优先级；Broadcast 适合关闭或全局状态变化，但所有被唤醒者仍然要重新竞争锁并检查自己的条件。若关闭操作只修改 closed 却不广播，已经睡眠的 goroutine 可能永远没有退出机会。

sync.Cond、channel 和 Mutex 怎么选

工具选型先看数据模型，而不是先看哪个 API 更短。Mutex 只负责保护一小段临界区；它不会让 goroutine 在条件不满足时自动等待。channel 更适合把值或事件从发送方交给接收方，并天然表达阻塞、关闭和所有权转移。sync.Cond 适合多个 goroutine 反复观察一组可变共享状态，例如队列容量、资源池或“关闭但仍需排空”的复合条件。

如果只是把一个生产者的结果交给一个消费者，channel 通常更直观；如果需要在同一份共享结构上维护多个不变量，Cond 可以减少人为拼接多个 channel 的复杂度。但 Cond 也更容易因漏锁、错用 if 或忘记广播而形成永久阻塞，使用前应把“谁修改条件、谁等待条件、关闭后如何退出”写成明确的约束。

常见问题

Wait 能不能放在 if 里？

不建议。Wait 返回后条件可能已被其他 goroutine 消费，应该用 for 重新读取共享状态。

调用 Signal 前必须持有锁吗？

Go 文档允许调用者不持有 c.L 调用 Signal 或 Broadcast，但条件修改仍应受锁保护。工程上把状态修改和通知放在同一临界区内，通常更容易审查。

什么时候直接改用 channel？

当通信核心是传递值、任务或关闭事件，且接收方不需要直接维护同一组共享不变量时，channel 往往更简洁；复杂共享条件再保留 Cond。