Go sync.Cond 为什么 Signal 不能替代共享状态检查

如果把 sync.Cond.Signal 当成“条件已经成立”的证明，并在唤醒后直接继续执行，代码就会把一次通知误当成共享状态。更稳妥的理解是：共享变量记录事实，Signal 只负责提示某个等待者重新查看事实；真正决定能否继续的是持锁检查的条件表达式。

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

Signal 只唤醒一个当前正在等待的 goroutine，而且没有等待者时不会留下可供以后消费的通知。等待方必须在持有同一把锁时用 for 重新检查共享状态；通知方也必须先修改状态，再发出通知。

Signal 通知的不是“条件为真”

sync.Cond 绑定一个 Locker。官方文档要求，修改条件和调用 Wait 时都要持有这把锁；Signal 可以在持锁或不持锁时调用，但它只唤醒一个正在等待的 goroutine。这个 API 没有把 Signal 保存成一个计数器，也没有承诺被唤醒后条件仍然成立。

因此需要把两个对象分开看：

为什么 Wait 必须放在 for 循环里

假设一个有界队列用 count > 0 表示可以取数据。消费者醒来时，可能是生产者刚放入了数据，也可能是多个消费者竞争同一项数据；当它重新拿到锁时，队列状态已经可能被另一个消费者改变。因此，安全模式不是“等一次再取”，而是“条件不满足就继续等”。

package main

import (
	"fmt"
	"sync"
)

type Queue struct {
	mu    sync.Mutex
	cond  *sync.Cond
	items []string
}

func NewQueue() *Queue {
	q := &Queue{}
	q.cond = sync.NewCond(&q.mu) // Cond 与保护 items 的同一把锁绑定。
	return q
}

func (q *Queue) Put(item string) {
	q.mu.Lock()
	q.items = append(q.items, item) // 先发布共享状态，再通知等待者。
	q.cond.Signal()                  // 只唤醒一个可能的消费者。
	q.mu.Unlock()
}

func (q *Queue) Get() string {
	q.mu.Lock()
	defer q.mu.Unlock() // Wait 返回时已经重新持有 q.mu，统一在退出时释放。

	for len(q.items) == 0 {
		q.cond.Wait() // Wait 原子释放 q.mu；返回前会再次拿回 q.mu。
	}
	item := q.items[0]
	q.items = q.items[1:] // 条件再次成立后，才消费共享状态。
	return item
}

func main() {
	q := NewQueue()
	go func() { q.Put("ready") }()
	fmt.Println(q.Get())
}

这里的 Signal 并没有把数据交给消费者，它只是在 items 已经变为非空后提醒一个等待者。消费者重新拿锁后仍然要执行 len(q.items) == 0 检查；如果条件又不成立，就回到 Wait。

通知顺序决定了能否观察到状态

通知方的核心顺序是“加锁、修改状态、通知、解锁”。把 Signal 写在修改状态之前，会让等待者醒来后读到旧状态；它随后会再次进入循环等待，而这次状态修改可能已经没有新的通知。即使某些时序下代码看起来能工作，也不应该依赖这种偶然顺序。

另一个容易忽略的边界是：如果生产者在消费者进入 Wait 前完成了状态修改并调用了 Signal，这次通知可能没有等待者可以唤醒。但只要状态仍然保存在 items 中，消费者随后加锁检查时会发现 len(q.items) > 0，根本不会进入等待。正因为状态独立存在，程序才不依赖“必须先收到通知”。

Signal、Broadcast 和共享状态怎么选

如果一次状态变更只需要一个消费者继续工作，例如队列从空变为非空，通常可以用 Signal。如果一个状态变化可能让多个不同等待条件同时满足，或者所有等待者都需要重新判断，就用 Broadcast。两者都不能替代条件变量本身的共享状态。

如果等待方需要的是一个不可错过的事件计数，而不是“某个共享条件何时成立”，就要重新设计状态模型；仅仅把 Signal 改成 Broadcast，也不能让通知具备持久化语义。

排查 sync.Cond 问题时先看这四件事

1. 等待方是否在持有 Cond.L 时读取条件，并把 Wait 放在 for 循环里？
2. 通知方是否在同一把锁保护下先修改共享状态，再通知？
3. 是否把 Signal 的返回时机误当成业务成功，或者把一次唤醒当成永久许可？
4. 是否因为多个消费者竞争，醒来后条件已经被别人消费，仍然直接访问了共享数据？

最常见的修复不是增加更多 Signal，而是补齐“状态、锁、循环检查”这条关系。Cond 只负责让等待者在状态可能变化时重新获得运行机会；业务代码必须自己定义状态何时成立、谁修改它以及醒来后如何处理不成立的情况。

常见问题

Signal 没有等待者时，之后的 Wait 会自动被唤醒吗？

不会。Signal 只作用于当下已经在该 Cond 上等待的 goroutine。要避免遗漏，必须让真正的共享状态保留在锁保护的数据结构中，Wait 前先检查状态。

Wait 返回后还要检查条件吗？

要。Wait 返回只表示当前 goroutine 被 Signal 或 Broadcast 唤醒并重新拿回了锁，不表示业务条件必然成立。

修改状态后一定要持锁调用 Signal 吗？

文档允许 Signal 在不持锁时调用，但把状态修改和通知放在同一把锁保护的临界区里更容易表达完整的发布关系，也能避免通知与状态读取之间出现难以推断的时序。

总结一下：sync.Cond 的可靠性来自共享状态与锁，而不是来自 Signal 本身。把 Signal 当作“请重新检查”的提示，把 Wait 写进持锁的 for 循环，并在状态修改后通知，才能避免丢通知和醒来误判。