Go语言Cond条件变量同步详解

本文深入解析了Go语言中sync.Cond条件变量的正确使用方法与常见陷阱，强调其必须与互斥锁协同工作、自身不保存任何状态的核心原则；重点指出Wait前须持锁、唤醒后必须循环检查条件以规避虚假唤醒、Signal/Broadcast宜在锁内调用等关键实践，并明确对比了Cond与channel的适用边界——对于简单的一次性通知场景，channel更简洁安全，而Cond更适合需多goroutine等待同一动态条件（如缓冲队列非空）的复杂同步需求。

Cond 必须和互斥锁一起用，单独 new(sync.Cond) 没有意义

sync.Cond 本身不保存状态，它只是对底层 Locker 的“条件通知”增强。你不能靠 Cond.Wait() 等待某个变量变 true 就完事——必须先用互斥锁保护该变量的读写，否则会竞态。

常见错误是这样写：

var ready bool
cond := sync.NewCond(&sync.Mutex{})
// …… goroutine 中直接 cond.Wait() —— 错！ready 没被锁保护，读写都可能乱

• 正确做法：用 sync.Mutex 或 sync.RWMutex 包裹条件判断和等待逻辑
• Wait 前必须已持有锁；Wait 返回时自动重新持有锁（所以退出前要记得 Unlock()）
• Signal/Broadcast 不要求持有锁，但实践中建议在锁内调用，避免通知丢失

Wait 会自动释放锁并挂起，但唤醒后需重新检查条件

Cond.Wait() 不是“等条件成立”，而是“等别人 Signal/Broadcast + 自己重新抢到锁 + 你自己再判断一次”。这是最常被忽略的点——漏掉二次检查，就会出现虚假唤醒或逻辑跳过。

典型场景：生产者往缓冲队列塞数据，消费者等 len(queue) > 0 才取。

• 错误写法：if len(queue) == 0 { cond.Wait() } → 唤醒后不检查，可能 queue 又空了
• 正确写法：必须用 for len(queue) == 0 { cond.Wait() } 循环等待
• Signal 是唤醒一个等待者，Broadcast 唤醒全部；高并发下 Broadcast 更安全，但代价略高

别用 Cond 实现简单的一次性通知，用 Channel 更自然

如果只是“等一个事件发生”，比如初始化完成、某个任务结束，sync.Cond 是过度设计。Go 的 channel 天然支持阻塞等待、类型安全、可关闭语义，且更易读。

对比：

• Cond 版本：需要额外维护 ready bool、互斥锁、Cond 实例，Wait 要循环，Signal 要确保时机
• Channel 版本：done := make(chan struct{})，发端 close(done)，收端 <-done 即可，无竞态风险
• Cond 适合多 goroutine 等待同一动态条件（如资源池有空位、队列非空），且该条件由多个写操作共同影响

Cond.Broadcast 在高并发下可能触发惊群，注意性能边界

当上百个 goroutine 同时 Wait()，一次 Broadcast() 会让它们全部被唤醒、抢锁、检查条件、多数又立刻 Wait 回去——这就是“惊群效应”。虽然 Go runtime 做了一定优化，但压测时仍可观测到锁争用飙升。

• 能用 Signal() 就别用 Broadcast()，尤其当你知道只需唤醒一个消费者时
• 若必须 Broadcast，考虑加一层轻量级状态分片，比如把等待者按 key 分组，只唤醒相关组
• 注意：Cond 没有超时机制，Wait 不支持 context；需要超时请自己封装或换 channel + select

Cond 的难点不在 API，而在对“条件状态”的建模是否严密——锁的范围、检查的时机、唤醒的粒度，三者错一个，就容易卡死或跳过逻辑。写完务必用 -race 跑一遍。

今天关于《Go语言Cond条件变量同步详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！