当前位置：首页 > 文章列表 > Golang > Go教程 > 用 B.Loop 正确排除一次性初始化开销

用 B.Loop 正确排除一次性初始化开销

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

我在给一段哈希代码补基准测试时，最容易先写出的是 for i := 0; i 。这段写法本身没有错，但只要每轮测量前还要准备输入、分配缓冲区或建立对象，初始化成本就可能和被测操作混在一起。Go 1.24 引入的 testing.B.Loop 给了更清晰的边界：把一次性准备放在第一次 b.Loop() 之前，循环体只保留真正想测的调用，循环结束后的清理也不计入结果。

要点速览

B.Loop 需要 Go 1.24 及以上工具链，写法必须是 for b.Loop() { ... }。
循环第一次进入时会重置计时器，循环返回 false 时会停止计时；初始化和清理应放在循环外。
不要在同一个基准里同时使用 b.Loop 和 b.N，需要并行场景时仍使用 RunParallel。

先把基准测试拆成三块

一个可读的基准通常有三个区域：准备输入、执行被测操作、释放资源。下面用计算 SHA-256 作为小项目的目标，只是为了让“初始化一次、计算多次”的关系足够明显。输入构造、填充随机数据等动作属于准备区，不应该因为基准框架为了达到稳定测量时长而被反复计数。

Go testing.B.Loop 将一次性输入准备、循环体和循环后清理分隔开的结构说明图 — 图1：结构说明图，展示准备区、B.Loop 测量区与清理区的静态边界，不是运行截图或实测证据。

把一次性输入放到 B.Loop 之前

核心写法是让 input := buildInput() 位于循环之前，并让 hashBlock(input) 成为循环内唯一的主要工作。B.Loop 首次调用会重置计时器，因此准备输入不会进入计时；它返回 false 后计时器停止，循环后的资源回收也不会污染结果。

package loopbench

import (
    "crypto/sha256"
    "testing"
)

func buildInput() []byte {
    // 这份输入只创建一次，避免把准备成本算进每次哈希。
    data := make([]byte, 128

这里的 _ = hashBlock(input) 不是多余写法。官方文档说明，B.Loop 循环体内的函数调用参数、返回值和赋值变量会被保持存活，降低编译器把无副作用调用完全优化掉的风险。它解决的是“基准循环被优化”的边界，不代表所有外部副作用都能自动变成可靠测量；如果被测函数本身依赖时钟、网络或共享状态，仍要单独设计隔离方案。

不要把 b.N、清理和并行模型混在一起

旧式 b.N 基准依赖测试框架多次调用基准函数，再调整 N 以获得足够长的测量时间，所以昂贵准备可能随调用重复发生。迁移到 B.Loop 时，应删除显式的 b.N 循环，而不是在外面再套一层。两种写法也不要放在同一个基准函数里，否则读者很难判断计时边界。

代码位置	适合放什么	是否计入目标耗时
第一次 B.Loop 之前	输入构造、解析固定配置、创建只读对象	不计入
for b.Loop() 内	一次要比较的函数调用或算法操作	计入
循环返回 false 之后	关闭文件、释放连接、清理临时资源	不计入

B.Loop 循环体中的输入参数、哈希返回值和计时边界关系说明图 — 图2：关系说明图，强调输入参数、函数调用、返回值和计时器边界之间的静态关系，不是终端截图。

用 go test 检查测量对象

把代码放进以 _test.go 结尾的文件后，可以用下面的命令只跑目标基准，并同时输出分配统计：

# 只运行目标基准，并显示每次操作的分配信息
go test -run '^$' -bench '^BenchmarkHashPreparedInput$' -benchmem ./...

如果项目仍需支持 Go 1.23 或更早工具链，不能直接调用 B.Loop；可以保留旧式 b.N 写法，并用 b.ResetTimer() 把准备阶段排除在计时外。升级到 Go 1.24 后再迁移时，优先检查三点：循环条件是否精确写成 b.Loop()、循环体是否真的只包含被测操作、旧的 b.N 是否已经移除。