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

大家好，我们又见面了啊~本文《在 Go 中，变量何时会变得不可访问？》的内容中将会涉及到golang等等。如果你正在学习Golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

问题内容

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]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.

的文档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还没有离开它的生命范围，为什么它会无法访问？这是否意味着只要在下面的代码中没有使用变量，无论它是否在其生命范围内，它都将无法访问？

正确答案

当运行时检测到 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()调用。

今天关于《在 Go 中，变量何时会变得不可访问？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于golang的内容请关注golang学习网公众号！