Go sync.Cond 的条件等待与唤醒设计

Go 的 sync.Cond 适合这样的场景：共享状态暂时不满足，调用方不想忙等，而状态变化时需要让一个或多个 goroutine 重新尝试。它不是“收到通知就继续”的消息队列，正确设计的核心是锁内检查条件，条件不满足才 Wait，被唤醒后再次检查。

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

可以把 sync.Cond 记成“状态变化后的重新检查点”：Mutex 保护条件，Wait 负责让出锁并休眠，Signal 或 Broadcast 只负责唤醒等待者，真正能不能继续仍由条件判断决定。

先把共享条件和 sync.Cond 放在一起

本文用一个有界任务队列说明设计。队列为空时，消费者等待；队列从空变为非空时，生产者唤醒一个消费者；队列从满变为未满时，消费者唤醒一个生产者。这里的条件不是 Cond 内部的字段，而是队列长度等共享状态。

sync.NewCond 接收一个 sync.Locker，常见传入 *sync.Mutex。同一把锁要保护“读取队列状态、修改队列状态、调用 Wait”这几类动作，否则检查和等待之间会出现竞态。

Wait 必须放在持锁的 for 循环里

Wait 的关键动作是原子地解锁并挂起当前 goroutine，之后被唤醒时再重新加锁后返回。因此调用方不能写成一次 if 判断：等待期间其他 goroutine 可能已经消费了资源，或者条件变化后又被其他任务改回去了。

package main

import (
    "fmt"
    "sync"
)

// Queue 保存共享任务，并让条件判断与队列修改使用同一把锁。
type Queue struct {
    mu       sync.Mutex
    notEmpty *sync.Cond
    items    []string
}

// NewQueue 在创建队列时绑定 Cond，后续不要复制已经使用过的 Cond。
func NewQueue() *Queue {
    q := &Queue{}
    q.notEmpty = sync.NewCond(&q.mu)
    return q
}

// Pop 等待队列非空；Wait 返回后仍要回到循环重新确认条件。
func (q *Queue) Pop() string {
    q.mu.Lock()
    defer q.mu.Unlock()

    for len(q.items) == 0 {
        q.notEmpty.Wait()
    }
    item := q.items[0]
    q.items = q.items[1:]
    return item
}

// Push 修改条件后通知等待者，通知发生在状态写入之后。
func (q *Queue) Push(item string) {
    q.mu.Lock()
    q.items = append(q.items, item)
    q.notEmpty.Signal()
    q.mu.Unlock()
}

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

这个模板有三个不能省略的点：进入检查前先锁定 mu；等待使用 for 而不是 if；状态修改完成后再通知。defer Unlock 让返回路径也能释放锁，适合示例中短小的临界区。

Signal 和 Broadcast 取决于状态变化的影响范围

Signal 唤醒一个等待者，适合一次只新增一个可消费任务的场景。Broadcast 唤醒所有等待者，适合条件一次性发生大范围变化，例如队列关闭、批量补充任务，或多个等待者都需要重新读取共享状态。

通知不等于把资源直接交给等待者。被唤醒的 goroutine 还要重新竞争关联锁，重新检查条件。尤其是多个消费者等待同一队列时，使用 Broadcast 会让它们依次醒来，但最终通常只有少数 goroutine 能拿到任务，其余 goroutine 会再次进入 Wait。

// PushBatch 一次加入多个任务，批量变化时唤醒全部消费者。
func (q *Queue) PushBatch(items []string) {
    q.mu.Lock()
    q.items = append(q.items, items...)
    // 只有状态已经写入，等待者醒来后才有机会看到新任务。
    q.notEmpty.Broadcast()
    q.mu.Unlock()
}

// Signal 不是调度优先级保证；它只表示至少一个等待者可以重新尝试。
func (q *Queue) PushOne(item string) {
    q.mu.Lock()
    q.items = append(q.items, item)
    q.notEmpty.Signal()
    q.mu.Unlock()
}

官方文档允许调用者在调用 Signal 或 Broadcast 时不持有 c.L，但本文示例仍把“修改状态和通知”放在同一临界区中，以便读者直观看到状态发布顺序。Broadcast 的等待者越多，唤醒成本越明显，临界区应保持短小。

把关闭状态也纳入条件表达式

真实队列通常不只有“有任务”和“没任务”两种状态，还要处理关闭。消费者应等待“有任务或已关闭”，这样关闭时即使队列为空也能退出；生产者在关闭后不应继续追加数据。

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

// Next 在队列关闭且已排空时返回 false，其余情况返回一个任务。
func (q *SafeQueue) Next() (string, bool) {
    q.mu.Lock()
    defer q.mu.Unlock()

    for len(q.items) == 0 && !q.closed {
        q.cond.Wait()
    }
    if len(q.items) == 0 && q.closed {
        return "", false
    }
    item := q.items[0]
    q.items = q.items[1:]
    return item, true
}

// Close 发布终态并唤醒所有消费者，避免有人永久睡眠。
func (q *SafeQueue) Close() {
    q.mu.Lock()
    q.closed = true
    q.cond.Broadcast()
    q.mu.Unlock()
}

关闭操作使用 Broadcast 是因为所有等待者都需要重新判断终态。判断顺序也很重要：先允许消费剩余任务，只有“队列为空且已关闭”时才返回结束。

设计完成后的检查表

如果问题只是把一次性事件传递给消费者，频道通常更直接；但当多个 goroutine 需要围绕同一个复杂共享状态反复等待时，sync.Cond 能把“状态保护”和“等待/唤醒”清晰地放到一个设计里。

相关问题

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

因为唤醒只代表可以重新尝试，其他 goroutine 可能已经改变了共享状态，所以必须重新持锁判断。

一个任务应该用 Signal 还是 Broadcast？

通常先用 Signal；如果状态变化会影响所有等待者，例如关闭或批量补充，再使用 Broadcast。

Cond 能不能复制？

不能在首次使用后复制。应让它作为长期对象的一部分，通过指针或外层结构管理。