当前位置：首页 > 文章列表 > Golang > Go问答 > B.Loop 中修改循环外变量为什么会影响基准结果

B.Loop 中修改循环外变量为什么会影响基准结果

来源：17golang原创 2026-10-09 08:45:45 0浏览收藏

先说结论：testing.B.Loop 会控制迭代次数、自动处理循环前后的计时边界，并帮助阻止循环体被编译器整体优化掉，但它不会在每轮开始前复制或恢复循环外变量。只要循环体修改了外部切片、map、缓冲区或对象字段，下一轮就会从修改后的状态继续执行；一旦输入规模、容量、命中率或分支条件随轮次变化，最终的 ns/op 和 allocs/op 就成了多种工作量的平均值。

官方文档：https://pkg.go.dev/testing#B.Loop

要点速览

B.Loop 不负责业务状态隔离，循环外变量天然会跨迭代存活。
每轮新建对象和每轮复用对象都是合理目标，但两者测量语义不同。
重置动作是否计时要由生产场景决定，不能为了数字好看随意排除。

循环外变量为什么会让每轮工作量漂移

Go 官方对 B.Loop 的要求很明确：循环的每次迭代应当做相同的事情。这里的“相同”不只指调用了同一个函数，还包括输入状态、数据规模和资源条件应当具有同一语义。B.Loop 第一次被调用时重置计时器，返回 false 时停止计时；这些动作不会回滚你的切片长度、map 内容或对象字段。

B.Loop 循环外切片状态跨迭代保留并造成 append 工作量漂移的静态关系图 — 图1：循环外切片状态与 append 工作量漂移的静态关系图；不代表真实运行结果。

最典型的问题是把目标切片声明在循环外，然后在循环中持续 append：

func BenchmarkAppendDrift(b *testing.B) {
    chunk := make([]byte, 128)
    dst := make([]byte, 0, 1024)

    for b.Loop() {
        // 错误点：dst 的 len、cap 和底层数组会跨迭代保留并持续变化。
        dst = append(dst, chunk...)
    }
}

前几轮可能直接写入预留容量，某些轮次会触发扩容和复制，后续数据又会继续增长。这不仅让每轮工作量不一致，还可能让基准占用大量内存。类似的漂移还包括：循环外 map 从插入新键逐渐变成更新旧键；缓存从冷启动逐渐变成高命中；解码器、压缩器或 bytes.Buffer 复用后保留了更大的容量。

先决定要测新建成本还是复用成本

修复方法不是机械地把所有变量移进循环，而是先写清楚目标：生产代码每次都会创建新对象，还是会重置并复用同一个对象？这两种基准都可以正确，但名称、初始化位置和指标解释必须一致。

B.Loop 中每轮新建状态与重置复用状态两种基准语义的静态比较图 — 图2：新建状态与复用状态的两种基准语义；选择哪一种取决于生产代码的真实使用方式。

目标	每轮起点	应计入的成本	适合的命名
测完整新建流程	新对象、相同输入	分配、初始化和目标操作	Fresh、New、Cold
测对象复用稳态	同一对象已准备好	Reset 与目标操作，或明确排除准备动作	Reuse、Warm、Steady
只测核心算法	相同预置状态	核心算法本身	Core、Prepared

如果要测“每次创建一个新切片并追加数据”的完整成本，变量应在循环内创建：

func BenchmarkAppendFresh(b *testing.B) {
    chunk := make([]byte, 128)
    b.ReportAllocs()

    for b.Loop() {
        // 每轮都从相同容量和长度开始，分配与 append 都属于被测工作。
        dst := make([]byte, 0, 1024)
        dst = append(dst, chunk...)

        // B.Loop 会保持循环体中的赋值与调用结果存活，通常不必再写全局 sink。
        _ = dst
    }
}

如果生产代码使用对象池或长期复用缓冲区，则可以把对象放在循环外，但每轮必须恢复到同一逻辑状态：

func BenchmarkAppendReuse(b *testing.B) {
    chunk := make([]byte, 128)
    dst := make([]byte, 0, 1024)
    b.ReportAllocs()

    for b.Loop() {
        // 将长度恢复为零并保留容量，模拟生产中的缓冲区复用。
        dst = dst[:0]
        dst = append(dst, chunk...)
        _ = dst
    }
}

这里保留容量是设计目标，不是测试漏洞。真正的问题是没有说明“测的是复用”，或者重置后仍残留会改变下一轮行为的字段、索引、缓存和随机数状态。

重置动作要不要算进基准时间

如果线上每次处理请求前都会调用 Reset，通常应把它计入每次操作。如果重置只是为了给核心算法构造等价输入，而且线上输入准备发生在其他阶段，则可在循环内使用 StopTimer 和 StartTimer 排除准备时间。Go 官方的排序示例就是先暂停计时、重新填充数组，再开始计时执行排序。

func BenchmarkParsePrepared(b *testing.B) {
    buf := make([]byte, 4096)

    for b.Loop() {
        b.StopTimer()
        // 准备动作只用于恢复等价输入，不属于本基准要比较的解析成本。
        fillDeterministicInput(buf)
        b.StartTimer()

        // 每轮解析相同规模、相同结构的输入，避免状态漂移。
        parse(buf)
    }
}

不要为了降低 ns/op 就把真实请求路径中的必要动作移出计时区间。判断标准只有一个：被排除的工作，在你要回答的性能问题中是否真的发生在计时边界之外。对于很小的操作，频繁启停计时器还会延长整个测试过程，因此最好分别提供“完整路径”和“核心操作”两个命名清楚的基准。

循环外计数器并非一定错误

“修改循环外变量”不是一条绝对禁令。固定成本的计数器、自定义指标累加器，或者用于记录总字节数的变量，可以合法地跨迭代变化。关键是它的变化不能反过来改变下一轮输入或控制流。

func BenchmarkEncode(b *testing.B) {
    input := fixedInput()
    var totalBytes int64

    for b.Loop() {
        // 累加结果用于循环结束后的自定义指标，不参与下一轮编码决策。
        out := encode(input)
        totalBytes += int64(len(out))
    }

    // B.Loop 返回 false 后 b.N 才是本次测量的总迭代数。
    b.ReportMetric(float64(totalBytes)/float64(b.N), "B/op")
}

如果计数器被用来改变分支、索引、数据大小或缓存键，那么它就从“只记录结果”变成了“修改下一轮工作负载”。此外，累加类型要能承受总迭代数，不能让溢出后的行为悄悄改变控制流。

怎样确认基准语义已经稳定

不要先盯着一次运行的快慢，而要先检查结构。循环开始前的外部对象有哪些可变字段？循环体修改了什么？下一轮是否能观察到这些修改？每轮的数据长度、命中率和分配条件是否等价？确认语义后，再用多次运行和分配统计观察波动。

# 只运行指定基准，避免普通测试干扰，并记录分配指标
go test -run='^$' -bench='BenchmarkAppend(Fresh|Reuse)$' -benchmem -count=10

# 固定 CPU 维度，减少不同调度配置给比较带来的额外变量
go test -run='^$' -bench='BenchmarkAppend(Fresh|Reuse)$' -benchmem -count=10 -cpu=1

比较时应看两件事：第一，多次结果是否在可接受范围内稳定；第二，两个基准的语义差异是否和分配指标、对象生命周期一致。Reuse 更快不代表它“修复了” Fresh，它可能只是回答了另一个问题。若要比较提交前后的变化，应在同一机器、同一 Go 版本、同一 CPU 配置下保存结果，再使用统计工具做配对比较。