Go runtime.KeepAlive 为什么能保护底层句柄生命周期

Go 的 runtime.KeepAlive 解决的是一个很窄但很要命的生命周期问题：对象里保存着文件描述符、套接字或 cgo 句柄，代码已经把句柄传给底层调用，但对象本身在 Go 代码里暂时没有新的显式引用。此时终结器可能先运行，底层句柄就会被关闭。

正确做法是把 runtime.KeepAlive(obj) 放在最后一次依赖 obj 的系统调用或 cgo 调用之后。它只保证对象至少活到这个位置，不负责释放资源，也不能替代显式的 Close。

runtime.KeepAlive 到底保证了什么

Go 文档把它描述为“让参数在当前点仍然可达”。这里的关键不是 KeepAlive 做了某种锁定，而是编译器和运行时不会把对象的生命周期判断提前越过这个调用点。若对象绑定了终结器，终结器也不能在这个点之前因为对象不可达而被调度。

例如一个包装结构体保存文件描述符，终结器负责关闭描述符，而一次读取直接使用结构体里的字段：

type handle struct {
	fd int // 底层文件描述符，由对象持有
}

func readHandle(h *handle, buf []byte) (int, error) {
	n, err := syscall.Read(h.fd, buf)
	// 读取结束前，h 仍必须保持可达，避免终结器提前关闭 fd。
	runtime.KeepAlive(h)
	return n, err
}

这里的保护对象是 h，不是整数形式的 fd。如果最后一次显式提到 h 的位置被编译器判断为更早的字段读取，终结器就可能在真正的系统调用前运行。KeepAlive 把“最后安全使用点”写得清楚。

正确放置 KeepAlive：紧跟最后一次底层调用

最稳妥的判断方法是先圈出“最后一个仍依赖对象本身的调用”，再把 KeepAlive 放在它之后。对文件描述符来说，这通常是 syscall.Read、syscall.Write 或某个 cgo 函数返回之后；不要只在函数开头调用一次，也不要把它放到下一轮复用句柄之后。

如果函数同时有错误返回和正常返回，资源所有权要先说清楚：谁创建，谁关闭；谁把句柄交给异步任务，谁保证任务完成前对象仍可达。KeepAlive 只解决当前 goroutine 中最后一次低层调用与终结器之间的竞态，不能替你协调多个 goroutine。

KeepAlive、Close、GC 和 Pinner 不要混用

Close 是确定性的资源操作，应该由拥有资源的一方显式调用，并在错误路径上保持幂等或可判断。runtime.GC() 只是请求一次垃圾回收，既不保证某个终结器立刻运行，也不会替你延长对象寿命。KeepAlive 更不会让对象永久存活。

runtime.Pinner 用于固定 Go 内存对象，以满足特定的指针传递规则；它和“对象可能被终结器提前处理”是两件事。即使使用 cgo，也必须遵守 unsafe.Pointer 的有效使用规则，不能靠 KeepAlive 绕过指针传递限制。

func useResource(r *resource) error {
	if err := r.open(); err != nil {
		return err // 打开失败时没有可关闭的句柄
	}
	defer r.Close() // 所有权仍由显式 Close 收口

	if err := r.callNative(); err != nil {
		runtime.KeepAlive(r)
		return err // 底层调用返回后再结束对象保护窗口
	}
	runtime.KeepAlive(r)
	return nil
}

上面的写法表达了两个独立事实：调用期间对象不能过早失去可达性，函数退出前资源必须走确定性的关闭路径。若 callNative 把工作交给后台线程，KeepAlive 不能替代等待、引用计数或显式的任务完成信号。

上线前检查这五个生命周期问题

1. 终结器绑定的对象是否真的承载了仍在使用的句柄，而不是只保存一个复制出来的整数。
2. KeepAlive 是否紧跟最后一次使用对象的底层调用之后。
3. Close 是否由明确的资源所有者负责，并覆盖错误返回、提前退出和取消路径。
4. 跨 goroutine 或 cgo 后，是否还有等待或同步协议，而不是把 KeepAlive 当成并发安全保证。
5. 是否能删掉终结器而不影响正常释放；终结器只能做兜底，不能承担业务正确性。

当代码需要这五项都能回答清楚时，KeepAlive 通常只出现一两处，而且位置非常明确。若必须在很多地方散落调用，往往说明资源所有权或异步边界还没有整理好。

常见问题

KeepAlive 会阻止 GC 回收整个程序吗？

不会。它只把传入对象标记为可达直到当前调用点，之后对象仍可能被回收，终结器也可能在未来运行。

用了 KeepAlive 还需要 Close 吗？

需要。KeepAlive 不释放文件描述符、连接或 cgo 资源；正常路径仍应显式 Close，终结器只作为异常兜底。

KeepAlive 能修复所有 cgo 句柄问题吗？

不能。它只处理对象过早不可达的问题，不能放宽 Go 与 C 之间的指针规则，也不能替代跨线程同步和任务完成通知。

参考：Go runtime.KeepAlive 官方文档、Go 垃圾回收指南。