登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go问答

Go testing.AllocsPerRun 为什么会先预热一次再统计

来源:17golang原创

时间:2026-11-05 11:18:16 172浏览 收藏

我第一次用 testing.AllocsPerRun 看一段 Go 代码的分配次数时,最容易误读的地方就是“为什么函数明明只传了 100 次,却像是先多调用了一次”。这一次额外调用是设计好的 warm-up,不会被计入返回值的平均分配次数。

AllocsPerRun(runs, f) 的测量窗口从 warm-up 之后才开始:先执行一次 f,再读取分配计数起点,调用 f 共 runs 次,最后用增量除以 runs。官方地址:https://pkg.go.dev/testing#AllocsPerRun。

先记住这条主线:预热用来把首次调用带来的启动性分配放在测量窗口外;真正的结果是指定 runs 次调用产生的 Mallocs 增量平均值。

一次调用为什么不能直接代表稳定分配

很多函数第一次执行时会顺便完成只需做一次的准备工作,例如建立内部缓存、初始化某个惰性对象或触发运行时第一次访问。若直接从函数调用前开始读分配计数,第一次调用的特殊成本就会和常态调用混在一起。

AllocsPerRun 没有把这次首次调用当成样本。它先调用一次传入的 f,然后才记录测量起点。这样,读者看到的平均值更接近“已经进入稳定状态后,每次调用平均产生多少次分配”,而不是“从冷启动到第一次完成的总成本”。这也是标题中“先预热一次”的关键。

AllocsPerRun把预热调用放在Mallocs测量起点之前的原创静态结构说明图
图1:静态结构说明图,预热调用位于测量起点之前;统计窗口只连接指定 runs 次调用与最终的分配增量平均值。

预热调用和真正统计的边界在哪里

从实现关系看,可以把一次 AllocsPerRun 拆成四个对象:预热调用、起始 runtime.MemStats、指定次数的 f 调用,以及结束时的 runtime.MemStats。起点读数发生在 warm-up 之后,所以 warm-up 产生的 Mallocs 增量不会进入后面的差值。

这不表示 warm-up 没有影响。它改变了被测函数进入测量窗口时的状态;它只是没有被当成一次样本加进平均数。若 f 每次都分配一次,预热之后的每个样本仍会贡献一次;若只有第一次分配,warm-up 就会把这次一次性成本隔离出去。

实现还会在测量期间把 runtime.GOMAXPROCS 设为 1,并在返回前恢复原值。这个约束让分配计数窗口更可控,但也意味着它不是并发场景下的吞吐测试;正在执行并行测试时调用它也不属于合适的使用方式。

Mallocs 增量怎样变成返回值

测量逻辑可以写成一个很短的关系式:

平均分配次数 = (结束时 Mallocs - 起始时 Mallocs) / runs

这里的起始值和结束值都来自 runtime.MemStats 的 Mallocs 字段。AllocsPerRun 先得到指定次数调用期间的总增量,再做平均,而不是把每次调用单独记录后再做浮点平均。

f函数、Mallocs增量、整数除法与float64返回值之间关系的原创静态结构说明图
图2:静态关系说明图,输入函数和指定 runs 形成 Mallocs 增量,整数除法得到平均分配次数,API 再以 float64 类型返回。

文档特别说明,返回类型虽然是 float64,结果实际上总是整数值。原因是实现先进行整数除法,再把结果转换为 float64。因此看到 1、2 这样的结果时,不要把它理解成经过随机采样得到的近似小数。

用一个最小示例读取分配次数

下面的示例把 runs 写成 100,重点展示调用边界。它没有把某个输出数字当成所有机器都相同的事实;实际分配行为仍取决于函数实现、编译器优化和运行环境。

package allocs_test

import "testing"

var sink []byte

func measureAllocations() float64 {
    return testing.AllocsPerRun(100, func() {
        // 把结果交给包级变量,避免示例中的分配对象完全没有用途。
        sink = make([]byte, 128)
    })
}

这段代码的含义不是“总共调用 101 次就返回 101 次分配”,而是 warm-up 的一次调用不进入分母和分子;统计阶段才执行 100 次并计算这 100 次的平均分配次数。若需要比较两种写法,应让两次测量使用相同的 runs、相近的输入和相同的外部状态。

几个参数和边界不要混在一起

看到的现象正确理解
函数好像多执行了一次那是 warm-up,发生在测量起点之前,不计入平均结果
返回值是 float64API 类型如此,但实现按整数增量除以 runs,结果保持整数语义
runs 越大越准确runs 增大能让平均更有参考价值,但不会把一次性初始化成本重新纳入统计
想测并发分配吞吐AllocsPerRun 会把测量期间 GOMAXPROCS 设为 1,不应当作并发压测接口
想看耗时AllocsPerRun只回答分配次数,不替代 benchmark 的耗时指标

把这次误解压缩成一句判断

如果你只关心“稳定调用一次大约产生几次分配”,AllocsPerRun 的预热设计正好帮你排除冷启动干扰:第一次调用负责让函数进入可测状态,后续 runs 次才组成统计窗口。读返回值时,按 Mallocs 增量的整数平均来解释,而不要把 warm-up 误加进调用次数,也不要把它当成耗时或并发吞吐结果。

相关问题

预热调用会改变函数的全局状态吗?会,因为它就是一次真实的 f() 调用。若函数有外部副作用,应在闭包内部控制输入和状态,避免把不可重复的业务动作直接交给 AllocsPerRun。

为什么不把预热也算进平均值?因为它的目的就是隔离首次调用的特殊成本;实现把起始 MemStats 放在 warm-up 之后,统计窗口自然不会包含这次增量。

AllocsPerRun 能告诉我分配了多少字节吗?不能。它返回的是平均分配次数;分配字节数和耗时是另外的测量维度。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>