runtime.SetFinalizer 与对象保活关系的判断

在 Go 里给文件描述符、设备句柄或其他非内存资源挂上 runtime.SetFinalizer，并不等于“函数返回时它一定还活着”。真正决定 finalizer 能否被安排的是对象是否仍然可达；如果对象最后一次被编译器认为已经用完，底层系统调用还没有结束，资源就可能被提前关闭。解决这类问题的关键，是把资源真正使用完的位置写成明确的 runtime.KeepAlive 终点。

官方资料：https://pkg.go.dev/runtime#SetFinalizer

官方资料：https://pkg.go.dev/runtime#KeepAlive

SetFinalizer 是不可达对象的兜底清理机制，不是确定时刻的析构函数；KeepAlive 只负责把对象保活到指定位置。凡是仍依赖对象内部句柄的调用，都要先完成调用，再执行 KeepAlive，业务代码仍应优先显式释放资源。

先看一个资源提前失效的现场

假设一个结构体同时保存 Go 侧的状态和操作系统句柄。函数把句柄传给底层调用后，源码里看起来已经“用过了”对象，接下来只等待调用返回：

type NativeResource struct {
	fd uintptr
}

func (r *NativeResource) finalize() {
	// finalizer 只负责兜底关闭外部句柄，不能替代正常的 Close。
	closeNativeHandle(r.fd)
}

func readOnce(r *NativeResource, buf []byte) error {
	// 底层调用仍然依赖 r.fd，但编译器可能认为 r 在这里之后不再使用。
	if err := readNativeHandle(r.fd, buf); err != nil {
		return err
	}
	return nil
}

问题不在于 readNativeHandle 一定会触发 finalizer，而在于代码没有表达“这个对象必须至少活到系统调用返回”。一旦对象不可达，垃圾回收器可以清除 finalizer 关联并在独立的 finalizer goroutine 中调用清理函数；清理函数如果关闭同一个句柄，就会让正在使用的外部资源失效。

因此，这类偶发问题通常不是“GC 太快”，而是资源生命周期没有覆盖到底层调用的结束点。先画清对象、句柄和调用之间的边界，再决定是否需要 KeepAlive。

SetFinalizer 介入的是对象可达性

runtime.SetFinalizer(obj, finalizer) 做的是“为对象登记一个最终清理函数”。它不会把对象永久固定在堆上，也不会承诺在某个确定时间调用函数。运行时发现带 finalizer 的对象不可达后，会清掉这次关联，再安排 finalizer(obj)；此时对象会因为传入 finalizer 而重新可达，但已经没有同一个 finalizer 关联，下一次变成不可达时才可能真正释放。

这个语义带来三个容易混淆的阶段：

官方文档还限定了 obj 的形态：它应是通过 new、复合字面量取地址或局部变量取地址得到的对象指针。零大小对象、包级变量初始化阶段得到的对象，以及某些很小且无指针对象的批量分配，都不能拿“最终一定执行”来设计资源回收。

为什么最后一次使用不等于仍然存活

Go 编译器可以在语义允许的地方提前判断一个局部变量已经没有后续用途。尤其是把对象内部字段传给系统调用时，调用表达式可能只使用了一个整数句柄，而不是继续使用对象指针本身。从源码阅读者的角度看，对象还在函数栈上；从垃圾回收器的可达性角度看，它可能已经没有必须保留的引用。

下面的写法把风险点藏在了“最后一次使用”里：

func writeOnce(r *NativeResource, buf []byte) error {
	// 这里读取的是句柄字段，调用方不一定继续使用 r 指针。
	if err := writeNativeHandle(r.fd, buf); err != nil {
		return err
	}

	// 如果后面还会访问 r，生命周期边界仍然不够直观。
	return nil
}

这不表示每次调用都必然出错，也不表示 KeepAlive 应该到处添加。判断标准只有一个：底层操作结束以前，是否仍依赖这个对象携带的资源。如果答案是“依赖”，就应该在该操作完成后明确保活；如果答案是“不依赖”，就不必为了延迟 GC 而滥用 KeepAlive。

