Go sync.Cond 生产者消费者唤醒策略

Go 的 sync.Cond 适合把“队列状态发生变化”传给正在等待的 goroutine。生产者消费者模型里，生产者让队列从空变为非空时通知 notEmpty，消费者让队列从满变为未满时通知 notFull。单个元素只需要唤醒一个等待者，多种状态可能同时改变或需要结束等待时才考虑 Broadcast。

先把唤醒对象和队列状态分开

sync.Cond 关联一把 Locker。调用 Wait 时，当前 goroutine 会原子地释放这把锁并进入等待，返回前再重新加锁。因此，队列长度、关闭标记等状态必须由同一把锁保护；不要先解锁再凭一个布尔值决定是否等待。

下面的结构把“有数据可取”和“有容量可放”拆成两个条件。消费者只关心 notEmpty，生产者只关心 notFull，唤醒关系会比所有人共用一个条件更容易排查。

type Queue struct {
	mu       sync.Mutex
	notEmpty *sync.Cond
	notFull  *sync.Cond
	items    []int
	capacity int
}

func NewQueue(capacity int) *Queue {
	q := &Queue{capacity: capacity}
	// 两个条件共享同一把锁，保证判断和修改队列状态成对发生。
	q.notEmpty = sync.NewCond(&q.mu)
	q.notFull = sync.NewCond(&q.mu)
	return q
}

生产者消费者的两条唤醒边界

消费者取数据时，正确顺序是加锁、检查队列、为空就等待、醒来后再次检查。生产者入队后再通知 notEmpty；反方向同理。Signal 不保存“未来的一次唤醒”，所以即使通知发生在等待者到达前也不构成丢失：后来的 goroutine 会先看到已经改变的队列状态，不满足等待条件才会进入等待。

func (q *Queue) Put(v int) {
	q.mu.Lock()
	defer q.mu.Unlock()
	for len(q.items) == q.capacity {
		// 满队列时释放锁等待；返回后必须重新确认容量。
		q.notFull.Wait()
	}
	q.items = append(q.items, v)
	// 一个新元素只对应一个可运行的消费者，避免无谓惊群。
	q.notEmpty.Signal()
}

func (q *Queue) Get() int {
	q.mu.Lock()
	defer q.mu.Unlock()
	for len(q.items) == 0 {
		// 空队列时等待；被唤醒不代表数据一定仍然可取。
		q.notEmpty.Wait()
	}
	v := q.items[0]
	q.items = q.items[1:]
	// 出队释放一个容量位置，唤醒一个生产者即可。
	q.notFull.Signal()
	return v
}

这里的 for 不能改成一次性的 if。多个消费者同时被唤醒、其他 goroutine 抢先取走数据，或者条件被更复杂的停止逻辑改变时，醒来的 goroutine 都必须重新核对谓词。

什么时候从 Signal 切换到 Broadcast

Signal 只唤醒一个等待者，适合一次只增加一个元素或释放一个容量的位置。Broadcast 会唤醒全部等待者，适合队列关闭、消费者退出、配置恢复等场景：每个 goroutine 都需要醒来检查自己的退出条件，而不是争抢同一份数据。

关闭队列时，通常要在锁内设置 closed，然后调用 Broadcast。等待循环应写成“队列为空且未关闭才等待”；醒来后若已关闭且没有剩余数据，就返回结束信号。不要只广播而不改变状态，否则 goroutine 醒来后还会再次睡回去。

用四组边界检查唤醒策略

排查卡住时，先记录锁保护下的队列长度、容量和关闭标记，再看生产者是否在入队后通知、消费者是否在出队后通知。不要把 goroutine 数量变化直接解释成丢失唤醒；只要等待谓词、状态修改和通知顺序正确，调度顺序本身不应改变最终结果。

相关问题

为什么 sync.Cond 的 Wait 要放在 for 里？

因为唤醒只表示“值得重新检查”，不承诺返回时条件仍为真。循环能处理竞争、多个等待者和关闭状态。

Signal 没有等待者时会不会积累一次通知？

不会。Cond 不负责保存资源数量；资源数量应由队列状态表示，后来者会先检查状态再决定是否等待。

生产者消费者都用 Broadcast 可以吗？

语义上可以，但会让大量 goroutine 同时争抢同一把锁。若一次只新增一个元素或一个容量位置，Signal 通常更合适。