Go语言如何测试并发代码_并发测试思路与方法
能，但默认不保证并发行为可复现或可断言；go test 串行执行测试函数，手动启 goroutine 需自行处理同步、超时与断言。
Go 语言 go test 能直接测并发逻辑吗？
能，但默认不保证并发行为可复现或可断言。Go 的测试框架本身是单线程执行的，go test 启动的每个测试函数仍是串行调用；你手动起 goroutine 属于运行时行为，测试框架不会帮你同步、拦截或超时控制——这得自己加。
常见误操作：写个 for i := 0; i 就跑 go test，结果偶尔失败、偶尔通过，根本没法定位问题。
- 必须显式等待所有 goroutine 完成（用
sync.WaitGroup或chan） - 必须处理竞态（加
-race编译标志，否则大概率漏掉数据竞争） - 避免用
time.Sleep做“等待”，它不可靠、拖慢测试、掩盖同步缺陷
如何写可验证的并发测试？以 sync.Mutex 计数器为例
目标：验证一个带锁的计数器在并发调用下结果准确。关键不是“有没有 panic”，而是“最终值是否符合预期”。
func TestCounter_Concurrent(t *testing.T) {
var c Counter
var wg sync.WaitGroup
const workers = 10
const opsPerWorker = 100
for i := 0; i < workers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for j := 0; j < opsPerWorker; j++ {
c.Inc()
}
}()
}
wg.Wait()
if got, want := c.Value(), int64(workers*opsPerWorker); got != want {
t.Errorf("Counter.Value() = %d, want %d", got, want)
}}
注意点：
-
sync.WaitGroup必须在 goroutine 外调用Add()，且defer wg.Done()要在 goroutine 内部 —— 否则可能提前 Wait 返回 - 被测对象（如
c）不能是局部变量逃逸到多个 goroutine 之外又没同步保护；这里Counter内部用了Mutex，所以安全 - 测试前可加
t.Parallel()，但仅当该测试不依赖共享状态（比如不操作全局 map / 文件 / 环境变量）
怎么发现隐藏的竞态？必须开 -race
Go 的竞态检测器（race detector）不是静态分析，而是在运行时插桩内存访问。不开它，99% 的 data race 都不会报错，只会导致随机错误值、panic 或静默失败。
- 永远用
go test -race运行并发测试，CI 中也应强制启用 -
-race会显著降低性能（5–10 倍），所以只在测试时开，不要在生产构建中启用 - 一旦触发 race report，输出里会明确标出两个冲突的 goroutine 栈，例如：
Previous write at ... by goroutine 7:Current read at ... by goroutine 8:
典型误判场景：对只读全局变量（如 const 或初始化后不再修改的 var config = struct{...}{...}）做并发读，-race 不会报 —— 这是合法的，不用加锁。
测试超时与死锁：用 t.Cleanup 和 context.WithTimeout
并发测试最怕卡死。别依赖测试主流程超时（go test -timeout 是整包级的），应在测试内部主动设限。
func TestConcurrentService_Timeout(t *testing.T) {
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
t.Cleanup(cancel) // 确保无论成功失败都释放资源
s := NewService()
errCh := make(chan error, 1)
go func() {
errCh <- s.Run(ctx) // Run 应监听 ctx.Done()
}()
select {
case err := <-errCh:
if err != nil && !errors.Is(err, context.DeadlineExceeded) {
t.Fatal(err)
}
case <-time.After(3 * time.Second):
t.Fatal("service did not exit within timeout")
}}
要点：
-
t.Cleanup()比defer更可靠：即使t.Fatal()提前退出，它也会执行 - 不要让 goroutine 直接操作
t（如t.Log()），因为t不是并发安全的；改用 channel 或 mutex 控制输出 - 用
context.WithTimeout而非time.After做取消信号 —— 前者可被主动 cancel，后者只能等时间到
真正难的是模拟真实并发边界条件：比如网络延迟抖动、锁争抢高峰、channel 缓冲区满。这些没法靠单元测试全覆盖，得结合集成测试 + 日志埋点 + 生产指标反推。但至少，上面四步能守住基础正确性底线。
