Broadcast() 必然唤醒所有等待 goroutine，导致它们竞争同一把锁并重复检查条件，引发 CPU 升高和吞吐不增；根本原因是唤醒后未满足条件者立即重入 Wait()，而非 Wait() 本身问题。
sync.Cond.Broadcast() 为什么会触发惊群
当上百个 goroutine 同时调用 c.Wait()，一次 c.Broadcast() 会唤醒全部——这不是“可能”，而是确定行为。它们立刻竞争同一把锁（c.L），抢到的 goroutine 检查条件，大概率发现不满足（比如队列还是空），又立刻 c.Wait() 回去；没抢到的则持续自旋等待锁。结果是：CPU 升高、锁争用飙升、实际吞吐没提升。
- 根本原因不是
Wait()本身，而是所有被唤醒者都在同一临界区里重复检查 + 重等 - Go runtime 对 notify 队列做了优化（如逆序唤醒），但无法消除锁竞争这一层开销
- 常见错误现象：
pprof显示sync.Mutex.Lock占用大量 CPU，或压测时 QPS 卡在某个值上不再增长
什么时候必须用 Broadcast()，什么时候该换 Signal()
Signal() 和 Broadcast() 的语义差异远大于性能差异。选错会导致逻辑错误，而不仅是慢。
- 用
Signal()：生产者每次只放一个任务（如单个 job 入队），消费者只需一个能干活的 → 唤醒一个即可，避免无谓唤醒 - 用
Broadcast()：全局状态变更（如shutdown = true、配置重载完成），所有等待者都必须立即响应 → 少唤醒一个就漏通知 - 注意：
Signal()不排队：如果当前没有 goroutine 在Wait()，信号直接丢失；Broadcast()同理，不会缓存
Wait() 必须套在 for 循环里，不是建议，是强制
虚假唤醒（spurious wakeup）和条件竞态会让 if 判断彻底失效。哪怕你确认只用 Signal()，也绝不能省略循环。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
if len(items) == 0 { c.Wait() }→ 唤醒后直接读items，可能仍是空 - 正确写法：
for len(items) == 0 { c.Wait() }→ 每次唤醒都重新检查，且检查与Wait()在同一把锁下 - 关键点：循环体外不能提前释放锁；
Wait()内部会自动 unlock/lock，所以循环内不要手动 unlock
Cond 生命周期和锁绑定容易被忽略的坑
sync.Cond 不是线程安全的可复制对象，它的 L 字段指向的锁一旦创建就不能变。很多问题源于临时构造 Cond 或锁作用域错配。
- 别在 goroutine 里
new(sync.Cond)并传入局部sync.Mutex变量 → 锁变量一出作用域就失效，Wait()行为未定义 - Cond 应和锁生命周期一致：锁是包级变量 or 结构体字段，Cond 也应是同级声明
- 别尝试复用同一个 Cond 实例去等待不同条件（如既等队列非空，又等资源池有空位）→ 条件混杂，
Signal()语义失控
真正难的不是写对 Wait() 循环，而是判断“这个条件是否真的需要广播”。多数时候，你心里想的是“快唤醒一个来干活”，却顺手写了 Broadcast() —— 这个下意识动作，就是惊群的起点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
