Go runtime.SetFinalizer 为什么不能当作可靠资源释放器

如果一个 Go 对象背后握着文件描述符、套接字或 C 内存，runtime.SetFinalizer 不能当作唯一的释放方案。它只会在 GC 发现对象不可达后，于某个不确定的时间排队执行；进程退出前不保证执行，runtime.GC() 也只保证把任务排队，不能保证最终化器已经跑完。可靠的主路径应当是显式 Close，最终化器最多负责兜底和暴露遗漏。

先把 SetFinalizer 放回它该在的位置

SetFinalizer(obj, finalizer) 绑定的是“对象死亡后的补救动作”，不是“函数返回时的清理动作”。对象变得不可达后，GC 才可能发现它；随后运行时清除关联并在独立 goroutine 中调用最终化器。这个时间点由 GC 节奏决定，既不是 defer 的倒序时机，也不是请求结束的明确时机。

所以可以这样判断：只要资源耗尽会让下一次打开、连接或分配失败，就不能等最终化器。文件描述符上限、连接池配额和 C 内存压力都属于运行时未必知道的外部约束，应该在业务边界显式处理。

为什么 GC 触发时间不能等同于资源释放时间

官方文档列出了几个很容易被忽略的边界。最终化器可能在任意遥远的未来执行，程序退出时可能根本不执行；带最终化器的对象如果形成引用环，回收和最终化器执行都没有保证；最终化器还可能让对象在调用期间重新变得可达。

更隐蔽的是，最后一次使用对象的地方可能比人眼看到的代码更早。若最终化器负责关闭底层描述符，传入系统调用后对象可能已经被判定为不可达，应在真正不再需要它之后调用 runtime.KeepAlive：

type NativeFile struct {
    fd int
}

func writeNativeFile(f *NativeFile, data []byte) error {
    _, err := syscall.Write(f.fd, data)
    // 让 f 至少存活到系统调用返回，避免最终化器过早关闭 fd。
    runtime.KeepAlive(f)
    return err
}

KeepAlive 只解决“不能过早运行”的可达性问题，不会让最终化器变成同步释放接口。即使紧接着调用 runtime.GC()，也不能把它当作“现在已经关闭”的证明。

把显式 Close 和最终化器写成两条边界

一个可复用的包装类型可以把释放动作收口到 Close。用 sync.Once 或原子状态保证重复关闭不会再次操作底层资源；显式关闭成功后清掉最终化器，避免兜底路径重复执行。

type Handle struct {
    fd   int
    once sync.Once
    err  error
}

func NewHandle(fd int) *Handle {
    h := &Handle{fd: fd}
    runtime.SetFinalizer(h, func(h *Handle) {
        // 最终化器只兜底；生产代码应记录遗漏而不是承载业务时限。
        _ = h.close()
    })
    return h
}

func (h *Handle) close() error {
    h.once.Do(func() {
        // 只让一个调用真正关闭 fd，避免 Close 与兜底路径双重释放。
        h.err = syscall.Close(h.fd)
    })
    return h.err
}

func (h *Handle) Close() error {
    err := h.close()
    if err == nil {
        // 主路径已经完成释放，不再保留最终化器。
        runtime.SetFinalizer(h, nil)
    }
    return err
}

这里的关键不是把最终化器写得更复杂，而是把责任分层：调用方通过 defer h.Close() 或显式生命周期完成确定性释放；最终化器只处理程序员漏关的情况。若资源释放需要返回错误，最终化器没有合适的调用方接收错误，更不能替代显式 API。

复查这几个最容易误判的边界

Go 1.24 及以后，官方 GC 指南更建议优先考虑 runtime.AddCleanup，因为它比最终化器限制更少、出错面更小。但这不会改变资源 API 的基本原则：能确定释放时机，就提供并调用显式关闭方法；清理机制只做最后一道保险。

常见问题

SetFinalizer 能不能保证程序退出前关闭文件？

不能。官方文档明确没有这种保证。需要在退出前落盘、刷新或关闭的资源，必须由业务路径显式处理。

runtime.GC 调用返回后最终化器一定执行了吗？

不一定。它只会等待不可达对象被排入清理队列，测试应自行提供完成通知并等待回调结束。

显式 Close 后还需要 SetFinalizer 吗？

封装底层资源时可以保留它作为遗漏兜底，但成功 Close 后应清除最终化器，并保证 Close 与兜底逻辑幂等。

什么时候更适合用 runtime.KeepAlive？

当对象承载的底层资源要跨过一次系统调用或非 Go 调用继续有效时使用。它延长可达性，不负责释放资源。