前言： \textcolor{Green}{前言：} 前言：
💞这个专栏就专门来记录一下寒假参加的第五期字节跳动训练营
💞从这个专栏里面可以迅速获得Go的知识
Go的性能优化建议
性能优化对于一个系统来说是非常重要的，因为我们在编写代码结束的时候有可能不会对性能有过多的关注，但是对于用户来说性能是非常重要的，我们肯定希望使用的系统是流畅的。这是一个速度决定一切的年代，只要我们的还继续在这个时代中，线下的流程与系统就在持续向线上转移，我们就会碰到性能问题。
3 性能优化建议
简介
- 性能优化的前提是满足正确可靠、简洁清晰等质量因素
- 性能优化是综合评估，有时候时间效率和空间效率可能对立
- 针对 Go 语言特性，介绍 Go 相关的性能优化建议
3.1 性能优化建议 - Benchmark
如何使用
- 性能表现需要实际数据衡量
- Go 语言提供了支持基准性能测试的 benchmark 工具
go test -bench=. -benchmen
// from fib.go
func Fib(n int) int {
if n < 2 {
return n
}
return Fib(n - 1) + Fib(n - 2)
}
// from fib_test.go
func BenchmarkFib10(b *testing.B) {
// run the Fib function b.N times
for n := 0; n < b.N; n++ {
Fib(10)
}
}
结果说明
- BenchmarkFib10-8：BenchmarkFib10是测试函数名，-8 表示 GOMAXPROCS 的值为8
- 1855870：表示一共执行 1855870次， 即 b.N 的值
- 602.5 ns/op：表示每次执行花费 602.5 ns
- 0 B/op：表示每次执行申请多大的内存
- 0 allocs/op：表示每次执行申请几次内存
GOMAXPROCS 1.5版本后，默认值为CPU核数，https://pkg.go.dev/runtime#GOMAXPROCS
3.2 性能优化建议 - slice
slice 预分配内存
- 尽可能在使用 make() 初始化切片时提供容量信息
查看下面的代码，可以发现，提供容量信息后数据明显好
func NoPreAlloc(size int) {
data := make([]int, 0)
for k := 0; k < size; k++ {
data = append(data, k)
}
}
func PreAlloc(size int) {
data := make([]int, 0, size)
for k := 0; k < size; k++ {
data = append(data, k)
}
}
| BenchmarkNoPreAlloc-8 | 3529980 | 331.1 ns/op | 2040 B/op | 8 allocs/op |
| BenchmarkPreAlloc-8 | 11171086 | 107.1 ns/op | 896 B/op | 1 allocs/op |
此时我们明白了
- 切片本质是一个数组片段的描述
- 包括数组指针
- 片段长度
- 片段的容量（不改变内存分配情况下的最大长度）
- 切片操作并不复制切片指向的元素
- 创建一个新的切片会复用原来切片的底层数组
-
type slice struct { array unsafe.Pointer len int cap int }
另一个陷阱：大内存未释放
- 在已有切片基础上创建切片，不会创建新的底层数组
- 场景：
- 原切片较大，代码在原切片基础上新建小切片
- 原底层数组在内存中有引用，得不到释放
- 可使用 copy 替代 re-slice
func GetLastBySlice(origin []int) []int {
return origin[len(origin)-2:]
}
func GetLastByCopy(origin []int) []int {
result := make([]int, 2)
copy(result, origin[len(origin)-2:])
return result
}
func testGetLast(t *testing.T, f func([]int) []int) {
result := make([][]int, 0)
for k := 0; k < 100; k++ {
origin := generateWithCap(128 * 1024) // 1M
result = append(result, f(origin))
}
printMem(t)
_ = result
}
3.3 性能优化建议 - Map
map 预分配内存
func NoPreAlloc(size int) {
data := make(map[int]int)
for k := 0; k < size; k++ {
data[i] = 1
}
}
func PreAlloc(size int) {
data := make(map[int]int, size)
for k := 0; k < size; k++ {
data[i] = 1
}
}
| BenchmarkNoPreAlloc-8 | 22699 | 51972ns/op | 82327B/op | 9 allocs/op |
| BenchmarkPreAlloc-8 | 123418 | 9622ns/op | 40984B/op | 2 allocs/op |
分析：
- 不断向 map 中添加元素的操作会触发 map 的扩容
- 提前分配好空间可以减少内存拷贝和 Rehash 的消耗
- 建议根据实际需求提前预估好需要的空间
3.4 性能优化建议 - 字符串处理
- 常见的字符串拼接方式
func Plus(n int, str string) string {
s := ""
for i := 0; i < n; i++ {
s += str
}
}
func StrBuilder(n int, str string) string {
var bulider strings.Builder
for i := 0; i < n; i++ {
builder.WriteString(str)
}
return builder.String()
}
使用 strings.Builder
func ByteBuffer(n int, str string) string {
buf := new(bytes.Buffer)
for i := 0; i < n; i++ {
buf.WriteString(str)
}
return buf.String()
}
| BenchmarkPlus-8 | 4318 | 280260ns/op | 3212595 B/op | 999 allocs/op |
| BenchmarkStrBulider-8 | 269257 | 2392 ns/op | 26744 B/op | 15 allocs/op |
| BenchmarkByteBuffer-8 | 209278 | 5699 ns/op | 25008 B/op | 9 allocs/op |
- 使用 + 拼接性能最差，strings.Builder，bytes.Buffer 相近，strings.Buffer 更快
- 分析
- 字符串在 Go 语言中是不可变类型，占用内存大小是固定的
- 使用 + 每次都会重新分配内存
- strings.Builder，bytes.Buffer 底层都是 []byte 数组
- 内存扩容策略，不需要每次拼接重新分配内存
注意看下面的
- bytes.Buffer 转换为字符串时重新申请了一块空间
- strings.Builder 直接将底层的 []byte 转换成了字符串类型返回
// to build strings more efficiently, see the strings.Builder type.
func (b *Buffer) String() string {
if b == nil {
// Special case, useful in debugging.
return "<nil>"
}
return string(b.buf[b.off:])
}
// String returns the accumulated string
func (b *Builder) String() string {
return *(*string)(unsafe.Pointer(&b.buf))
}
func PreStrBuilder(n int, str string) string {
var bulider strings.Builder
builder.Grow(n * len(str))
for i := 0; i < n; i++ {
builder.WriteString(str)
}
return builder.String()
}
func PreByteBuilder(n int, str string) string {
buf := new(bytes.Buffer)
buf.Grow(n * len(str))
for i := 0; i < n; i++ {
buf .WriteString(str)
}
return buf .String()
}
这五个进行对比
| BenchmarkPlus-8 | 4272 | 279704 ns/op | 3212596 B/op | 999 allocs/op |
| BenchmarkStrBulider-8 | 268747 | 4405 ns/op | 26744 B/op | 15 allocs/op |
| BenchmarkByteBuffer-8 | 4670 | 5670 ns/op | 25008 B/op | 9 allocs/op |
| BenchmarkPreStrBulider-8 | 3938 | 3938 ns/op | 6144 B/op | 1 allocs/op |
| BenchmarkPreByteBuffer-8 | 4578 | 4578 ns/op | 12288 B/op | 2 allocs/op |
3.5 性能优化建议 - 空结构体
使用空结构体节省内存
- 空结构体 struct{} 实例不占据任何的内存空间
- 可作为各种场景下的占位符使用
- 节省资源
- 空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符
func EmptyStructMap(n int) {
m := make(map[int]struct{})
for i := 0; i < n; i++ {
m[i] = struct{}{}
}
}
func BoolMap(n int){
m := make(map[int]bool)
for i := 0; i < n; i++ {
m[i] = false
}
}
| BenchmarkEmptyStructMap-8 | 2372 | 505970 ns/op | 378864 B/op | 133 allocs/op |
| BenchmarkBoolMap-8 | 2266 | 526095 ns/op | 412362 B/op | 165 allocs/op |
- 实现 Set，可以考虑用 map 来代替
- 对于这个场景，只需要用到 map 的键，而不需要值
- 即使是将 map 的值设置为 bool类型，也会多占据 1 个字节空间
一个开源实现：https://github.com/deckarep/golang-set/blob/main/threadunsafe.go
3.6 性能优化建议 - atomic包
如何使用 atomic 包
type atomicCounter struct {
i int32
}
func AtomicAddOne(c *atomicCounter) {
atomic.AddInt32(&c, i, 1)
}
type mutexCounter struct {
i int32
m sync.Mutex
}
func MutexAddOne(c *mutexCounter) {
c.m.Lock()
c.i++
c.m.Unlock()
}
| BenchmarkAtomicAddOne-8 | 141824372 | 8.045 ns/op | 4 B/op | 1 allocs/op |
| BenchmarkNutexAddOne-8 | 60487044 | 21.73 ns/op | 16 B/op | 1 allocs/op |
使用 atomic 包
- 锁的实现是通过操作系统来实现，属于系统调用
- atomic 操作是通过硬件实现的，效率比锁高
- sync.Mutex 应该用来保护一段逻辑，不仅仅用于保护一个变量
- 对于非数值操作，可以使用 atomic.Value，能承载一个 interface{}
性能优化建议小结
- 避免常见的性能陷阱可以保证大部分程序的性能
- 普通应用代码，不要一昧的追求程序的性能
- 越高级的性能优化手段越容易出现问题
- 在满足正常可靠、简洁清晰的质量要求的前提下提高程序性能
