Go互斥锁保护带参数条件变量唤醒函数设计

先搞清楚一件事：Cond.Signal和Cond.Broadcast为什么不能带参数？

Go标准库里的sync.Cond，它的Signal和Broadcast确实没给参数接口。这不是疏忽，而是一个有意的设计选择。本质上说，条件变量是“条件重检机制”，它负责通知等待者“嘿，条件变了，你再看看”，但不负责传数据。如果非要把参数塞进去，反而是把简单问题搞复杂了，反而容易引出竞态和误唤醒的麻烦。

用Mutex+Cond实现带参数唤醒的正确姿势

既然标准库没提供带参数唤醒，那怎么实现“定向唤醒+传数据”呢？思路其实很直接：把“参数”存到一个共享结构体里，然后在Cond.L.Lock()的保护下写入，之后调用Signal()或Broadcast()。被唤醒的goroutine在锁的保护下读取并消费参数。所有读写必须在同一把Mutex下完成，这是关键。

容易出错的情况

• 调Signal()之前没加锁就写参数→等待者可能读到零值或脏数据
• 唤醒后直接unlock，不检查条件是否真满足→虚假唤醒后直接panic或逻辑错乱
• 多个goroutine同时改同一个参数字段→数据互相覆盖

实操建议

1. 定义一个结构体做参数载体。比如type WakeupData struct { ID int; Payload interface{} }
2. 用sync.Mutex保护整个结构体读写，别只锁部分字段
3. 唤醒方操作顺序：mu.Lock() → 更新wakeupData → cond.Signal() → mu.Unlock()
4. 等待方操作顺序：循环中加锁 → 检查条件（比如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()可能在条件没真正变化时就返回旧数据，导致逻辑错乱。清空动作必须和条件检查在同一个临界区内完成。