把 KeepAlive 放在真正的保活终点

runtime.KeepAlive(x) 的作用很窄：把 x 标记为当前可达，保证它的 finalizer 不会在这条调用之前运行。它不是锁，不会等待 finalizer，也不会把对象永久保活。最重要的位置，是所有依赖对象内部资源的操作已经返回之后：

func writeOnce(r *NativeResource, buf []byte) error {
	// 系统调用仍然通过 r.fd 使用外部句柄。
	err := writeNativeHandle(r.fd, buf)

	// 把“资源至少活到系统调用返回”写成明确的生命周期终点。
	runtime.KeepAlive(r)

	if err != nil {
		// 先返回底层错误，调用方仍可决定是否重试或关闭资源。
		return err
	}
	return nil
}

如果调用有多个返回路径，KeepAlive 要放在所有路径都经过的位置，或者在每个仍依赖资源的分支中保持同样的语义。不要把它放在系统调用之前，也不要仅凭 defer runtime.KeepAlive(r) 代替对资源边界的理解；延迟调用适合表达函数退出前仍需保活的场景，但资源使用的真正终点仍然应该清楚可见。

finalizer 还有哪些工程边界

把 KeepAlive 加对，只能解决“过早不可达”这一类问题，不能把 finalizer 变成可靠的资源管理协议。下面几条边界需要一起考虑。

• 不保证在进程退出前执行。 finalizer 的调度时间是不确定的，短命命令或服务退出时不能依赖它完成刷新、提交或关闭。
• 一个程序中的 finalizer 由单个 goroutine 顺序运行。 finalizer 内做慢 I/O、锁等待或复杂业务，会拖慢其他对象的兜底清理。
• 有依赖关系时不应假设顺序。 一个带 finalizer 的对象引用另一个同样带 finalizer 的对象，运行时要遵守依赖；环形结构则不能指望 finalizer 一定被回收。
• finalizer 读取可变状态仍需要同步。 SetFinalizer 与 finalizer 的调用之间有同步语义，但 KeepAlive 并不替代互斥锁或原子操作；主 goroutine 修改字段、finalizer 读取字段时仍要避免数据竞争。
• 显式释放仍然是主路径。 文件、连接、锁和事务应通过 Close、Unlock、Commit/Rollback 等明确动作结束；finalizer 只适合作为长时间运行程序里的兜底。

当前 runtime 文档也提示新代码优先评估 runtime.AddCleanup。无论选择哪种兜底 API，结论都一样：非内存资源的确定性生命周期不能交给 GC 时机。

把选择落到一张小清单

排查时可以沿着“对象指针—内部句柄—底层调用—显式释放”这条链逐项问：调用完成前对象是否必须可达？finalizer 是否可能关闭同一句柄？正常路径是否有明确 Close？finalizer 里是否做了耗时或并发不安全的工作？这四个问题通常比反复手动触发 GC 更快接近根因。

常见追问

KeepAlive 会不会阻止对象最终回收？

不会。它只把对象保活到调用点；调用返回后，如果没有其他引用，对象仍可在后续 GC 中变成不可达。

调用了 SetFinalizer 就一定会执行清理吗？

不一定。对象可能在进程退出前都没有得到调度，也可能受对象形态、依赖关系、循环引用或分配优化影响。确定性释放必须由业务代码完成。

finalizer 里能不能直接修改业务状态？

可以有这种设计，但必须把它当作异步并发代码处理：保护共享字段，避免长时间阻塞，并且不要把它当作主流程的成功确认信号。

归根结底，SetFinalizer 回答的是“对象不可达后如何兜底”，KeepAlive 回答的是“对象至少要活到哪里”。把这两个问题和显式资源释放分开，才能既避免句柄提前关闭，也避免把 GC 误当成确定性的析构机制。