Go sync.Cond 先 Signal 后 Wait 为什么会一直阻塞

如果你看到 Go 代码先调用 cond.Signal()，后面才进入 cond.Wait()，而等待 goroutine 一直不返回，通常不是调度器“漏唤醒”，而是把条件变量误当成了可积压的消息。

sync.Cond.Signal 只负责唤醒当前已经在等待的一个 goroutine。调用 Signal 时没有等待者，通知就不会替未来的 Wait 保存下来。可靠写法必须同时维护一个由同一把锁保护的共享条件：通知方先改变条件，再 Signal；等待方拿锁检查条件，只有条件不满足时才在 for 中 Wait。

一句话结论：Signal 是“提醒已经排队的等待者”，不是“存一条以后再消费的消息”。先 Signal 后 Wait 想要不阻塞，必须让共享状态本身记住“条件已经成立”。

官方文档：https://pkg.go.dev/sync#Cond

先区分通知和条件状态

条件变量解决的是“条件还没满足时，goroutine 暂停等待”的问题。它本身不保存业务状态，也不记录累计通知次数。Signal 的语义是：如果现在有 goroutine 正在等待，就尝试唤醒其中一个；如果没有等待者，就没有可唤醒的对象。

因此，下面这种代码天然存在竞态窗口：

package main

import "sync"

func wrongOrder(cond *sync.Cond) {
	// 这里没有等待者时，Signal 不会替未来的 Wait 保存通知。
	cond.Signal()

	cond.L.Lock()
	// Wait 只会等待后续真正发生的唤醒，先前的 Signal 已经不在了。
	cond.Wait()
	cond.L.Unlock()
}

把 Signal 放到 Wait 前面并不能表达“将来有人来就自动通过”。如果业务上确实存在“事件已经发生”的记忆，就要把这个记忆写进共享状态，例如 ready = true，而不是寄托在 Cond 内部。

为什么 Wait 必须和共享条件使用同一把锁

Go 文档要求：修改条件时要持有关联的 Locker，调用 Wait 时也要持有它。这个要求不是形式检查，而是为了把“检查条件”和“进入等待”连接起来。

Wait 会原子地释放 c.L 并挂起当前 goroutine；被唤醒后，它会先重新获取 c.L，然后才从 Wait 返回。这样通知方才有机会拿到同一把锁修改状态，等待方恢复后也能重新读取受保护的状态。

典型等待方应该写成下面这样：

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

func NewGate() *Gate {
	g := &Gate{}
	// Cond 与 mu 绑定，状态检查和 Wait 使用同一把锁。
	g.cond = sync.NewCond(&g.mu)
	return g
}

func (g *Gate) WaitReady() {
	g.mu.Lock()
	defer g.mu.Unlock()

	// 条件不成立才等待；条件已成立时直接继续，不依赖历史 Signal。
	for !g.ready {
		g.cond.Wait()
	}
}

func (g *Gate) MarkReady() {
	g.mu.Lock()
	// 先落地状态，再通知等待者，避免通知和状态脱节。
	g.ready = true
	g.cond.Signal()
	g.mu.Unlock()
}

在这个版本里，即使 MarkReady 先执行，后来的 WaitReady 也不会阻塞：它拿锁后先看到 ready == true，直接离开循环。这里真正被保留下来的是状态，而不是 Signal。

为什么要用 for，而不是只 Wait 一次

被唤醒不等于条件一定成立。等待方从 Wait 返回前会重新竞争锁，其他 goroutine 可能已经改变了状态；多个等待者也可能同时围绕同一条件工作。因此，Cond 的标准用法是“持锁检查条件，条件不满足就 Wait，返回后再检查”。

只写一次 Wait 会把一次唤醒误认为业务许可：

func fragileWait(g *Gate) {
	g.mu.Lock()
	defer g.mu.Unlock()

	// 单次 Wait 只说明收到唤醒，不足以证明 ready 仍然为 true。
	if !g.ready {
		g.cond.Wait()
	}
	// 这里必须再次依赖 ready 的实际值，而不是依赖 Signal 的到达。
	if !g.ready {
		return
	}
	// 条件成立后再访问受保护的数据。
}

更稳妥的写法就是前面的 for !g.ready。它同时处理三个边界：通知早于等待、等待期间条件仍未成立，以及被唤醒后需要重新确认共享状态。

Signal 和 Broadcast 怎么选

Signal 只唤醒一个等待者，适合一次状态变化只需要一个消费者继续工作的场景。Broadcast 会唤醒所有正在等待的 goroutine，适合一个全局条件变成真、所有等待者都应该重新检查的场景。

两者都不是状态存储器。调用 Broadcast 前没有等待者，同样不会替未来的 Wait 记账。选择哪个方法时，先问“状态变化后需要多少个等待者重新检查”，不要问“之前积累了多少次通知”。

把先 Signal 后 Wait 的旧写法改成什么

可以按下面的改造表逐项检查：

最小回归检查应该看什么

这类问题不需要靠“多跑几次”证明正确。测试至少应覆盖通知早于等待和等待早于通知两种排列，并给等待动作设置超时，防止错误写法把测试永久挂住。断言重点是最终共享状态，而不是某个 goroutine 是否恰好先被唤醒。

func TestGateOrder(t *testing.T) {
	gate := NewGate()

	// 先更新状态再启动等待方，验证历史 Signal 不需要被保存。
	gate.MarkReady()
	done := make(chan struct{})
	go func() {
		gate.WaitReady()
		close(done)
	}()

	select {
	case 

实际项目中还应补上第二种排列：先启动 WaitReady，再调用 MarkReady。如果共享状态包含计数器、队列长度或关闭标志，也要让测试覆盖状态从真变假、重复通知和多个等待者的情况。并发代码提交前再配合 go test -race ./... 检查数据竞争；Race 检测器不能替代条件逻辑，但能帮助发现忘记用锁保护状态的路径。

结论

Go sync.Cond 的 Signal 是唤醒接口，不是消息队列。先 Signal 后 Wait 之所以会一直阻塞，是因为当时没有等待者，通知没有被缓存。修复的关键顺序是：用关联的锁修改共享条件，等待方在同一把锁下用 for 检查条件，条件不满足才 Wait，状态成立后再 Signal 或 Broadcast。

相关问题

• Signal 一定要在持锁时调用吗？文档允许不持锁调用，但共享条件的修改必须和等待方使用同一套锁保护；工程上通常把修改状态和通知放在持锁区间内，减少语义错配。
• 为什么不用 channel？简单的一对一通知或关闭广播通常更适合 channel；Cond 更适合已有锁保护状态、需要围绕复杂条件反复检查的低层同步代码。
• Wait 返回后还需要判断吗？需要。返回说明 goroutine 被唤醒并重新持锁，不等于业务条件一定为真，所以要继续使用条件循环。