Go goroutine 退出前为什么要通知所有等待者

我们日常写Go并发逻辑时，经常能看到协程退出前会主动通知所有正在等待它的其他协程，这么做本质上是为了避免等待方无限阻塞，也能让协程生命周期的边界更清晰，防止出现悬空的协程泄漏。

在Go的并发模型设计里，goroutine退出本身不会主动向其他协程发信号，通知所有等待者是上层业务逻辑为了满足并发同步约定、避免死锁和资源泄漏而做的合理实现，不是goroutine运行时的强制要求。

“goroutine 退出了，为什么其他 goroutine 还在等？”关键在于：函数返回只结束当前 goroutine，不会自动广播一个退出事件。如果等待者阻塞在 channel、sync.Cond 或其他同步原语上，退出前必须明确发布终态；多个等待者通常用关闭 channel 或 Broadcast，而不是只调用一次 Signal。

退出、通知和共享状态不是一回事

Go 规范允许 goroutine 在函数返回时结束，但内存模型明确指出，goroutine 的退出本身不保证先于程序中的其他事件完成同步。于是下面这种想法是不可靠的：启动一个后台任务，然后让另一个 goroutine“等它自然退出”。自然退出没有可接收的句柄，也没有自动的广播队列。

正确做法是把“任务已经结束”变成一个明确的同步事件。通知还要和状态更新配套：先把 stopped、错误值或结果写入受保护的状态，再发布完成信号；等待者被唤醒后读取同一份状态。只通知、不保存状态，等待者仍不知道该做什么。

多个等待者为什么更适合关闭 done channel

如果事件只发生一次，而且所有等待者都只关心“是否完成”，可以把 channel 当作一次性闸门。关闭后的 channel 会让后续接收立即返回，因此 A、B、C 都能结束等待；它不是发送一个值，所以不会出现“第一个接收者拿走消息，其他人继续阻塞”的问题。

type Worker struct {
	done chan struct{}
	once sync.Once
}

func (w *Worker) run() {
	defer w.once.Do(func() {
		// 关闭 channel 发布一次性完成事件，避免多个退出路径重复 close。
		close(w.done)
	})
	// 这里执行任务；错误结果应另外保存并由 Wait 读取。
}

func (w *Worker) Wait() {
	// 接收关闭信号会阻塞到任务终态，之后所有等待者都可通过。
	

close 必须由约定的拥有者执行，不能让每个等待者都尝试关闭；重复关闭会 panic。若有多个可能的退出分支，defer 加 sync.Once 能把“只发布一次”写成明确约束。若还要传递错误，单独保存错误并在锁或其他同步关系下读取，不要把关闭 channel 当成错误载体。

共享条件变化时用 Broadcast，而不是猜醒谁

sync.Cond 适合等待一个由互斥锁保护的条件。例如任务结束后把 stopped 设为 true，再广播给所有等待者。Wait 返回不等于条件必然成立，所以必须使用循环重新检查条件；这也能抵抗其他 goroutine 先取得锁并改变状态的情况。

type State struct {
	mu      sync.Mutex
	stopped bool
	cond    *sync.Cond
}

func (s *State) finish() {
	s.mu.Lock()
	s.stopped = true // 先写终态，再唤醒观察者。
	s.cond.Broadcast() // 广播给所有等待 stopped 的 goroutine。
	s.mu.Unlock()
}

func (s *State) Wait() {
	s.mu.Lock()
	for !s.stopped {
		// Wait 临时释放锁；返回后重新持有锁并再次检查条件。
		s.cond.Wait()
	}
	s.mu.Unlock()
}

Signal 只唤醒一个等待者，适合只有一个消费者能够继续处理的场景；它不是“通知所有人”的替代品。很多简单的取消或完成场景，官方文档也建议优先考虑 channel：关闭 channel 对应广播，发送一个值更接近单次唤醒。

三种等待语义要怎样区分

最后复查四个边界：终态是否在通知前写入，通知是否只发生一次，等待是否支持超时或取消，以及结果和错误是否与信号建立了明确的同步关系。只要把“goroutine 结束”改写成可观察的事件，等待者就不会依赖调度器的偶然顺序。

常见问题

关闭 done 后还能继续向它发送值吗？

不能。关闭后的 channel 不能再发送，也不能再次关闭；如果既要传结果又要广播完成，应拆分结果存储和 done 信号。

为什么 Wait 还要用 for 循环？

因为被唤醒只表示可以重新竞争锁，不等于条件已经满足。重新检查条件才能避免误放行。

WaitGroup 能替代所有退出通知吗？

不能。它适合统计一组任务何时归零；如果等待者还要响应取消、读取错误或监听多个状态，仍需 channel、锁或其他明确协议。