在 Go 中，变量何时会变得不可访问？

Question

Go 1.7 beta 1 于今天早上发布，这里是Go 1.7 的发布说明草稿。一个新功能KeepAlive被添加到包runtime中。的文档runtime.KeepAlive给出了一个例子：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]byten, 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.的文档runtime.SetFinalizer还对以下内容进行了解释runtime.KeepAlive：例如，如果 p 指向一个包含文件描述符 d 的结构，并且 p 具有关闭该文件描述符的终结器，并且如果函数中最后一次使用 p 是对 syscall.Write(pd, buf, size )，那么一旦程序进入 syscall.Write，p 就可能无法访问。终结器可能在那个时候运行，关闭 pd，导致 syscall.Write 失败，因为它正在写入一个关闭的文件描述符（或者更糟糕的是，写入由不同的 goroutine 打开的完全不同的文件描述符）。为避免此问题，请在调用 syscall.Write 之后调用 runtime.KeepAlive(p)。令我困惑的是，变量p还没有离开它的生命范围，为什么它会无法访问？这是否意味着只要在以下代码中没有使用变量，无论它是否在其生命范围内，它都将无法访问？

Answer 1

当运行时检测到Go代码无法到达再次引用该变量的点时，该变量将变得不可访问。

在您发布的示例中， asyscall.Open()用于打开文件。返回的文件描述符（只是一个int值）被“包装”在struct. 然后一个终结器附加到这个结构值上，关闭文件描述符。现在，当这个结构值变得不可访问时，它的终结器可能随时运行，并且文件描述符的关闭/失效/重用可能会导致Read()系统调用执行时出现意外行为或错误。

p在Go代码中这个结构值的最后一次使用是什么时候syscall.Read()被调用（并且文件描述符p.d被传递给它）。系统调用的实现将在启动后使用该文件描述符syscall.Read()，它可能会一直这样做直到syscall.Read()返回。但是文件描述符的这种使用是“独立”于 Go 代码的。

所以p在执行系统调用期间不使用结构值，系统调用会阻塞 Go 代码，直到它返回。这意味着允许 Go 运行时p在执行期间Read()（Read()返回之前）或什至在其实际执行开始之前标记为不可访问（因为p仅用于为 call 提供参数Read()。

因此调用runtime.KeepAlive(): 因为这个调用在之后并且syscall.Read()它引用了变量p，所以 Go 运行时不允许在返回p之前标记 unreachable Read()，因为这是在Read()调用之后。

请注意，您可以使用其他构造来“保持p活力”，例如_ = p或返回它。runtime.KeepAlive()在后台没有做任何神奇的事情，它的实现是：

func KeepAlive(interface{}) {}

runtime.KeepAlive() 确实提供了更好的选择，因为：

• 它清楚地记录了我们想要保持p活动状态（以防止运行Finalizers）。

• 使用其他结构，例如_ = p可能会被未来的编译器“优化”出来，但不会被runtime.KeepAlive()调用。