Go语言sync.Cond与channel在条件等待中的选择

在Go语言的并发编程中，让一个Goroutine等待特定条件成立是常见需求。Go标准库提供了sync.Cond（条件变量）和channel（通道）两种机制来实现这一功能。虽然两者都能达到“等待”和“通知”的目的，但它们的适用场景和底层逻辑截然不同。正确选择两者，能让代码更简洁且不易出错。

一、 判断核心需求：信号通知还是状态检查？

在动手写代码前，必须先明确你的核心需求是哪一种。这直接决定了你该使用哪种工具。

分析你的业务逻辑：

1. 如果是“一次性通知”或“广播”：例如，任务完成后通知所有Worker停止工作，或者某个初始化步骤完成后通知后续流程继续。这种场景下，关注点在于“事件发生了”，而非“某个具体的数值变成了多少”。
   • 选择 channel。
2. 如果是“反复检查复杂状态”：例如，生产者消费者模型中，消费者等待队列非空；或者多个Goroutine等待某个共享变量（如计数器、配置项）达到特定阈值。这种场景下，关注点在于“状态是否满足”，且往往涉及对共享资源的互斥访问。
   • 选择 sync.Cond。

二、 使用Channel的场景：简单、直接、解耦

当需求仅仅是“发送信号”时，channel 是Go语言推荐的首选方案。它天然具有并发安全性，且语法简单。

1. 实现一对一通知

适用于生产者-消费者中的简单配对，或者主Goroutine等待子Goroutine结束。

编写以下代码：

package main

import (
    "fmt"
    "time"
)

func main() {
    // **定义**一个无缓冲通道作为信号
    done := make(chan struct{})

    // **启动**子Goroutine
    go func() {
        fmt.Println("子Goroutine: 正在处理任务...")
        time.Sleep(2 * time.Second)
        fmt.Println("子Goroutine: 任务完成")
        // **关闭**通道或**发送**数据来通知
        close(done)
    }()

    fmt.Println("主Goroutine: 等待任务完成...")
    // **阻塞**等待通道信号
    <-done
    fmt.Println("主Goroutine: 收到信号，退出")
}

2. 实现广播通知（一对多）

利用channel被关闭后，接收操作会立即返回零值且不会阻塞的特性，可以实现广播。

编写以下代码：

package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(id int, done <-chan struct{}, wg *sync.WaitGroup) {
    defer wg.Done()
    fmt.Printf("Worker %d: 正在运行...\n", id)
    // **阻塞**等待，多个Goroutine都在等待同一个通道
    <-done
    fmt.Printf("Worker %d: 收到停止信号，退出\n", id)
}

func main() {
    var wg sync.WaitGroup
    done := make(chan struct{})

    // **启动**多个Worker
    for i := 1; i <= 3; i++ {
        wg.Add(1)
        go worker(i, done, &wg)
    }

    time.Sleep(1 * time.Second)
    fmt.Println("主程序: 准备广播停止信号")
    // **关闭**通道，一次性唤醒所有等待的Goroutine
    close(done)

    wg.Wait()
    fmt.Println("主程序: 所有Worker已退出")
}

注意：只有关闭通道才能实现一对多的“广播”效果，单纯往通道里发数据只能唤醒一个Goroutine。

三、 使用sync.Cond的场景：复杂的共享状态保护

当等待的条件非常复杂（例如 len(queue) > 0 && config.flag == true），且涉及频繁的锁竞争时，channel 会显得力不从心。你需要先拿锁，检查状态，如果不满足则等待，被唤醒后再检查。这正是 sync.Cond 的设计初衷。

1. 核心操作流程

在使用 sync.Cond 之前，必须理解其严格的执行顺序。下图展示了 Wait 和 Broadcast 的标准交互流程：

2. 代码实现

以下代码模拟了一个经典的生产者-消费者场景，只有当队列中有数据时，消费者才消费，否则一直等待。

编写以下代码：

package main

import (
    "fmt"
    "sync"
    "time"
)

type Queue struct {
    items []int
    // **定义**互斥锁和条件变量
    mu    sync.Mutex
    cond  *sync.Cond
}

func NewQueue() *Queue {
    q := &Queue{}
    // **初始化**条件变量，需关联一个锁
    q.cond = sync.NewCond(&q.mu)
    return q
}

// 消费者
func (q *Queue) Consume(id int) {
    // **获取**锁
    q.mu.Lock()

    // **循环检查**条件（防止虚假唤醒）
    for len(q.items) == 0 {
        fmt.Printf("消费者 %d: 队列为空，等待中...\n", id)
        // **调用**Wait，它会自动释放锁并挂起当前Goroutine
        // 被唤醒后会自动重新获取锁
        q.cond.Wait()
    }

    // 条件满足，处理数据
    item := q.items[0]
    q.items = q.items[1:]
    fmt.Printf("消费者 %d: 消费了数据 %d\n", id, item)

    // **释放**锁
    q.mu.Unlock()
}

// 生产者
func (q *Queue) Produce(item int) {
    // **获取**锁
    q.mu.Lock()

    q.items = append(q.items, item)
    fmt.Printf("生产者: 生产了数据 %d\n", item)

    // **通知**至少一个等待的Goroutine
    q.cond.Signal()
    // 如果想通知所有，使用 q.cond.Broadcast()

    // **释放**锁
    q.mu.Unlock()
}

func main() {
    q := NewQueue()

    // **启动**两个消费者
    for i := 1; i <= 2; i++ {
        go q.Consume(i)
    }

    // **启动**生产者
    for i := 1; i <= 5; i++ {
        q.Produce(i)
        time.Sleep(500 * time.Millisecond)
    }

    time.Sleep(1 * time.Second)
}

关键点解析：

• 循环检查：必须使用 for 循环而不是 if 语句。因为Goroutine可能被意外唤醒（虚假唤醒），也可能在被唤醒期间条件又被其他Goroutine修改了。
• 锁的绑定：sync.Cond 必须绑定一个 sync.Mutex 或 sync.RWMutex。
• Signal与Broadcast：Signal 随机唤醒一个等待者（节省资源），Broadcast 唤醒所有等待者（确保不漏掉任何一个，例如全局状态变更）。

四、 对比总结与选择建议

为了在实际开发中快速做出决策，请参考下表对比。表格上方和下方均保留了空行，以符合排版规范。

执行选择步骤：

1. 检查是否只是想让某个Goroutine停下来或继续执行。
   • 如果是，使用 chan struct{}。
2. 检查是否是在等待一个“共享数据结构”的状态变化（如队列长度、缓存大小）。
   • 如果是，且这个检查非常频繁，使用 sync.Cond。
3. 检查是否可以使用带缓冲的Channel直接替代“队列”。
   • 如果可以，优先使用 Channel（例如直接 ch <- item 和 item := <-ch），这通常比 sync.Cond 更地道且不易出错。

结论：在绝大多数Go语言应用开发中，channel 是更优的选择。只有在极少数涉及高并发下的精细状态控制，或者需要构建类似线程池、阻塞队列等基础数据结构时，才考虑使用 sync.Cond。