问题描述
下面是Go 1.8 release notes中对该问题描述
The garbage collector no longer considers arguments live throughout the entirety of a function. For more information, and for how to force a variable to remain live, see the runtime.KeepAlive
function added in Go 1.7.
什么意思呢？就是说从1.8版本开始，go的GC不再管你变量在函数中的作用域了，只要GC发现后面这个变量没有再被使用了，就回收。乍一看好像很有问题，仔细想似乎又没什么问题。
紧接着官方对这个问题进行了一次update：
Updating: Code that sets a finalizer on an allocated object may need to add calls to runtime.KeepAlive
in functions or methods using that object. Read the KeepAlive
documentation and its example for more details.
Update的内容对该问题的影响进行了具体说明，就是当用户自己对一个对象设置了finalizer时，需要根据自己的需要来决定在哪个地方调用KeepAlive，以保证在此之前，GC不会回收该对象。就是说，虽然用户设置了finalizer，但finalizer的触发是由GC来控制的。新版本的GC是并行执行的，且不关心变量在函数中的作用域了，因此很可能在你不希望他释放的时候，GC把对象给释放掉了。
解决方案
下面是官方给的一段典型的示例代码：
type File struct { d int }
d, err := syscall.Open("/file/path", syscall.O_RDONLY, 0)
// ... do something if err != nil ...
p := &File{d}
runtime.SetFinalizer(p, func(p *File) { syscall.Close(p.d) })
var buf [10]byte
n, err := syscall.Read(p.d, buf[:])
解释一下问题出在哪里：变量p创建之后，用户给它设置了
finalizer。然后开始调用syscall.Read，注意Read传的参数是p.d，Go中传参都是复制的，也就是Read里面使用的变量跟变量p没有半毛钱关系。也就是Read函数调用之后，结束之前，变量p就失去了存在的意义，GC会忠实的履行自己的职责，将p给回收，此时触发了用户自己设置的finalizer，将文件描述符给关闭了。但这个时候，Read操作可能还在通过该文件描述符访问文件，这就是问题所在。
解决此问题的方法：
type File struct { d int }
d, err := syscall.Open("/file/path", syscall.O_RDONLY, 0)
// ... do something if err != nil ...
p := &File{d}
runtime.SetFinalizer(p, func(p *File) { syscall.Close(p.d) })
var buf [10]byte
n, err := syscall.Read(p.d, buf[:])
// Ensure p is not finalized until Read returns.
runtime.KeepAlive(p)
// No more uses of p after this point.
就是在Read函数调用之后，对对象p手动调用一次KeepAlive，KeepAlive是个空函数，只是欺骗一下GC，变量p到这里还有被使用，在此之前不要回收。这就确保了Read返回前，对象p不会被回收。当然KeepAlive之后，p就会被GC回收。
