用 Cond 协调批量状态变化而不是循环轮询

批量任务常见的一种写法，是每隔一段时间查看“已经完成多少”，没有达到目标就继续睡眠。这种轮询代码看起来简单，但等待间隔越短，空转越频繁；间隔越长，状态变化后的响应又越慢。更稳妥的做法是让等待者只在条件不满足时挂起，由更新状态的 goroutine 主动发出通知。

官方地址：https://pkg.go.dev/sync

本文使用 sync.Cond 组织一个批量处理器：多个等待者关注同一份状态，状态达到阈值时一次唤醒，关闭时让全部等待者离开。关键点只有一句话：Wait 必须放在锁保护的条件循环里，通知只负责唤醒，不能代替条件判断。

先把轮询改成条件等待

先看轮询模型的问题。它把“什么时候变化”交给时间间隔，而不是交给真正改变状态的代码。批量任务在第 1 秒完成时，消费者可能还要等到下一次 tick；如果状态一直不变，所有 goroutine 又会重复被唤醒。

sync.Cond 提供一个等待点。等待者拿到锁后检查条件，条件不满足就调用 Wait；Wait 会原子地释放关联的锁并挂起，恢复时重新拿回锁。状态更新方写入新状态后调用 Signal 或 Broadcast。

type Batch struct {
    mu        sync.Mutex
    changed   *sync.Cond
    finished  int
    target    int
    closed    bool
}

func NewBatch(target int) *Batch {
    b := &Batch{target: target}
    // Cond 与同一把锁绑定，所有状态读写都经过这把锁。
    b.changed = sync.NewCond(&b.mu)
    return b
}

func (b *Batch) WaitReady() bool {
    b.mu.Lock()
    defer b.mu.Unlock()
    // 条件循环防止被唤醒后状态仍未满足，也覆盖关闭分支。
    for b.finished = b.target
}

这里的 WaitReady 不依赖固定时间。它醒来后重新读取 finished 和 closed，只有条件确实满足才返回成功；如果是关闭通知，则返回失败，让上层决定如何结束任务。

让状态与 Cond 共用同一把锁

通知本身不是状态。只调用 Signal 并不能保证被唤醒的 goroutine 看到目标状态，也不能替代互斥锁。生产者要先在锁内修改共享字段，再通知等待者：

func (b *Batch) AddFinished(n int) {
    b.mu.Lock()
    // 先更新事实，再通知；等待者醒来后会重新检查条件。
    if !b.closed {
        b.finished += n
    }
    b.changed.Broadcast()
    b.mu.Unlock()
}

func (b *Batch) Close() {
    b.mu.Lock()
    // 关闭也是一种状态变化，必须唤醒仍在等待的 goroutine。
    b.closed = true
    b.changed.Broadcast()
    b.mu.Unlock()
}

批量状态更新和关闭都广播，是因为等待者关心的是同一组谓词：目标是否完成，或者处理器是否已经关闭。若只更新 closed 而不通知，正在等待的 goroutine 可能永远留在阻塞点。

按批量场景选择 Signal 或 Broadcast

Signal 最多唤醒一个等待者，适合一次状态变化只需要交给一个消费者处理的场景；Broadcast 唤醒所有等待者，适合“批量完成”“全局关闭”这类所有人都需要重新判断的变化。被唤醒后谁先拿到锁并不由 Signal 保证。

如果状态模型本来就是一条事件流，通道通常更直观：关闭通道可以表达“不会再有值”，发送可以表达一次事件。只有当多个等待者围绕一份可变共享状态反复判断，且需要精确控制唤醒范围时，Cond 才更有价值。

补上退出与误唤醒防护

最后检查三个边界。第一，Cond 不能在首次使用后复制；把它放进结构体时应通过指针传递结构体。第二，Wait 返回后不要直接执行成功路径，必须回到循环重新判断。第三，退出字段要和其他状态一样受锁保护，并在修改后广播。

func (b *Batch) Snapshot() (finished int, closed bool) {
    b.mu.Lock()
    defer b.mu.Unlock()
    // 快照只在锁内读取，避免调用方看到互相矛盾的字段。
    return b.finished, b.closed
}

func (b *Batch) WaitUntilDone() error {
    b.mu.Lock()
    defer b.mu.Unlock()
    // 关闭优先于完成结果，调用方可以据此停止后续工作。
    for b.finished 

这样改造后，等待时间由状态变化驱动，代码也把“完成”和“关闭”两条退出路径写成了明确的状态机。排查永久阻塞时，可以重点确认：是否所有状态更新都持有同一把锁、是否每条退出路径都广播、是否有 goroutine 在等待一个永远不会再变化的条件。

相关问题

Cond 能完全替代 channel 吗？

不能。简单事件传递优先考虑 channel；Cond 更适合围绕共享状态进行条件等待，并且需要多个观察者重复判断同一谓词的场景。

为什么 Wait 不能写成 if？

唤醒只代表“值得重新检查”，不代表条件一定满足。恢复后可能已有其他 goroutine 先改变状态，因此必须使用 for 循环保护实际条件。