问题描述
下面是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回收。