使用unsafe消除Go语言的边界检查
热点路径优化可运用unsafe指针算术运算来消除Go编译器无法移除的边界检查，前提是能证明这些检查确实不必要。这是2026年7月6日发布的内容，也是“优化目录”系列文章的一部分，该系列还包括“何时浮点除法比整数除法更快”“4字节填充如何使数组清零速度提高49%”。
边界检查消除（BCE）的作用
边界检查消除（BCE）可能是Go领域中最强大、最有效的优化技术之一。开始对任何Go热点路径进行优化时，它是首选技术。为什么它如此强大呢？因为它能减少热点路径中的指令数量和分支数量，减少浪费的周期，还有额外好处。如果代码已出现缓存容量和/或冲突缺失问题，减少指令数量可显著改善这些问题，涉及L1指令缓存、微操作缓存，也许还有前端分支预测缓存。此外，BCE对寄存器压力也有帮助。边界检查不仅强大，而且易于检测，有时相对容易消除。简而言之，BCE通常是值得优先尝试的快速优化方法。然而，有时用传统方法消除边界检查并不容易，这时就需要用到unsafe技术了。
什么是边界检查
Go是安全语言，提供一些保证，如保证不能访问超出范围的切片元素。为实现这一点，编译器会添加汇编代码，确保访问超出范围的索引时，运行时会触发panic。例如：
func load(src []byte, i int) byte {
return src[i]
}
使用`-B`标志编译这段代码，该标志会禁用边界检查，会生成简洁的汇编代码；去掉`-B`标志后，汇编代码显示了边界检查带来的开销。虽然这个汇编代码的差异有点夸张，但即便忽略一些因素，仍然存在开销。不过，如果有小函数通过BCE转换为叶子函数，从而消除调用开销，那就是合理的与BCE相关的优化。顺便说一下，不需要在汇编代码中搜索来查找边界检查，编译器可使用以下命令列出所有的边界检查：
go build -gcflags="-d=ssa/check_bce/debug=1" .
处理边界检查的传统方法
如果能“证明”边界检查是不必要的，Go编译器通常可以消除它们。可通过在遍历范围之前先访问上界或下界来证明。例如在真实代码库中有这样的例子：
func matchLen(a, b []byte, limit int) int {
a = a[:limit]
b = b[:len(a)]
i = 0
for ; i <= len(a)-8; i += 8 {
xor = loadU64(a[i:]) ^ loadU64(b[i:])
if xor != 0 {
return i + bits.TrailingZeros64(xor)/8
}
}
for ; i < len(a) && a[i] == b[i]; i++ {
}
return i
}
在循环条件中使用`i <= len(a)-8`使编译器能够消除边界检查，因为它现在可以确定所有对`a`的访问都在范围内。`b = b[:len(a)]`消除了循环中与`b`相关的边界检查。随着Go版本的不断更新，编译器在消除边界检查方面变得越来越智能。通常有很多好方法可以向编译器提示BCE，但有时用传统方法无法消除边界检查，这时就需要用到unsafe了。需要注意，这里讨论的是编译器无法确定边界检查是否必要，但程序员可以确定的情况。如果无法证明边界检查是不必要的，就不要消除它，编译器插入这些检查是有原因的。
使用unsafe消除边界检查
以brotli库中的`binary.LittleEndian.Uint32`函数为例，该函数以小端字节序从切片中读取4个字节，已尝试通过给编译器提示来消除边界检查，但仍有一个边界检查。下面是使用unsafe的示例，它消除了所有的边界检查，还将加载函数转换为叶子函数，消除了`CALL`开销：
//go:build !purego && (amd64 || 386 || arm64 || loong64 || ppc64le || wasm)
package encoder
import "unsafe"
func loadU32LE(b []byte, i uint) uint32 {
return *(*uint32)(unsafe.Add(unsafe.Pointer(unsafe.SliceData(b)), i))
}
需要注意的是，函数签名发生了变化。调用标准库版本是`binary.LittleEndian.Uint32(data[offset:])`，调用unsafe版本是`loadU32LE(data, offset)`。如果仍然使用`(data[offset:])`，调用方仍然会有一个边界检查。还要注意`go:build`指令，这个技巧只适用于那些首先以小端字节序将数据放入内存的机器。像klauspost/compress这样对性能要求极高的库也依赖于同样的unsafe小端字节序加载。
示例分析
对使用unsafe的示例进行分析：
- `unsafe.SliceData(b)`返回的结果与`&b[0]`相同，即指向切片第一个元素的指针。使用`b[0]`会引入边界检查，而`unsafe.SliceData`的好处是可在空切片上使用它。
- `unsafe.Pointer`将`unsafe.SliceData`返回的`*byte`转换为`unsafe.Add`所需的`unsafe.Pointer`类型。
- `unsafe.Add(ptr, i)`返回`&b[i]`的`unsafe.Pointer`表示。
- 最后将其转换为`*uint32`并进行解引用。
查看汇编代码会发现，Go编译器消除了所有的边界检查，并内联了所有的调用。
性能对比
进行基准测试来对比标准库的小端字节序加载器和手动编写的unsafe版本的性能。基准测试代码如下：
package bce
import (
"encoding/binary"
"testing"
"unsafe"
)
func loadU32LE(b []byte, i uint) uint32 {
return *(*uint32)(unsafe.Add(unsafe.Pointer(unsafe.SliceData(b)), i))
}
var sink uint32
func BenchmarkLoadU32LE(b *testing.B) {
data = make([]byte, 4096)
b.SetBytes(int64(len(data)))
for b.Loop() {
var acc uint32
for i = uint(0); i+4 <= uint(len(data)); i += 4 {
acc += loadU32LE(data, i)
}
sink = acc
}
}
func BenchmarkStdUint32(b *testing.B) {
data = make([]byte, 4096)
b.SetBytes(int64(len(data)))
for b.Loop() {
var acc uint32
for i = 0; i+4 <= len(data); i += 4 {
acc += binary.LittleEndian.Uint32(data[i:])
}
sink = acc
}
}
测试结果为：
goos: linux
goarch: amd64
pkg: bcetest
cpu: 12th Gen Intel(R) Core(TM) i5-12500
BenchmarkLoadU32LE 22644585 273.7 ns/op 14966.04 MB/s
BenchmarkStdUint32 9922156 600.7 ns/op 6818.58 MB/s
unsafe版本的速度快了两倍多。在真实世界的压缩匹配查找器在生产环境类似工作负载下，用unsafe版本替换标准库小端字节序加载器前后的基准测试结果如下：
pkg: github.com/andybalholm/brotli/matchfinder
│ before.txt │ after.txt │
│ B/s │ B/s vs base │
Trio 90.39Mi ± 0% 99.99Mi ± 0% +10.62% (p=0.000 n=30)
明显的缺点是：这是不安全的，编译器为你插入的所有验证现在都必须由程序员证明是真正不必要的。希望Go有`nobounds`编译器提示，但它没有，所以唯一可行的选择就是使用unsafe指针算术运算。
上一篇：4字节填充如何使数组清零速度提高49%
