性能优化建议
性能优化的前提是代码的正确可靠，简洁等根本的质量因素
性能优化需要综合考量时间复杂度和空间复杂度
使用Benchmark进行性能测试
go test -bench=. -benchmem
//fib.go
package main
func Fib(n int) int {
if n < 2 {
return n
}
return Fib(n-1) + Fib(n-2)
}
//fib_test.go
package main
import "testing"
func BenchmarkFib10(b *testing.B) {
for n := 0; n < b.N; n++ {
Fib(10)
}
}
Slice性能优化建议
尽可能在使用make()初始化切片时提供容量信息
左边为没有预制大小，右边是初始化了大小
明显初始化大小后会提升效率
切片本质是一个数组片段的描述
包括数组指针
片段的长度
片段的容量(不改变内存分配情况下的最大长度)
切片操作并不复制切片指向的元素
创建一个新的切片会复用原来切片的底层数组，如果容量不够会先扩容，再添加，这样的操作是需要消耗时间的
在已有切片基础上创建切片，不会创建新的底层数组
场景：
（1）原切片较大，代码在原切片基础上新建小切片；
（2）原底层数组在内存中有引用，得不到释放。
可使用copy替代 re-slice
Map性能优化建议
和Slice类似，最好先预分配内存，提前分配好空间可以减少内存拷贝和 Rehash的消耗，不断向map中添加元素的操作会触发map的扩容
字符串处理性能优化
使用strings.Builder进行字符串拼接可以提升性能
使用＋拼接性能最差，strings.Builder，bytes.Buffer相近，strings.Builder更快
左为＋，右为使用strings.Builder
以下为bytes.Buffer
性能差异原因：
字符串在Go语言中是不可变类型，占用内存大小是固定的
使用＋每次都会重新分配内存
strings.Builder，bytes.Buffer底层都是[]byte数组
内存扩容策略，不需要每次拼接重新分配内存
bytes.Buffer转化为字符串时重新申请了一块空间，而strings.Builder直接将底层的[]byte转换成了字符串类型返回
如果知道字符串大小，最好预分配内存，这样的效率最优，原理和Slice差不多
空结构体的使用
空结构体struct实例不占据任何的内存空间可作为各种场景下的占位符使用
空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符
比如：
测试性能结果如下：
使用空结构体节省内存
实现Set，可以考虑用map 来代替，对于这个场景，只需要用到 map 的键，而不需要值，即使是将map 的值设置为bool类型，也会多占据1个字节空间
atomic包的使用处理线程问题
左为使用atomic包处理线程问题，右为使用加锁的方式，也就是我们之前经常用到的方式
对比性能：
使用atomic包可以提升性能
原因分析：
锁的实现是通过操作系统来实现，成本较高，属于系统调用
atomic操作是通过硬件实现,效率比锁高
sync.Mutex应该用来保护一段逻辑,不仅仅用于保护一个变量
对于非数值操作，可以使用atomic.Value，能承载一个 interface{}
小结
避免常见的性能陷阱可以保证大部分程序的性能
普通应用代码，不要一味地追求程序的性能
越高级的性能优化手段越容易出现问题
在满足正确可靠、简洁清晰的质量要求的前提下提高程序性能。
