当前位置：首页 > 文章列表 > Golang > Go问答 > Go sync.Cond 等待为什么会错过通知

Go sync.Cond 等待为什么会错过通知

来源：17golang原创 2026-10-14 05:35:23 0浏览收藏

使用 Go 的 sync.Cond 时，最容易误判的一幕是：一个 goroutine 调用了 Signal，另一个 goroutine 后面进入 Wait，结果后者一直等不到。真正要保存的不是通知，而是“条件已经满足”的共享状态。只要条件检查、进入等待和修改状态由同一把锁保护，通知先到达也不会让正确的等待者永久丢失。

下面按一个最小工作流拆开这个问题：先看通知窗口，再写出正确的等待协议，最后用锁、条件和唤醒范围逐项排查。

先区分“通知丢了”和“状态没有保存”

Signal 只负责唤醒当时正在等待的一个 goroutine；它不是带容量的消息队列。如果调用通知时没有等待者，这次通知不会替未来的等待者排队。因此，下面这种思路本身就不可靠：

// 错误示意：通知本身没有保存“已经打开”的状态。
cond.Signal()
// 另一个 goroutine 稍后才调用 cond.Wait，可能继续等待。

可靠协议是把“是否已经打开”放在共享变量里。等待者先锁住状态，条件已经满足就直接继续；只有条件不满足时才调用 Wait。这样，即使通知发生在等待者到达之前，等待者也能从状态变量读到结果，而不依赖一条已经过去的 Signal。

sync.Cond 共享条件与通知窗口的静态结构说明图 — 图1：结构说明图，展示共享条件、互斥锁与通知窗口的关系；这不是运行截图或调度器证据。

把条件检查和 Wait 放进同一把锁

官方文档要求：改变条件以及调用 Wait 时都要持有关联的 Locker。一个可复用的门闩示例可以这样组织：

package gate

import "sync"

type Gate struct {
    mu    sync.Mutex
    cond  *sync.Cond
    ready bool
}

func New() *Gate {
    g := &Gate{}
    // Cond 复用同一把锁，保证条件读写与等待协议一致。
    g.cond = sync.NewCond(&g.mu)
    return g
}

func (g *Gate) Wait() {
    g.mu.Lock()
    defer g.mu.Unlock()
    // 条件已经满足时不进入 Wait，避免依赖过去的通知。
    for !g.ready {
        g.cond.Wait()
    }
}

func (g *Gate) Open() {
    g.mu.Lock()
    // 先写入共享状态，再通知等待者。
    g.ready = true
    g.cond.Broadcast()
    g.mu.Unlock()
}

这里的关键不是 Broadcast 本身，而是 ready 的生命周期：Wait 读它，Open 写它，二者都经过 mu。因此通知早到时，后来的等待者会直接跳过等待。

为什么必须用 for，以及何时用 Signal

Wait 返回后，调用方重新拿到锁，但条件可能已经被其他 goroutine 改变。另一个等待者可能先消费了资源，或者生产者只发布了一份结果，所以不能把返回当成“条件必然成立”。for 会让等待者重新读取真实状态：

// 条件变量只负责唤醒，是否能继续由共享状态决定。
g.mu.Lock()
for g.remaining == 0 {
    // Wait 返回前会重新获得 g.mu，返回后仍需再次判断。
    g.cond.Wait()
}
g.remaining-- // 在锁内消费资源，避免多个等待者重复消费。
g.mu.Unlock()

如果一次状态变化只允许一个等待者继续，使用 Signal；如果状态变化可能让所有等待者都重新满足条件，使用 Broadcast。Signal 也不保证被唤醒的 goroutine 立即运行，其他竞争同一把锁的 goroutine 可能先拿到锁，所以不要把调度顺序写进业务假设。