Go runtime.KeepAlive 与 finalizer 如何配合外部句柄

给 Go 对象挂了 finalizer，并不等于对象会一直活到一次外部调用结束。编译器只需要确认后面不会再使用这个对象，就可能把它视为不可达；如果 finalizer 负责关闭文件描述符、cgo 资源或其他原生句柄，释放动作就可能抢在真正的系统调用完成前发生。

最稳妥的规则是：显式 Close 负责正常生命周期，finalizer 只做兜底；凡是外部调用只拿了对象里的句柄或地址，调用返回后立刻写 runtime.KeepAlive(obj)。KeepAlive 的位置是“最后一次必须保持对象可达的边界”，不是函数开头，也不是随手放在 defer 里。

这个组合到底解决什么问题

假设 NativeHandle 只有一个 fd 字段。代码把 h.fd 传给原生函数后，后续不再读取 h，那么对编译器来说，h 可能已经没有继续存活的理由。此时垃圾回收器若发现它不可达，就可以排队执行 finalizer；finalizer 若关闭了同一个 fd，原生函数可能拿到已关闭的句柄，甚至碰巧遇到被其他代码重新分配的相同编号。

runtime.KeepAlive(h) 不会延长资源的业务所有权，也不会阻塞垃圾回收器。它只把“对象必须仍可达”的最后位置明确写出来。Go 官方示例正是把它放在 syscall.Read 返回之后，而不是放在读取之前。

把外部句柄的生命周期拆成两条线

包装对象和外部资源是两条生命周期：前者由 Go 垃圾回收器判断可达性，后者由操作系统、驱动或 C 库管理。finalizer 只能在第一条线结束后尝试处理第二条线，不能替代协议设计。因此正常路径应提供幂等的 Close，并让调用方在不再使用时明确释放。

KeepAlive 应该放在最后一次使用之后

推荐把对象作为参数传入外部操作，操作完成后紧接一行 KeepAlive。这样代码审查时能直接看出资源边界：

package handle

import "runtime"

type NativeHandle struct {
	fd uintptr // 保存外部系统分配的句柄值，不代表 Go 对象会自动延长资源寿命
}

func (h *NativeHandle) ReadInto(buf []byte) error {
	if h == nil {
		return errNilHandle // 先拒绝空对象，避免把错误伪装成句柄失效
	}
	if err := nativeRead(h.fd, buf); err != nil {
		return err // 外部调用失败也要经过 KeepAlive 边界
	}
	runtime.KeepAlive(h) // 必须放在最后一次原生调用返回之后
	return nil
}

如果原生函数返回了需要继续使用的地址或异步任务，KeepAlive 也不能单独解决问题：要先确认库的所有权、回调和并发协议，再决定是否需要复制数据、引用计数或显式等待。它保护的是 Go 对象的可达性，不是任意一段底层内存。

finalizer 的三个反例要先排除

第一，不要在 finalizer 闭包里捕获外层对象：

runtime.SetFinalizer(h, func(_ *NativeHandle) {
	closeNative(h.fd) // 错误：闭包重新引用 h，可能让 h 仍然可达
})

// 正确方向：finalizer 只使用参数，不从外层捕获包装对象。
runtime.SetFinalizer(h, func(v *NativeHandle) {
	closeNative(v.fd) // 只读取传入对象的句柄值
})

第二，避免包装对象通过字段、容器或回调形成自引用环；带 finalizer 的环不保证能按预期回收。第三，不要把 finalizer 当作并发协调器。Go 文档说明 finalizer 由一个 goroutine 依次运行；如果它读取会被业务 goroutine 修改的状态，仍需要锁或原子操作。runtime.GC() 也只负责把工作排队，不等于 finalizer 已经执行完成。

什么时候改用显式 Close 或 AddCleanup

文件、连接、映射区域和 cgo 句柄通常都应有显式 Close，并在文档里写清调用方责任。finalizer 只作为遗漏释放时的最后保险，不能拿来做必须及时完成的提交、解锁或事务操作。

在支持 runtime.AddCleanup 的 Go 版本中，可以把独立的资源值传给 cleanup 函数，避免清理函数反向持有包装对象。它对同一指针允许多个 cleanup，但执行时间仍不确定；如果项目需要兼容更早版本，仍应以显式 Close 和版本隔离为准。

判断清单很简单：外部调用是否可能在对象最后一次 Go 使用之后仍未返回？若是，在返回后放 KeepAlive；清理函数是否只依赖独立句柄值？若否，先改闭包；业务是否要求确定释放时间？若是，不要把 finalizer 当主路径。

常见问题

KeepAlive 应该放在 syscall 之前吗？

通常不应该。它要放在最后一次必须保持对象可达的外部调用之后，让 finalizer 不会在该调用真正完成前关闭句柄。

加了 KeepAlive 就不用 Close 了吗？

不用。KeepAlive 只处理提前终结的边界，资源什么时候释放仍要靠显式 Close、所有权协议或兜底清理。

finalizer 里加锁能保证释放安全吗？

锁只能处理共享状态的同步，不能保证 finalizer 何时运行，也不能修复引用环、错误捕获外层对象或外部库自身的异步所有权问题。