性能优化|青训营笔记
这是我参与「第五届青训营 」伴学笔记创作活动的第 6 天
1. 性能优化建议
- 性能优化的前提是满足正确可靠、简洁清晰等质量因素
- 性能优化是综合评估，有时候时间效率和空间效率可能对立
- 针对Go语言特性，介绍Go相关的性能优化建议
1.1 Benchmark
- 性能表现需要实际数据衡量
- Go语言提供了支持基准性能测试的benchmark工具
go test -bench=. -benchmem
1.2 Slice
Slice 预分配内存
-
尽可能在使用make()初始化切片时提供容量信息
-
切片本质是一个数组片段的描述
- 包括数组指针
- 片段的长度
- 片段的容量(不改变内存分配情况下的最大长度)
-
切片操作并不复制切片指向的元素
-
创建一个新的切片会复用原来切片的底层数组
-
另一陷阱大内存未释放
-
在已有切片基础上创建切片，不会创建新的底层数组
-
场景
- 原切片较大，代码在原切片基础上新建小切片
- 原底层数组在内存中有引用，得不到释放
-
可使用copy替代re-slice
-
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)
}
}
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
}
go test -run=. -v 测试
1.3 Map
map 预分配内存
尽可能在使用make()初始化切片时提供容量信息
- 不断向map中添加元素的操作会触发map的扩容
- 提前分配好空间可以减少内存拷贝和Rehash的消耗
- 建议根据实际需求提前预估好需要的空间
1.4 字符串处理
使用strings.Builder
-
常见字符串拼接方式
-
- strings.Builder
- bytes.Buffer
-
+性能最差，bytes.Buffer和strings.Builder相近，strings.Builder更快
分析：
- 字符串在Go语言中是不可变类型，占用内存大小是固定的
- 使用"+"每次都会重新分配内存
- strings.Builder，bytes.Buffer底层都是[]byte数组
- 内存扩容策略，不需要每次拼接重新分配内存
- bytes.Buffer转化为字符串时重新申请了一块空间
- strings.Builder直接将底层的[]byte转换成了字符串类型返回
预分配：
strings.Builder.Grow(n*len(str))
bytes.Buffer.Grow(n*len(str))
1.5 空结构体
-
空结构体struct{}实例不占据任何的内存空间
-
可作为各种场景下的占位符使用
- 节省资源
- 空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符
-
实现set，可以考虑用map来代替 用空结构体作为map的值即可节省内存
-
对于这个场景，只需要用到map的键，而不需要值
-
即使是将map的值设置为bool类型，也会多占据1个字符空间
1.6 atomic包
多线程编程atomic性能比加锁高
- 锁的实现是通过操作系统来实现，属于系统调用
- atomic操作是通过硬件实现，效率比锁高
- sync.Mutex应该用来保护一段逻辑，不仅仅用于保护一个变量
- 对于非数值操作，可以使用atomic.Value，能承载一个interface{}
1.7 小结
- 避免常见的性能陷阱可以保证大部分程序的性能
- 普通应用代码，不要一味地追求程序的性能
- 越高级的性能优化手段越容易出现问题
- 在满足正确可靠、简洁清晰的质量要求的前提下提高程序性能
