cond.Wait 和 cond.Signal 的正确使用场景是什么？-Golang-PHP中文网

cond.Wait必须在while循环中调用，因虚假唤醒和竞态要求反复检查谓词；cond.Signal须在持锁修改状态后、释放锁前调用；cond.Wait与cond.Signal必须共用同一把锁；Condition适用于低频、长时间等待共享状态变更的场景。

cond.Wait 必须在 while 循环中调用

直接用 if 判断后调用 cond.wait() 是常见错误，会导致虚假唤醒（spurious wakeup）或条件被其他线程抢先修改后继续执行，引发数据错乱。posix 和 jvm 的 condition 实现都明确允许 cond.wait() 在无信号时返回，也允许一个 cond.signal() 唤醒多个线程（尤其在多核系统上）。

正确做法是：获取锁后，用 while 循环反复检查谓词（predicate），仅当条件真正满足时才退出循环：

lock.Lock()
defer lock.Unlock()
for len(queue) == 0 {  // 谓词：队列为空
    cond.Wait()  // 自动释放 lock，唤醒后自动重新获取
}
item := queue[0]
queue = queue[1:]

不能写成 if len(queue) == 0 { cond.Wait() }
即使只期望唤醒一个线程，也要循环检查——因为唤醒不等于条件成立
Java 中 await()、Go 的 Cond.Wait()、C 的 pthread_cond_wait() 全部适用该规则

cond.Signal 应在修改共享状态后、释放锁前调用

cond.Signal() 本身不操作共享数据，也不释放锁，它只是向等待队列发一个通知。如果在释放锁之后调用，可能出现「状态已变但通知丢失」的竞态：新线程抢先进入并再次阻塞，而旧线程的 signal 没有等待者接收。

典型安全顺序是：

lock.Lock()
// 修改共享状态：如 queue.push(item), count++
if len(queue) == 1 {  // 刚从空变为非空，值得通知消费者
    cond.Signal()
}
lock.Unlock()

必须在持有锁期间判断是否需要 signal —— 否则无法原子地观察状态+决定通知
不要在 unlock 后调用 cond.Signal()，哪怕看起来“逻辑更顺”
若需唤醒所有等待者（例如关闭信号、批量就绪），用 cond.Broadcast() 或 cond.SignalAll()，但代价更高

cond.Wait 和 cond.Signal 必须共用同一把锁

Condition 不是独立同步原语，它必须与且仅与一个互斥锁绑定。例如 Go 的 sync.Cond{L: &mutex}、Java 的 ReentrantLock.newCondition()、C 的 pthread_cond_wait(&cond, &mutex) 都强制要求传入 mutex。跨锁使用会导致未定义行为，轻则死锁，重则内存破坏。