最近尝试把开发环境，升级到Golang1.7.1后，程序会偶发性的宕掉，查看日志后，发现总是在一个计算切片的哈希值的地方，错误信息是：
unexpected fault address 0xc043df4000， fatal error: fault
在1.7之前程序持续运行2年了，从来没有出现这个问题，怀疑是Golang编译器升级到SSA后导致的。将程序的代码精简为以下函数：
//本代码的主要作用是，把一个字符串的Assii的值累加起来。 func SimpleCrc(ptr uintptr, size int) int { ret := 0 maxPtr := ptr + uintptr(size) for ptr < maxPtr { b := *(*byte)(unsafe.Pointer(ptr)) //出错的地方 ret += int(b) ptr++ } return ret }
注：实际的代码比这个复杂很多。采用类似这种写法后，相比常规写法性能提升高达8倍。
分析错误直接表现是“非法内存地址访问”导致的，只有一种原因是“字符串使用的内存被SSA编译释放了”，被GC提前回收了并且归还给了
windows操作系统。因此查阅了SSA编译器的原理。发现SSA编译器变得聪明很多，它能根据（既定规则）快速判断出，内存不再被使用，所以内存回收非常迅速。由此思考的着眼点变为：有没有什么办法告知SSA编译器，特定的内存在指定的代码区不要回收？，记得之前看过Golang1.7在runtime包中，增加一个函数func KeepAlive(interface{})
{}，查看注释后发现“使用该函数可以设定内存在指定的代码区保持有效”，而不被GC回收。
为了重现上述推断，因此编写以下示例：
// memTest package main import ( "fmt" "reflect" "runtime" "unsafe" ) func SimpleCrc(ptr uintptr, size int) int { ret := 0 maxPtr := ptr + uintptr(size) for ptr < maxPtr { b := *(*byte)(unsafe.Pointer(ptr)) ret += int(b) ptr++ } return ret } //模拟申请内存，触发Gc回收内存 func Allocation(size int) { var free []byte free = make([]byte, size) if len(free) == 0 { panic("Allocation Error") } } func SliceCrcTest(slice []byte, N int) (ret int) { newSlice := []byte(string(slice)) //获取独立内存 sh := (*reflect.SliceHeader)(unsafe.Pointer(&newSlice)) //反射切片结构 ptr, size := uintptr(sh.Data), sh.Len //获取地址尺寸 runtime.GC() //强制内存回收 for i := 0; i < N; i++ { ret = SimpleCrc(ptr, size) //计算crc校验码 Allocation(size) //模拟申请内存，触发Gc回收内存 } //runtime.KeepAlive(newSlice) //本行一旦注释后结果不再是1665，取消注释节正确 return } func StringCrcTest(str string, N int) (ret int) { newStr := string([]byte(str)) //获取独立内存 runtime.SetFinalizer(&newStr, func(x *string) {}) //设置回收事件 sh := (*reflect.StringHeader)(unsafe.Pointer(&newStr)) //反射字符串结构 ptr, size := uintptr(sh.Data), sh.Len //获取地址尺寸 runtime.GC() //强制内存回收 for i := 0; i < N; i++ { ret = SimpleCrc(ptr, size) //计算crc校验码 Allocation(size) //模拟申请内存，触发Gc回收内存 } //runtime.KeepAlive(newStr) //本行一旦注释后结果不再是1665，取消注释节正确 return } func main() { var B = []byte("1234567890-1234567890-1234567890") //Crc的值为：1665 var S = string(B) //生成字符串 N := 1000000 //循环执行1,000,000次 fmt.Printf("SimpleCrc(\"%s\") = %v\n", B, SliceCrcTest(B, N)) fmt.Printf("SimpleCrc(\"%s\") = %v\n", B, StringCrcTest(S, N)) }
上述代码重现的思路是，首先申请内存，具体是new一个切片或字符串（其值是"1234567890-1234567890-1234567890"，它的正确CRC结果是1665），分别传入函数SliceCrcTest和StringCrcTest查看运行结果；这里只介绍SliceCrcTest函数的内部实现思路，StringCrcTest和SliceCrcTest非常一致，请自己分析理解。
在SliceCrcTest函数内部，首先是代码
newSlice := []byte(string(slice)) //获取独立内存
本行代码重复申请了两次内存，其目的是，产生一个局部变量，加快重现GC回收newSlice。
sh := (*reflect.SliceHeader)(unsafe.Pointer(&newSlice)) //反射切片结构
本行代码是通过反射，获取到切片newSlice的数据结构，目的是读取“1234567890-1234567890-1234567890”的首地址和长度。
ptr, size := uintptr(sh.Data), sh.Len //获取地址尺寸
本行代码是获取“1234567890-1234567890-1234567890”的首地址和长度，到变量ptr, size。
runtime.GC() //强制内存回收
本行代码是强制启动内存回收扫描，然后for循环一百万次，这样做的目的是留出足够的时间让GC取回收内存，循环体类执行代码如下。
ret = SimpleCrc(ptr, size) //计算crc校验码 Allocation(size) //模拟申请内存，触发Gc回收内存
调用SimpleCrc计算“1234567890-1234567890-1234567890”的校验码，并把最后一次的结果保存到ret返回变量（正确值是1665）。Allocation函数是模拟申请一次内存，函数返回后就内存会被GC回收。
//runtime.KeepAlive(newSlice) //本行一旦注释后结果不再是1665，取消注释节正确
这条语句最为关键，本语句被注释了，那么SliceCrcTest的结果应该是0，这代表着，newSlice 内存被GC回收了，并且同一块内存被再次分配给Allocation函数中的free变量，由于free的初始化为由32个‘0’组成的切片，因此SliceCrcTest计算结果变成了“0”。这样就问题重现了，被SSA编译器误认为，内存不在有效，因此GC就会回收。
注：在实际的重现过程中，因为这是一个随机的过程，不同的操作系统可能不会重现，但是只要知道思路和原理，稍微调整一下N的数值，把它加大就会重现。
N := 1000000 //循环执行1,000,000次总结：
由于Golang的SSA的编译器，变得非常聪明了，因此会把使用反射reflect.StringHeader，reflect.SliceHeader返回值中的uintptr指向的内存块，当成了没有被使用的内存块回收了。
解决办法有两个：
- 一是尽量不要过分追求性能，使用反射reflect和unsafe包内的函数。这样能避免一些诡异的、很难分析的bug出现。
- 如果非要使用反射reflect和unsafe包内的函数，请注意一定要使用runtime.KeepAlive告诉SSA编译器，在指定的代码段内，不要回收内存块。
有疑问加站长微信联系（非本文作者）
