Go语言WaitGroup在Wait()期间调用Add()是否安全？最佳实践是什么？

假设我们有两个嵌套的goroutine，为避免goroutine泄漏，使用WaitGroup来同步，代码示例如下：

func A(wg *sync.WaitGroup) {
    defer wg.Done()
    // 执行业务逻辑
}

func B(wg *sync.WaitGroup) {
    defer wg.Done()
    wg.Add(1)  // 为A()的goroutine计数
    go A(wg)
    // 执行业务逻辑
}

func main() {
    wg := &sync.WaitGroup{}
    wg.Add(1)  // 为B()的goroutine计数
    go B(wg)
    // 执行业务逻辑
    wg.Wait()
}

这段代码能正常运行，但存在一种可能：main()中的wg.Wait()先执行，之后B()里的wg.Add(1)才运行。乍看像是有竞态条件，但实际上并未违反WaitGroup的规则——规则要求“当计数器为0时，正增量的Add()调用必须在Wait()之前执行”，而此时wg.Add(1)执行时计数器值为1，满足安全条件。

核心问题 #

1. 当一个goroutine因调用Wait()阻塞时，另一个goroutine调用Add()是否安全？
2. 如果不安全，最佳实践是什么？另外，为每个函数单独用WaitGroup会导致代码混乱，有没有更优的方案？

一、Wait()阻塞时调用Add()的安全性 #

根据Go官方对sync.WaitGroup的规范：

只要计数器的值大于0，在任意goroutine中调用Add()都是安全的。只有当计数器为0时，后续的Add()必须在Wait()之前执行，否则会触发panic。

回到示例代码，main()先调用wg.Add(1)启动B的goroutine，此时计数器值为1。哪怕main()先进入Wait()阻塞，B的goroutine调用wg.Add(1)时计数器仍然是1（因为B的Done()还没执行），所以这个操作是完全安全的，不会引发竞态条件或panic。

二、最佳实践 #

虽然上述代码安全，但子goroutine内调用Add()的写法不够直观，后续维护时容易误改计数器逻辑。更清晰、容错性更高的写法是在启动子goroutine之前调用Add()，让Add()和goroutine启动操作在同一个goroutine内完成，避免跨goroutine的计数器操作带来的误解：

func A(wg *sync.WaitGroup) {
    defer wg.Done()
    // 执行业务逻辑
}

func B(wg *sync.WaitGroup) {
    defer wg.Done()
    // 先调用Add()，再启动子goroutine，操作顺序清晰
    wg.Add(1)
    go A(wg)
    // 执行业务逻辑
}

func main() {
    wg := &sync.WaitGroup{}
    wg.Add(1)
    go B(wg)
    // 执行业务逻辑
    wg.Wait()
}

针对嵌套goroutine的场景，还有这些更通用的最佳实践：

• 复用WaitGroup优先：无需为每个嵌套层级单独创建WaitGroup，复用同一个实例即可，但必须严格遵循“先Add再启动goroutine”的原则，确保计数器操作顺序一目了然。
• 封装计数器管理：如果嵌套层次极深或子goroutine数量动态变化，可将WaitGroup的Add()操作统一放到上层调用逻辑中，底层函数只负责调用Done()，减少底层函数对WaitGroup的直接操作，降低维护成本。
• 避免动态计数风险：如果子goroutine数量是动态生成的，务必在创建每个子goroutine前调用Add()，绝对不要在子goroutine内部执行Add()，哪怕当前场景安全，也会给后续代码修改埋下隐患。

内容的提问来源于stack exchange，提问作者David M