Go互斥锁保护带参数条件变量唤醒函数设计
Go标准库条件变量Signal和Broadcast不带参数，通过互斥锁保护的共享结构体可实现带参数唤醒。等待方必须在for循环中检查条件并消费参数，避免虚假唤醒与数据竞争。清空操作需在临界区内完成。
先搞清楚一件事：Cond.Signal和Cond.Broadcast为什么不能带参数？
Go标准库里的sync.Cond，它的Signal和Broadcast确实没给参数接口。这不是疏忽，而是一个有意的设计选择。本质上说，条件变量是“条件重检机制”，它负责通知等待者“嘿，条件变了，你再看看”，但不负责传数据。如果非要把参数塞进去，反而是把简单问题搞复杂了，反而容易引出竞态和误唤醒的麻烦。
用Mutex+Cond实现带参数唤醒的正确姿势
既然标准库没提供带参数唤醒，那怎么实现“定向唤醒+传数据”呢？思路其实很直接：把“参数”存到一个共享结构体里，然后在Cond.L.Lock()的保护下写入，之后调用Signal()或Broadcast()。被唤醒的goroutine在锁的保护下读取并消费参数。所有读写必须在同一把Mutex下完成，这是关键。
容易出错的情况
- 调
Signal()之前没加锁就写参数→等待者可能读到零值或脏数据 - 唤醒后直接unlock，不检查条件是否真满足→虚假唤醒后直接panic或逻辑错乱
- 多个goroutine同时改同一个参数字段→数据互相覆盖
实操建议
- 定义一个结构体做参数载体。比如
type WakeupData struct { ID int; Payload interface{} } - 用
sync.Mutex保护整个结构体读写，别只锁部分字段 - 唤醒方操作顺序：
mu.Lock()→ 更新wakeupData→cond.Signal()→mu.Unlock() - 等待方操作顺序：循环中加锁 → 检查条件（比如
wakeupData.ID == targetID）→ 条件满足就消费并清空 → 解锁；条件不满足就cond.Wait()
为什么cond.Wait()必须放在for循环里？
这一点很容易被人忽略：Cond.Wait()返回并不等于条件已经满足。它只说明你被唤醒了，至于为什么会醒——可能是虚假唤醒（spurious wakeup），可能是别的goroutine在你之前抢走了资源，也可能是参数已经被覆盖。如果跳过条件检查直接读取，大概率会踩坑。
错误的写法是： 在Wait()后面接一个if wakeupData.ID == x { ... }
正确的写法：
mu.Lock()
for wakeupData.ID != targetID {
cond.Wait()
}
// 这里才安全地读取 wakeupData.Payload
mu.Unlock()
性能与可维护性的一个提醒
带参数唤醒本质上还是“轮询+通知”模型，不是channel那种点对点通信。如果你的唤醒目标固定，数量又不多（比如一对一任务派发），直接用chan结构会更清晰。只有等待者动态注册、或者需要广播并筛选的场景，才值得用Cond加共享参数。
还有一个容易被忽略的点：一旦使用共享的WakeupData结构体，就得明确它的生命周期。是每次唤醒后清空，还是允许累积？如果不清空，后续的Wait()可能在条件没真正变化时就返回旧数据，导致逻辑错乱。清空动作必须和条件检查在同一个临界区内完成。
