Golangsync.Cond条件变量使用实践

P粉602998670

发布时间：2025-09-23 15:30:01

471人浏览过

来源于php中文网

原创

sync.Cond是Go中协程等待条件成立的同步机制，需与互斥锁配合使用，核心方法为Wait、Signal和Broadcast；典型应用场景如生产者-消费者模型中高效通知数据就绪，使用时须在循环中检查条件以避免虚假唤醒，根据等待协程数量选择Signal或Broadcast。

golangsync.cond条件变量使用实践

在Go语言中，sync.Cond 是一种用于协程间同步的机制，它允许协程等待某个条件成立后再继续执行。虽然日常开发中使用频率不如 channel 或 sync.Mutex 高，但在某些特定场景下，比如多个协程需要等待共享状态变化时，sync.Cond 能提供更精确的控制。

什么是 sync.Cond？

sync.Cond 是“条件变量”（Condition Variable）的实现，它通常与互斥锁（*sync.Mutex 或 *sync.RWMutex）配合使用。它的核心方法有三个：

Wait()：释放锁并阻塞当前协程，直到被其他协程唤醒。
Signal()：唤醒一个正在等待的协程。
Broadcast()：唤醒所有等待的协程。

注意：调用 Wait() 前必须持有锁，而 Wait() 内部会自动释放锁，并在唤醒后重新获取锁。

典型使用模式

使用 sync.Cond 的标准流程如下：

立即学习“go语言免费学习笔记（深入）”；

l := &sync.Mutex{}
cond := sync.NewCond(l)
cond.L.Lock()
for !condition() {
    cond.Wait()
}
// 处理条件满足后的逻辑
cond.L.Unlock()

关键点在于：必须在循环中检查条件，避免虚假唤醒（spurious wakeup）导致的问题。

实际应用场景示例：生产者-消费者模型

假设我们有一个缓冲区，生产者向其中添加数据，消费者等待数据到来后再读取。我们可以用 sync.Cond 实现高效的等待/通知机制。

纵横B2B电子商务系统

经过数月的努力，纵横B2B V3.0正式发布。感谢所有用户的大力支持和耐心等待，升级过程中提出了众多有价值的功能建议，向他们致敬。本次升级直接跨越到3.0版本，意味着将会带来很多新的变化。首先最大的变化是用户中心，我们借鉴了大量SNS社区、WEB2.0网站的概念，增强了交互性和可操作性；其次彻底抛弃了关键词竞价模式，改为直接购买关键词，为网站带来直接收益创造了条件；对系统性能进行了大量改进，使得系

下载

package main
import (
"fmt"
"sync"
"time"
)
type Queue struct {
items []int
lock  sync.Mutex
cond  sync.Cond
}
func NewQueue() *Queue {
lock := &sync.Mutex{}
return &Queue{
items: make([]int, 0),
lock:  lock,
cond:  sync.NewCond(lock),
}
}
func (q *Queue) Put(item int) {
q.lock.Lock()
defer q.lock.Unlock()
q.items = append(q.items, item)
q.cond.Signal() // 唤醒一个等待的消费者
}
func (q *Queue) Get() int {
q.lock.Lock()
defer q.lock.Unlock()
for len(q.items) == 0 {
q.cond.Wait() // 等待数据到来
}
item := q.items[0]
q.items = q.items[1:]
return item
}
func main() {
queue := NewQueue()
// 启动消费者
go func() {
    for {
        val := queue.Get()
        fmt.Printf("Consumed: %d\n", val)
    }
}()

// 生产者
for i := 0; i zuojiankuohaophpcn 5; i++ {
    queue.Put(i)
    time.Sleep(100 * time.Millisecond)
}

time.Sleep(time.Second)
}
在这个例子中，消费者调用 Get() 时如果队列为空，就会进入等待状态。生产者每次放入数据后调用 Signal()，唤醒一个消费者。这种方式比轮询更高效，也比使用 channel 更灵活（例如可以动态控制唤醒策略）。
Signal vs Broadcast：如何选择？

当只有一个协程在等待某个条件时，使用 Signal() 即可。
当多个协程可能等待同一条件，且条件变化会影响所有等待者时，应使用 Broadcast()。

例如，在缓存失效通知场景中，多个读协程可能都在等待更新，此时应广播唤醒全部协程。
基本上就这些。sync.Cond 不复杂但容易忽略细节，关键是配对使用锁、在循环中检查条件、正确选择唤醒方式。合理使用能提升程序效率和响应性。