17370845950

parallel table-driven 基准测试是用结构体切片定义多组参数组合，并通过 b.RunParallel 在多个 goroutine 中并发执行每组测试，以高效评估函数在不同负载和数据特征下的性能表现。

什么是 parallel table-driven 基准测试

Go 的 testing.B 支持通过 b.RunParallel 并行执行基准测试逻辑，而 table-driven 是指用结构体切片定义多组输入、期望、配置等测试数据。两者结合，就是用表格组织不同参数组合，再让每组数据在多个 goroutine 中并发压测，从而高效评估函数在各种负载和数据特征下的性能表现。

基础写法：定义测试表 + 并行运行

核心是把「测试用例」抽象成结构体，每个用例包含输入数据、预期行为（可选）、配置项；然后在 b.Run 中遍历表格，并对每个用例调用 b.RunParallel 启动并行 worker。

• 用 struct{ name, input, size int } 定义测试维度（如不同数据规模、算法变体）
• 每个 b.Run 子基准对应一个场景，内部用 b.RunParallel(func(pb *testing.PB) { ... }) 驱动并发迭代
• pb.Next() 控制每个 goroutine 的工作节奏，避免手动计数出错

组合数据：用嵌套循环或笛卡尔积生成用例

当需要覆盖「算法类型 × 数据结构 × 并发度 × 输入大小」等多维组合时，不要手写几十个 struct 字面量。可用两层循环或辅助函数自动生成：

• 外层遍历算法标识（如 "map", "sync.Map", "shard-map"）
• 内层遍历数据规模（如 []int{1e3, 1e4, 1e5}）和并发 worker 数（[]int{4, 8, 16}）
• 每个组合构造唯一 name（如 fmt.Sprintf("%s-%d-%d", algo, size, workers)），便于结果识别

协程敏感场景：注意共享状态与同步开销

并行基准容易掩盖真实瓶颈——比如多个 goroutine 竞争同一 mutex、频繁 GC、或 channel 阻塞。要真实反映协程友好性：

• 避免在 b.RunParallel 内部创建全局 map/slice；应为每个 worker 分配独立局部变量
• 若测试含锁操作，确保锁粒度合理；可对比加锁 vs 无锁版本的吞吐差异
• 用 runtime.GC() 和 runtime.ReadMemStats() 在前后采样内存，判断是否因协程调度或逃逸导致额外开销

运行与观察：关键命令与指标

使用标准 go test 命令，配合参数获取有效数据：

• go test -bench=. -benchmem -count=3 -cpu=4,8,12：在不同 GOMAXPROCS 下跑 3 轮，看扩展性
• 关注 BenchmarkXXX-12 1000000 1200 ns/op 80 B/op 2 allocs/op 中的 ns/op（越低越好）、allocs/op（分配次数，影响 GC 压力）
• 用 go tool pprof 分析 CPU 和 goroutine trace，确认是否真正并行而非线程阻塞