Go并发等待机制详解

sync.WaitGroup 是等待多个 goroutine 完成的最常用且可靠方式，需在启动前调用 Add()、goroutine 内用 defer Done()、主协程调用 Wait() 阻塞等待。

用 sync.WaitGroup 等待多个 goroutine 完成是最常用且可靠的方式

Go 没有内置的“等待所有 goroutine 结束”语法，sync.WaitGroup 是标准库提供的轻量级同步原语，专为这类场景设计。它通过计数器 + 阻塞等待实现协作式同步，不依赖 channel 或 sleep 轮询。

关键点在于：必须在启动 goroutine 之前调用 Add()，且每个 goroutine 内部必须调用 Done()；Wait() 会阻塞直到计数归零。

• Add(1) 必须在 goroutine 启动前调用，否则可能因竞态导致计数未生效
• 不要在 goroutine 外部调用 Done()，也不要用 defer Done() 在非 goroutine 函数中——Done() 只应在对应 goroutine 内执行
• 计数器不可为负，多次调用 Done() 会 panic，务必确保每个 Add() 都有且仅有一个匹配的 Done()

package main
import (
"fmt"
"sync"
"time"
)
func main() {
var wg sync.WaitGroup
urls := []string{"https://a.com", "https://b.com", "https://c.com"}
for _, url := range urls {
    wg.Add(1) // 注意：这里在 goroutine 外、启动前调用
    go func(u string) {
        defer wg.Done() // 在 goroutine 内调用
        fmt.Printf("Fetching %s...\n", u)
        time.Sleep(500 * time.Millisecond)
        fmt.Printf("Done: %s\n", u)
    }(url)
}

wg.Wait() // 主 goroutine 阻塞等待全部完成
fmt.Println("All done.")
}

为什么不用 channel 配合 for range 等待？

用 channel 收集完成信号（如 done := make(chan struct{}, N)）也能工作，但属于“手动模拟 WaitGroup”，增加了复杂度和出错风险。

常见问题包括：

• 缓冲区大小设错（比如 make(chan struct{}, 2) 却发 3 个信号 → 第三个写操作阻塞）
• 忘记关闭 channel，导致 for range 永远不退出
• goroutine panic 后未发送信号，主 goroutine 永久等待（WaitGroup 同样会卡住，但至少不会因 channel 操作 panic）
• 无法复用：每次都要新建 channel 和循环逻辑，而 sync.WaitGroup 可重置（WaitGroup{} 重新赋值）或直接新建

除非你同时需要返回结果或错误（这时用带类型的 channel 更自然），否则纯等待完成，sync.WaitGroup 更简洁、安全、符合 Go 的惯用法。

WaitGroup 的底层行为与注意事项

sync.WaitGroup 内部使用原子操作维护计数器，并在 Wait() 时进入休眠状态，由 runtime 唤醒。它不是基于 mutex 的忙等，性能开销极低。

• 不能拷贝：WaitGroup 包含互斥锁字段，复制会导致 panic —— 总是传指针或作为包级/局部变量直接使用
• 不能重用后未重置：如果重复使用同一变量，需确保上次 Wait() 已返回，且不再有 goroutine 调用 Done()；否则可能读到旧计数或引发 panic
• 没有超时机制：Wait() 会一直等，生产代码中建议结合 context.WithTimeout 控制整体等待时限（例如启动 goroutine 时传入 context）

若需超时等待，典型做法是启动一个 timer goroutine 或用 select + time.After：

done := make(chan struct{})
go func() {
    wg.Wait()
    close(done)
}()
select {
case <-done:
fmt.Println("All finished")
case <-time.After(3 * time.Second):
fmt.Println("Timeout!")
}

当 goroutine 可能 panic 时，如何避免 WaitGroup 卡死？

WaitGroup 本身不处理 panic，如果某个 goroutine panic 且没调用 Done()，Wait() 就永远阻塞。这不是 bug，而是设计使然：它假设你控制着 goroutine 的生命周期。

真正可靠的解法是保证 Done() 总被执行：

• 用 defer wg.Done() —— 这是最简单有效的方案，defer 在 panic 后仍会执行
• 避免在 defer 前做可能 panic 的操作（比如 defer 前解引用 nil 指针）
• 若逻辑复杂，可包裹 recover：

go func() {
    defer wg.Done()
    defer func() {
        if r := recover(); r != nil {
            fmt.Printf("Recovered in goroutine: %v\n", r)
        }
    }()
    // 可能 panic 的代码
}()

注意：recover 只对当前 goroutine 有效，不影响其他 goroutine，也不会让主流程继续执行失败逻辑 —— 它只是防止 Done() 被跳过。

最常被忽略的一点：很多人把 wg.Add() 放在 goroutine 内部，以为“自己加自己减”，结果因调度延迟导致 Wait() 先执行、计数为 0 直接返回，后续 goroutine 还没开始就结束了。务必记住——Add() 是“预告”，必须提前告知要等几个任务。