是的，sync.cond.signal 严格只唤醒一个正在 wait 的 goroutine，且随机选择，不保证 fifo 或优先级；它与 pthread_cond_signal 行为一致，但常因条件检查未用 for 循环、锁保护不当或并发 signal 被误认为多播。
sync.Cond.Signal 真的是单播吗？
是的，sync.Cond.Signal 严格只唤醒一个正在 Wait 的 goroutine，且是随机选一个——不是按等待顺序，也不是按优先级。它不保证唤醒“最早等待的那个”，也不保证唤醒“还没执行过 Wait 后逻辑的那个”。这和 pthread 的 pthread_cond_signal 行为一致。
常见误解是认为 Signal 会唤醒“下一个该轮到的”，但 Go 的实现里没有队列 FIFO 语义；它只是从内部 notifyList 中挑一个就绪的 goroutine 唤醒。
如果你观察到多个 goroutine 同时往下走，问题大概率不在 Signal 本身，而在于：
- 条件检查用了
if而不是for，导致虚假唤醒后直接跳过重检 - 唤醒后没重新加锁或没保护共享状态读取，造成竞态
- 多个 goroutine 在同一时刻调用
Signal（比如并发归还资源），叠加效果看起来像“多播”
为什么 Wait 必须配合 for 循环？
因为 cond.Wait() 返回只代表“可能有变化”，不代表“条件已满足”。它可能被系统信号、调度器抢占、甚至 runtime 内部机制提前唤醒（即虚假唤醒）。所以你必须在 Wait 返回后，**再次检查条件是否真成立**。
错误写法：if !conditionMet() { cond.Wait() } —— 一旦被虚假唤醒，就直接跳过检查，后续逻辑可能基于错误状态运行。
正确写法必须是：
mu.Lock()
for !conditionMet() {
cond.Wait() // 自动 unlock → wait → re-lock
}
// 此时 conditionMet() 为 true，才安全操作
mu.Unlock()
注意：cond.Wait() 内部会先 unlock 当前持有的锁，等被唤醒后再自动 re-lock。所以循环体外不能漏掉 mu.Lock()，也不能在循环内重复 lock。
Signal 和 Broadcast 在资源池场景怎么选？
关键看“满足条件后，是否只有一个 goroutine 能消费它”。
典型资源池（如 RabbitMQ channel 池、数据库连接池）中：
- 获取资源时用
Signal是错的：如果多个 goroutine 在等空闲 channel，只唤醒一个，其余继续阻塞，但其实只要有一个 channel 归还，就可能有多个等待者能拿到——这里需要的是“通知所有人来抢” - 归还资源时必须用
Broadcast：因为归还动作让“空闲资源数 > 0”这个条件变为真，所有等待者都应有机会重试获取
换句话说：Signal 适合“点对点任务分发”，比如一个任务队列，每次只派一个 job 给一个 worker；Broadcast 适合“状态广播”，比如缓存失效、资源可用、配置更新等影响全体的事件。
容易被忽略的锁生命周期细节
cond.Wait() 要求调用前已持有 cond.L 所关联的锁，否则会 panic：sync: Cond.Wait with uninitialized Cond 或更常见的 unlock of unlocked mutex。
但真正难调试的是锁的“作用域错位”：
- 在
for循环外mu.Lock()，但在循环内某次cond.Wait()返回后，忘记检查是否仍需继续等待，就直接mu.Unlock()—— 这会导致临界区提前退出 - 条件函数
conditionMet()访问了未被同一把锁保护的字段，造成读到脏数据 - 多个
Cond共享同一把锁但各自管理不同条件，结果一个Broadcast唤醒了不该醒的 goroutine（它们等的是另一个条件）
最稳妥的做法：每个独立的等待逻辑配专属 Cond + 专属条件变量 + 明确的锁保护范围，避免混用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
