sync.Cond.Broadcast()会唤醒所有等待goroutine，导致锁争用激增、CPU空转、吞吐骤降；根本原因是唤醒后必须抢同一把锁再判断条件，多数会立即重Wait；应拆分Cond实例、用channel替代简单通知、加原子预检避免无效唤醒。
sync.Cond.Broadcast() 触发“惊群效应”的真实表现
当上百个 goroutine 同时调用 cond.wait()，而你执行一次 cond.broadcast()，它们会**全部被唤醒、全部尝试重新获取锁、全部检查条件、绝大多数立刻再次进入 wait()**。这不是理论推测——压测时能清晰看到 mutex contention 暴涨、cpu 在锁争用上空转、吞吐量断崖式下跌。
根本原因在于：Broadcast 本身不判断谁该醒，只负责“拉铃”；而每个被唤醒的 goroutine 都要抢同一把锁，哪怕它醒来发现条件仍不满足（比如队列还是空），也得先抢到锁才能继续判断和重 Wait。
- 典型错误场景：限流器中所有等待令牌的协程共用一个
sync.Cond，令牌只补一个，却用Broadcast() - 更隐蔽的问题：多个逻辑上独立的等待组（如不同优先级消费者）误共享同一个
Cond实例 - 注意：Go runtime 虽做了唤醒队列优化，但无法绕过“抢锁 → 判断 → 可能再 Wait”这个必然路径
Signal() 不是万能解药，但必须明确“谁该被唤醒”
cond.Signal() 确实只唤醒一个 goroutine，避免了批量抢锁，但它不保证唤醒的是“最合理那个”。调度器决定唤醒谁，而 Go 不提供优先级或 FIFO 保证（Signal() 唤醒的是“等待时间最长的”仅在文档中描述，实际行为依赖 runtime 实现，不可依赖）。
所以用 Signal() 的前提是你能接受“随机唤醒一个”，且业务上允许它失败后由下一个被唤醒者接力——比如生产者每次只投一个任务，消费者取完立即返回，自然形成轮转。
- 必须搭配循环检查：永远写
for len(queue) == 0 { cond.Wait() }，不能写if - 不要在锁外调用
Signal()后“以为通知已送达”——若此时无 goroutine 在 Wait，通知就丢了；建议在锁内完成状态更新 +Signal() - 如果业务要求“唤醒特定类型协程”（如高优任务必须优先处理），
sync.Cond本身不支持，得换方案（如多级 channel 或带优先级的任务队列）
真正规避惊群的三个实操动作
不是选 Signal 还是 Broadcast 的问题，而是整个同步设计是否让“唤醒”这件事变得必要且精准。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 拆分 Cond 实例：把语义不同的等待逻辑隔离，例如
highPrioCond和lowPrioCond分开，避免低优 goroutine 被高优事件广播惊醒 - 用 channel 替代简单通知：如果只是“等初始化完成”“等关闭信号”，直接用
done chan struct{}+close(done)，零锁争用、无虚假唤醒、语义更直白 - 加一层轻量状态预检：在调用
cond.Signal()前，先原子读一下当前待处理数（如atomic.LoadUint64(&pending)），仅当 > 0 才 Signal；这能过滤掉“通知发了但其实没活干”的无效唤醒
为什么 Wait 必须写在 for 循环里，而不是 if
这不是防御“虚假唤醒”这么简单——它是在防御整个并发模型里的时序裂缝。即使没有虚假唤醒，也可能发生：goroutine A 判断 len(queue) == 0 为真，准备 Wait；goroutine B 此刻插入一个元素并调用 Signal()；A 还没来得及挂起就被唤醒，抢到锁后发现 queue 已有数据，本可直接处理；但如果你用了 if，它就会跳过检查直接往下走，结果操作的是旧数据甚至 panic。
循环检查是唯一能确保“唤醒后看到的状态，是我自己亲手确认过的最新状态”的方式。
- 错误写法：
if queue.Empty() { cond.Wait() } - 正确写法：
for queue.Empty() { cond.Wait() }，且queue的所有读写都必须受同一把锁保护 - 别省略这层循环——它成本极低，但省掉它，等于把竞态漏洞明文写进代码
