Go sync.Cond 怎么避免丢通知：等待条件、Signal 顺序与退出清理

有界队列最容易暴露并发通知的漏洞：生产者已经把任务放进切片，消费者却还在睡；停机时又只唤醒了一个 goroutine，剩下的协程一直等不到退出信号。Go 的 sync.Cond 能把这两个等待点串起来，但它只负责唤醒，不替你保存“条件已经成立”这件事。

先把等待条件写成共享状态

这个示例做一个容量为 4 的任务队列。消费者只关心两件事：队列里有任务，或者队列已经停止。两件事都放在同一把 sync.Mutex 保护下，sync.Cond 只作为“状态发生变化”的通知点。

本篇只实现“消费者等待任务”的一侧，避免用一个 Cond 同时承载互相独立的生产者和消费者条件。条件越清楚，排查“为什么没醒”越容易。

从零写出不会丢通知的消费者

关键顺序只有三步：拿锁，循环检查条件，确认状态改变后再取数据。Wait 会在内部释放锁，所以生产者才能趁消费者等待时入队；它返回时又会重新拿锁。

package main

import (
    "fmt"
    "sync"
)

type Queue struct {
    mu      sync.Mutex
    changed *sync.Cond
    items   []string
    stopped bool
}

func NewQueue() *Queue {
    q := &Queue{}
    q.changed = sync.NewCond(&q.mu)
    return q
}

func (q *Queue) Push(item string) bool {
    q.mu.Lock()
    defer q.mu.Unlock()
    if q.stopped {
        return false
    }
    q.items = append(q.items, item)
    q.changed.Signal()
    return true
}

func (q *Queue) Pop() (string, bool) {
    q.mu.Lock()
    defer q.mu.Unlock()
    for len(q.items) == 0 && !q.stopped {
        q.changed.Wait()
    }
    if len(q.items) == 0 {
        return "", false
    }
    item := q.items[0]
    q.items[0] = ""
    q.items = q.items[1:]
    return item, true
}

func (q *Queue) Stop() {
    q.mu.Lock()
    q.stopped = true
    q.changed.Broadcast()
    q.mu.Unlock()
}

func main() {
    q := NewQueue()
    q.Push("job-17")
    item, ok := q.Pop()
    fmt.Println(item, ok)
    q.Stop()
}

这里的 for 不是为了防某一种特殊调度，而是因为唤醒后条件仍可能被别的消费者先取走。真正能否继续的依据永远是锁内状态：len(q.items) > 0 或 q.stopped。

为什么 Signal 要放在状态更新之后

如果先调用 Signal，再追加任务，唤醒的消费者可能立即重新拿锁并看到空队列；它会重新进入等待，而后续追加没有新的通知，就形成“任务已经在队列里但没人处理”的假象。先追加，再通知，消费者返回时看到的才是完整状态。

通知也不等于发出一条可积压的消息。消费者没有等待时，Signal 可以没有效果，但这并不丢任务，因为任务已经在 items 中；消费者下一次进入 Pop 时会直接读到它。这就是状态条件和一次性事件的区别。

多个消费者时，Signal 够不够

一次只新增一个任务时，唤醒一个消费者通常足够。若一次追加了多个任务，可以循环调用 Signal，也可以一次 Broadcast 让所有等待者竞争锁；后者会带来更多无效唤醒，最终仍要回到条件循环中核对。

停止时用 Broadcast 让所有人收尾

停机是另一个容易漏掉的分支。假设三个消费者都卡在 Wait，Stop 只调用一次 Signal，最多只有一个消费者能看到 stopped=true 并返回，另外两个仍然睡着。因此停止标记和 Broadcast 必须在同一把锁下完成。

for {
    item, ok := q.Pop()
    if !ok {
        // 队列已停止且没有剩余任务
        return
    }
    handle(item)
}

示例选择“先处理完队列中已有任务，再退出”：Pop 的条件是队列为空且已停止才返回 false。如果产品要求停止后立即丢弃剩余任务，可以在 Stop 中清空切片，但这会改变业务语义，不能只靠换通知方法解决。

把错误写法放进测试里

最常见的错误是把 Wait 放在 if 里，或者不持锁读 stopped。前者在多个消费者竞争时会取到已经不存在的任务，后者则让退出判断失去明确的同步边界。

// 错误：唤醒后没有重新确认条件
if len(q.items) == 0 {
    q.changed.Wait()
}
item := q.items[0]

// 正确：状态检查与 Wait 都在同一把锁保护下
for len(q.items) == 0 && !q.stopped {
    q.changed.Wait()
}

验收时至少覆盖三组场景：消费者先启动再入队、多个消费者同时等待后停止、停止后再调用 Push。运行 go test -race ./...，重点看是否出现数据竞争、永久等待或停止后仍接收任务。

什么时候换成 channel

官方文档明确提醒，很多简单场景用 channel 更直接：发送对应一个待处理值，关闭对应永久结束。若队列只是“生产者发任务、消费者收任务”，优先写 chan string；当多个条件共享一份复杂状态、需要精确控制锁内检查和批量唤醒时，再考虑 sync.Cond。

常见问题

sync.Cond.Wait 可以不放在 for 里吗？

不建议。返回只说明收到过 Signal 或 Broadcast，不代表业务条件仍然成立；必须重新检查共享状态。

调用 Signal 前一定要持有锁吗？

官方允许调用者不持有锁，但条件状态的修改和 Wait 必须在锁保护下。工程代码把状态修改、通知放在同一临界区，顺序更容易审查。

停止队列为什么不能只调用 Signal？

Signal 只唤醒一个等待者。停止是所有消费者都要观察的状态变化，应该设置停止标记后调用 Broadcast。

sync.Cond 能复制吗？

不能在首次使用后复制。把它放进结构体时应避免值拷贝，通常通过构造函数返回指针。

最后核对四个点

回到这段队列代码，只要确认“状态先变、通知后发；Wait 在 for 中；读写状态持有同一把锁；停止用 Broadcast”，就能避开大多数丢通知和停机悬挂问题。若需求只是传递任务值，换成 channel 往往更小；若等待条件本身就是共享状态的一部分，Cond 才值得保留。