小对象分配使用专用快速路径

Go 的“小对象分配使用专用快速路径”不是一个需要手工调用的 API，而是编译器与 runtime 协作完成的内部优化：当对象确实需要动态分配时，编译器会根据大小和指针属性选择更具体的分配入口；运行时再从对应的 size class、tiny block 或通用路径取得内存。

官方资料：https://go.dev/blog/size-specialized-allocations

真正需要记住的是：先让编译器决定对象是否逃逸，再让 runtime 按大小和是否含指针分流；Go 1.27 只优化部分小对象分配的调用成本，并不会让每个小对象都自动变成栈上值。

这个快速路径解决什么

如果一个局部值的地址被返回、放进长期存活的数据结构，或因为其他原因必须动态分配，Go 编译器会把它交给 runtime。官方说明里，这类堆分配最终会进入 mallocgc，调用时最重要的两个信息是请求大小和对象是否含有指针。

旧的直觉是“调用一次 mallocgc，再让它自己判断所有条件”。Go 1.27 增加了按 span class 特化的分配例程。对编译器能够确定大小的对象，它可以直接生成更具体的调用；对于动态长度的切片等场景，仍然会保留通用入口，由 mallocgc 决定是否转到专用例程。

先分清 tiny、small 和 large

“小对象”在工程讨论里容易被混成一个概念，但 runtime 至少有三种观察角度：

Go 1.27 的 size-specialized 例程主要针对不超过 80 字节的部分分配。官方文章把 1–8、9–16、17–24、25–32、33–48、49–64、65–80 字节分别列为小对象 size class；实际返回的槽位大小可能大于请求值，所以 17 字节对象可能拿到 24 字节槽。

tiny allocator 还要单独理解：runtime 的 mcache 是 per-P 的小对象缓存，其中保存当前 tiny block 的地址和偏移量。只有无指针对象才能共享 tiny block，这样垃圾回收器不需要在 block 内追踪每个子对象的指针关系。

用最小代码观察分配入口

先看一个会把地址返回给调用方的结构体。它只是制造一个可被逃逸分析关注的候选，并不直接保证最终使用哪一种 runtime 路径：

package sample

type pair struct {
	left  uint32
	right uint32
}

func newPair() *pair {
	// 返回指针让编译器判断 pair 是否需要逃逸到堆。
	return &pair{left: 1, right: 2}
}

func consume() uint32 {
	// 只在当前函数内使用值，编译器可能选择不做堆分配。
	p := pair{left: 3, right: 4}
	return p.left + p.right
}

用编译器信息观察“是否逃逸”，比根据结构体只有 8 字节就断言“必走 tiny”更可靠：

# 查看编译器的逃逸判断和内联提示，不把输出当成固定的运行时契约
go test -gcflags='-m=2' ./...

即使 newPair 发生了堆分配，也还要看对象是否含指针、实际 size class 和当前构建版本。tiny、small、size-specialized 是连续的内部分流，不是应用代码可以直接选择的三个开关。

Go 1.27 怎样调用专用例程

Go 1.27 的优化重点是减少一部分小分配的入口成本。官方发布说明给出的范围是小于 80 字节的部分分配，单次分配成本最高可降低约 30%，但对整体分配密集程序的预期提升约为 1%；二进制体积大约增加 60 KB。

实现上，runtime 为不同 span class 准备专用变体。span class 同时编码 size class 和是否无指针；例如官方文章举例的 mallocgcSmallNoScanSC3 表示普通 small、无指针、size class 3，也就是 17–24 字节范围。专用例程只处理常见情况，发现 GC 状态等边界条件时会回退到更通用的分配逻辑。

这也解释了为什么“源码里看到小对象”不等于“一定直接调用专用函数”：编译器只有在能确定分配大小和类型属性时，才适合直接生成专用调用；动态长度切片、反射和复杂类型路径仍可能走通用判断。

如果需要做兼容性对照，Go 1.27 发布说明提供了构建期开关：

# 只用于对照基准：关闭尺寸特化，比较同一程序的分配成本
GOEXPERIMENT=nosizespecializedmalloc go test -bench=. -benchmem ./...

这是实验性对照，不建议把它当作常规性能开关。发布前应优先使用默认构建结果，并记录 Go 版本、目标架构和 benchmark 参数。

把收益放回真实工程

不要先改代码再猜收益。先用 -benchmem 看每次操作的分配次数和字节数，再用 CPU/内存剖析确认热点是否真的在对象分配。如果主要成本来自清零、锁竞争、网络等待或大对象复制，尺寸特化对整体延迟的影响可能很小。

保留指针语义。含指针对象需要由 GC 扫描，不能为了追求 tiny block 把它强行改成不安全的字节布局。tiny 对象也不能显式释放；应用层只需要遵守普通 Go 的生命周期规则，不要通过 unsafe 模拟 runtime 的内部释放协议。

关注版本与架构。官方给出的 20%–30% 是部分分配成本的上限描述，不是业务吞吐承诺。升级 Go 后应在自己的服务、CPU 架构和数据分布上重新跑基准，避免用别人的数字替代测量。

一个适合提交到项目里的基准骨架如下：

func BenchmarkNewPair(b *testing.B) {
	// 让每轮都产生同样的工作量，避免把日志和网络操作混入分配测量。
	for i := 0; i 

基准只负责提供可重复的比较入口；它不能单独证明某个对象“走了 tiny allocator”。需要结合编译器逃逸信息、allocs/op、B/op 和运行时内存剖析一起解释。

常见问题

小于 80 字节就一定走专用快速路径吗？

不一定。大小只是条件之一，还要看编译器是否知道大小、对象是否含指针、GC 和调试状态，以及当前 Go 版本是否启用对应优化。动态长度和边界场景仍可能由通用入口处理。

tiny allocator 和 Go 1.27 的 size-specialized allocation 是一回事吗？

不是。tiny allocator 把多个无指针小对象放进同一个 tiny block；size-specialized allocation 则是按 span class 生成更具体的分配例程，减少分派和判断成本。两者都服务于小对象，但优化层次不同。

应用代码能直接调用 mallocgc 或设置 tiny block 大小吗？

不能把 runtime 内部函数当成公开 API。应用层应通过减少不必要的逃逸、复用合适的数据结构和测量 benchmark 来获得收益，不要用 unsafe 绑定内部实现。

总结一下：先看逃逸，再看大小与指针属性，最后看实际基准。Go 1.27 的专用快速路径让常见小对象的 runtime 入口更短，但它的价值要通过真实分配次数、CPU 时间和堆行为来判断，而不是靠对象字节数做静态猜测。