go test -bench 不能直接测 goroutine 并发行为，因其 Benchmark 函数单线程执行、不等待子协程完成、不控制并发度且不暴露调度维度；需用 RunParallel 或手动管理 goroutine 生命周期。
为什么 go test -bench 不能直接测 goroutine 并发行为
因为 testing.B 的 Benchmark 函数是单线程串行执行的，即使你在里面启动 100 个 goroutine，bench 默认只统计主协程的耗时，且不保证所有 goroutine 已完成。结果往往偏低、不可靠，甚至因竞态或提前退出而漏统计。
- 典型错误：在
BenchmarkXxx里直接go f()后就返回 →bench结束时 goroutine 可能还在跑 -
runtime.GOMAXPROCS和实际 OS 线程调度会影响并发吞吐，但-bench不暴露这些维度 - 没有内置机制控制“每轮压测启动多少 goroutine”或“持续运行多久”，无法模拟真实异步任务流
用 testing.B.RunParallel 模拟多 goroutine 基准压测
RunParallel 是标准库中唯一为并发基准设计的接口，它会启动指定数量的 goroutine 并等待全部完成，同时自动分摊 b.N 次迭代。适合测试无状态、可并行的任务（如编解码、计算密集型）。
- 它内部使用
sync.WaitGroup+ 闭包分片，确保所有 goroutine 执行完才计时 - 参数
f接收一个func(*testing.PB)，其中pb.Next()控制每个 goroutine 的工作量分配 - 注意：不能用于依赖共享状态且未加锁的操作，否则引发竞态（
go test -race可捕获）
func BenchmarkJSONMarshalParallel(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
data := map[string]interface{}{"id": 123, "name": "test"}
for pb.Next() {
_, _ = json.Marshal(data)
}
})
}手动控制 goroutine 数量与生命周期的自定义 Benchmark
当你要测带 channel、worker pool、任务队列等真实异步模型时，必须脱离 RunParallel，自己管理 goroutine 启动、信号同步和计时范围。核心是把「启动全部 worker」和「发送全部任务」包裹在 b.ResetTimer() 之前，把「等待全部完成」放在之后。
- 用
sync.WaitGroup计数活跃 goroutine，避免提前结束 - 用
time.AfterFunc或context.WithTimeout防止死锁（尤其 channel 阻塞场景） -
b.ReportAllocs()和b.SetBytes()仍有效，可用于分析内存/吞吐
func BenchmarkWorkerPool(b *testing.B) {
const workers = 8
const tasks = 1000
b.ResetTimer()
b.ReportAllocs()
// 启动 worker pool
jobs := make(chan int, tasks)
results := make(chan int, tasks)
var wg sync.WaitGroup
for w := 0; w < workers; w++ {
wg.Add(1)
go func() {
defer wg.Done()
for range jobs {
// 模拟异步处理：比如 HTTP 调用、DB 查询
results <- 42
}
}()
}
// 发送任务
for i := 0; i < tasks; i++ {
jobs <- i
}
close(jobs)
// 等待全部结果
for i := 0; i < tasks; i++ {
<-results
}
// 等待所有 worker 退出
wg.Wait()}
立即学习“go语言免费学习笔记（深入）”；
容易被忽略的 goroutine 基准陷阱
很多人以为只要用了 goroutine 就算“异步压测”，但实际指标可能完全失真：
- 没调
b.ResetTimer()→ 初始化 channel、worker、预热逻辑被计入耗时 - 用
time.Sleep替代真实异步操作 → 测试的是调度器休眠开销，不是业务延迟 - 忘记关闭 channel 或漏读
results→bench卡住或 panic - 在 goroutine 里调
b.Fatal→ 导致 panic 且无法捕获，测试静默失败 - 未设置
GOMAXPROCS→ 默认可能只有 1 个 P，无法体现多核并发收益
真正难的不是起 goroutine，而是让 benchmark 精确反映你关心的异步路径：是首字节延迟？是吞吐饱和点？还是长连接复用率？这些必须靠你手动建模，标准 go test -bench 不会替你猜。
