Golang测试中的并发同步原语正确性验证

sync.waitgroup 忘记 add 就调 done 会必现 panic: sync: negative waitgroup counter；必须在 goroutine 启动前调用 wg.add(1)，不可在内部或延迟调用。

Go test 中 sync.WaitGroup 忘记 Add 导致 panic

测试里用 sync.WaitGroup 等待 goroutine 完成，但没调 WaitGroup.Add 就直接 Done，会触发 panic: sync: negative WaitGroup counter。这不是偶发，是必现——因为 Done 本质是原子减一，初始值为 0，减一就崩。

• 必须在 go 语句前调用 wg.Add(1)，不能放在 goroutine 内部（除非你确定它一定会执行）
• 如果启动 N 个 goroutine，Add 要在循环外一次性加 N，或在循环内每次加 1；别用 wg.Add(len(jobs)) 后再遍历启动，否则存在竞态：goroutine 可能先执行 Done，而 Add 还没完成
• 测试中更推荐显式计数：比如 for i := 0; i

用 testing.T.Parallel() 时误共享 Struct 字段

多个并行测试子例程（subtest）共用同一个 struct 实例的字段，比如 type fixture struct { mu sync.RWMutex; data map[String]int }，不加锁直接读写 data，会触发 data race 报告，甚至测试结果错乱。

• t.Parallel() 不自动隔离变量作用域，只控制执行调度；所有闭包捕获的外部变量仍是共享的
• 每个并行 subtest 应该拥有独立的 fixture 实例，或确保对共享状态的操作被 mu.Lock() / RWMutex.RLock() 保护
• 常见错误：在 for _, tc := range tests 循环里启动 func(t *testing.T) { t.Parallel(); ... use(tc) ... }，但 tc 是循环变量地址，所有 goroutine 实际读的是最后一个 tc 的值——必须用局部副本：tc := tc

time.Sleep 在并发测试里不是同步手段

写测试时用 time.Sleep(10 * time.Millisecond) 等待 goroutine 执行完，看似“跑过了”，实则不可靠：CPU 负载高时 sleep 不够，CI 环境可能直接跳过断言；低负载时又拖慢测试速度。

• time.Sleep 是时间等待，不是事件等待；它无法保证某段逻辑已执行、某次 channel 发送已完成、某个 mutex 已释放
• 正确替代方案优先级：channel 接收 > sync.WaitGroup > sync/atomic 标志位 > 最后才考虑带超时的 time.AfterFunc 或 select + time.After
• 示例：不要 go doWork(); time.Sleep(5ms); assert.Equal(t, expected, globalVar)；改用 c := make(chan struct{}); go func() { doWork(); close(c) }();

测试 sync.Once 行为时忽略多 goroutine 初始化竞争

验证 sync.Once.Do 是否真的只执行一次，仅用单 goroutine 调用 once.Do(f) 并检查返回值，根本测不出并发安全特性。

立即学习“go语言免费学习笔记（深入）”；

• 必须显式启动多个 goroutine 同时调用 once.Do，再通过共享计数器（如 atomic.Int64）确认 f 仅被执行一次
• 注意：Do 返回后，不表示 f 已执行完毕——只是提交了执行请求；若需验证副作用（如写文件、改全局状态），得配合 channel 或 mutex 等同步原语确认 f 真的退出
• 容易漏掉的点：测试中用 var once sync.Once; once.Do(func(){ ... })，但没检查 f 内部是否 panic；一旦 panic，Once 会标记为已执行，后续调用直接返回，但行为不符合预期

并发测试里最麻烦的从来不是写多少 goroutine，而是怎么让它们“同时开始”又“可验证地结束”。sync.WaitGroup 和 channel 是基础，但初始化时机、变量捕获、panic 传播这些细节，稍不注意就让测试变成“看着绿，其实没测到”。