sync.WaitGroup 计数器竞态与 GMP 调度时序缺陷

sync.WaitGroup 是 Go 处理并发任务汇聚（Fan-in）最常用的同步原语。其接口设计虽然精简（Add、Done、Wait），但其正确性强依赖于严格的调用时序。若调用位置发生偏差，看似逻辑闭环的代码便会退化为概率性失效的竞态条件（Race Condition）。此类缺陷通常无法被常规单元测试稳定捕获，但在高并发或调度延迟波动的生产环境中会引发严重的逻辑截断。

1. 缺陷模式：协程内增量导致的非确定性执行

在批量派发异步任务时，常见的反模式是将 Add 逻辑移入异步闭包内部：

func CheckHealth() {
    var wg sync.WaitGroup

    for i := 0; i < 10; i++ {
        go func(nodeID int) {
            // 缺陷根源：在派生的子协程内部递增计数器
            wg.Add(1)
            defer wg.Done()
            fmt.Printf("Node %d checked\n", nodeID)
        }(i)
    }

    // 主协程等待汇聚
    wg.Wait()
    fmt.Println("All nodes checked. Proceeding...")
}

运行上述代码时，输出结果通常呈现出非确定性：可能完整执行 10 次检测，也可能仅执行一部分，甚至主协程直接穿透 wg.Wait() 退出，未执行任何一次探活逻辑。

2. 调度机制剖析：主协程执行与 G 调度的微秒级竞速

这种“零等待”现象的根源在于 Go 运行时的 GMP 调度机制与指令执行时序的冲突。

1. go 关键字的非同步特性：执行 go func() 并不代表该协程立即获得 CPU 时间片执行。运行时的底层行为仅是完成 runtime.newproc 分配，构建一个新的 Goroutine（G），并将其压入当前 Processor（P）的本地可运行队列（runq）等待调度。
2. 时钟竞争与提前穿透：主协程在连续执行 10 次循环并完成 G 的入队后，极快地执行到 wg.Wait()。此时，如果本地运行队列中的子协程尚未被 P 实际调度执行，sync.WaitGroup 内部的原子计数器（state）依然为 0。
3. 阻塞条件失效：根据 wg.Wait() 的实现，当检测到内部 counter 值为 0 时，无需调用 runtime.gopark 挂起当前协程，而是直接返回。主函数随即结束生命周期，调用栈被销毁，尚未被调度的子协程被动流产，导致业务逻辑未按预期完成。

3. 正确实现：主流程先验计数

修复方案的核心是保证计数器递增在时序上绝对先于 Wait 的条件评估，即由派发任务的主协程负责先验累加：

func CheckHealth() {
    var wg sync.WaitGroup

    for i := 0; i < 10; i++ {
        // 在派生协程前显式递增计数器，或在循环外预先执行 wg.Add(10)
        wg.Add(1)
        go func(nodeID int) {
            defer wg.Done()
            fmt.Printf("Node %d checked\n", nodeID)
        }(i)
    }

    wg.Wait()
    fmt.Println("All nodes checked. Proceeding...")
}

• 时序保障：在任何一个 go 语句返回前，主协程已原子性地累加了计数器。哪怕子协程因调度延迟尚未开始运行，主协程到达 wg.Wait() 时也能感知到非零状态并正确挂起等待。
• 批量优化：若任务总数在运行前已明确，更优的做法是在循环外部单次调用 wg.Add(10)，减少循环内原子操作带来的额外开销。

4. 关键准则

• 计数前置：wg.Add() 的调用生命周期必须绑定在任务派发方（创建者协程），严禁委托给任务执行方（受派发协程）。
• 动态递增的禁忌：若并发场景下的任务量是动态产生的，必须确保每一次 Add 操作发生时，对应的 Wait 尚未开始评估；在计数器清零且 Wait 已经返回后再次调用 Add，将直接触发运行时 Panic。