Golang并发测试技巧与实现解析

有志者，事竟成！如果你在学习Golang，那么本文《Golang并发测试实现方法详解》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

不是必须用 t.Parallel()，但不用它测试函数仍串行执行；t.Parallel() 仅允许与其他标记该方法的测试并发运行，需配合 -p 参数生效，且须避免状态竞争与 goroutine 中误调 t 方法。

并发测试必须用 t.Parallel() 吗？

不是必须，但不用它就不是真正的并发执行。Go 的测试框架默认串行运行每个 TestXxx 函数；t.Parallel() 仅表示“允许该测试与其他标记了 t.Parallel() 的测试并发运行”，前提是它们不共享状态或竞争资源。

• 多个测试函数都调用 t.Parallel()，Go 测试主程序才会并行调度它们（受 -p 参数控制）
• 单个测试函数内部想并发执行子任务（比如启动 10 个 goroutine 模拟请求），不需要 t.Parallel()，直接用 go 即可
• 误在有状态依赖的测试里加 t.Parallel()，极易触发 data race —— go test -race 会立刻报出类似 Read at 0x00c000012340 by goroutine 7 的错误

如何安全地在单个测试中启动多个 goroutine？

关键不是“能不能开 goroutine”，而是“怎么等它们结束 + 怎么捕获 panic + 怎么避免共享变量竞争”。推荐组合使用 sync.WaitGroup 和 defer recover()（如需捕获 panic）。

func TestConcurrentHTTPCalls(t *testing.T) {
    var wg sync.WaitGroup
    errors := make(chan error, 10)
for i := 0; i < 5; i++ {
    wg.Add(1)
    go func(id int) {
        defer wg.Done()
        // 注意：不要直接引用循环变量 i，要传参
        resp, err := http.Get("https://httpbin.org/delay/1")
        if err != nil {
            errors <- err
            return
        }
        resp.Body.Close()
    }(i)
}

go func() {
    wg.Wait()
    close(errors)
}()

// 收集所有错误（最多等 3 秒）
timeout := time.After(3 * time.Second)
for {
    select {
    case err, ok := <-errors:
        if !ok {
            return
        }
        if err != nil {
            t.Errorf("request %d failed: %v", i, err) // 注意：这里 i 已失效，应改用闭包传入的 id
        }
    case <-timeout:
        t.Fatal("timeout waiting for requests")
    }
}
}

go test -p=4 和 t.Parallel() 是什么关系？

-p=N 控制测试进程级并行度（即最多同时跑 N 个 TestXxx 函数），而 t.Parallel() 是告诉测试驱动：“这个函数可以被放入并行池”。两者配合才生效。

• 没调用 t.Parallel()：即使 -p=10，该测试也永远排在串行队列里
• 调用了 t.Parallel() 但 -p=1：所有标记的测试仍会串行执行（因为只允许 1 个活跃测试）
• 典型配置：go test -p=8 -race —— 启用竞态检测的同时，最多并行跑 8 个测试函数
• 注意：-p 值不能超过 GOMAXPROCS，默认等于 CPU 核心数，但可被 GOMAXPROCS 环境变量覆盖

为什么并发测试经常 panic 却没输出具体位置？

因为 goroutine 中的 panic 不会自动传播到主测试 goroutine，会被静默吞掉，除非显式 recover 或使用 t.Log/t.Error 在主 goroutine 汇总。

• 最简修复：在每个 goroutine 内部加 defer func() { if r := recover(); r != nil { t.Errorf("panic in goroutine: %v", r) } }()
• 更稳妥做法：把错误通过 channel 发回主 goroutine，在那里统一 t.Error（如上例）
• 别依赖 log.Fatal 或 os.Exit —— 它们会直接终止整个测试进程，跳过其他测试和清理逻辑
• 如果用了 t.Parallel()，还要注意：不能在 goroutine 中调用 t.Helper() 或修改 t 的状态（如 t.Skip()），会 panic 报 test is not running

并发测试真正难的不是启 goroutine，是厘清“谁负责等待、谁负责错误收集、谁负责超时控制”——这三个角色一旦混在一起，失败时根本看不出是卡死、panic 被吞，还是 channel 漏读。

以上就是《Golang并发测试技巧与实现解析》的详细内容，更多关于的资料请关注golang学习网公众号！