Go runtime.KeepAlive 防止句柄过早回收

runtime.KeepAlive 解决的是一种很窄但很隐蔽的生命周期问题：Go 对象持有文件描述符、套接字或其他原生句柄，清理由 finalizer 负责，而业务代码只把句柄字段传给系统调用。编译器可能认为对象在更早的位置已经不再使用，finalizer 因而有机会提前关闭句柄。正确做法是把 runtime.KeepAlive(owner) 放在最后一个仍依赖该资源的操作之后。

实际开发中如果把绑定了系统资源的Go指针对象传递给C接口、或者执行异步回调逻辑时，只要在对象的最后一次被引用位置之后手动调用`runtime.KeepAlive`标记存活，就能避免GC提前回收句柄导致的空指针、资源非法访问这类诡异问题。

最小写法：放在原生调用之后

下面的 Handle 假设在其他位置注册了 finalizer，用于兜底关闭 fd。syscall.Read 只接收整数句柄，不会让 h 自动保持可达，因此要在读取完成之后显式保活所有者。

package resource

import (
	"runtime"
	"syscall"
)

type Handle struct {
	fd int
}

func ReadOnce(h *Handle, buf []byte) (int, error) {
	// 原生调用只拿到整数句柄，不会自动保活 h。
	n, err := syscall.Read(h.fd, buf)

	// h 在这里之前必须保持可达，防止清理函数提前关闭 fd。
	runtime.KeepAlive(h)
	return n, err
}

关键不是“调用过 KeepAlive”这件事，而是它出现的位置。只要程序执行到这行之前，运行时就必须把 h 视为可达对象，关联的 finalizer 不能提前运行。

为什么只使用句柄值还不够

Go 的存活分析关注对象是否还会被 Go 代码使用。把 h.fd 取成一个整数并传入系统调用后，后续表达式可能只依赖这个整数，不再依赖结构体 h。整数值仍在使用，并不等于持有它的 Go 对象仍然可达。

如果 h 注册了关闭句柄的 finalizer，垃圾回收器可能在系统调用真正消费该句柄之前判定对象不可达。finalizer 一旦关闭句柄，当前读取可能失败；更危险的是，操作系统若很快复用了相同编号，新调用还可能碰到另一个资源。KeepAlive 就是在 Go 对象边界和系统资源边界之间补上明确的存活约束。

KeepAlive 的位置决定保护边界

runtime.KeepAlive(h) 只保证 h 在该调用点之前可达。若把它放在 syscall.Read 之前，保活边界会过早结束，系统调用期间仍可能失去保护。因此通常写成“执行原生调用，再调用 KeepAlive，最后返回结果”。

当函数存在多个返回分支时，可以把原生操作整理到统一出口，减少漏放。也可以在合适的函数入口写 defer runtime.KeepAlive(h)，让保活发生在函数退出时；不过这种写法会把生命周期延长到整个函数结束，范围更宽，应确认这就是想要的资源边界。

哪些情况需要，哪些情况不需要

错误写法与修正

第一种错误是把 KeepAlive 放在操作前面。它只能保证对象活到这一行，不能自然延伸到后面的系统调用。

func ReadWrong(h *Handle, buf []byte) (int, error) {
	// 错误：保活边界在真正读取之前就结束了。
	runtime.KeepAlive(h)
	return syscall.Read(h.fd, buf)
}

第二种错误是把它当作资源管理器。下面的显式关闭模式通常更容易推理：业务路径负责 Close，finalizer 只做遗忘关闭时的兜底。即使保留 finalizer，也要让关闭操作具备幂等保护。

func (h *Handle) Close() error {
	// 生产代码应同时处理重复关闭和并发访问。
	err := syscall.Close(h.fd)
	runtime.SetFinalizer(h, nil) // 显式关闭后取消兜底清理。
	return err
}

第三种错误是为了“防止 GC”在普通代码中到处添加 KeepAlive。它只用于阻止 finalizer 过早执行，不是通用性能优化，也不会阻止其他 goroutine 主动关闭同一资源。

常见问题

KeepAlive 会把对象永久留在内存里吗？

不会。它只把对象的可达性延长到指定调用点。越过该点后，如果没有其他引用，对象仍可被回收。

没有设置 finalizer 也需要调用吗？

通常不需要。官方语义强调它用于防止 finalizer 过早运行。若问题是并发关闭、悬空指针或错误的资源所有权，应分别修复对应设计。

它和 TCP keep-alive 是一回事吗？

不是。runtime.KeepAlive 管的是 Go 对象可达性；TCP keep-alive 是网络连接探测机制，两者只有英文名称相似。

最稳妥的检查方法是什么？

沿着“Go 对象所有者—原生句柄字段—系统调用—清理函数”检查：如果系统调用只拿到裸句柄，而清理函数可能由 finalizer 触发，就把 KeepAlive(owner) 放在最后一个需要该资源的调用之后，并继续用显式 Close 管理正常生命周期。