Go runtime.SetFinalizer 什么时候会失效：对象可达性、GC 时机与资源回收边界

给文件、连接或 mmap 包一层 Go 对象时，最容易出现一个错觉：只要调用 runtime.SetFinalizer，对象被 GC 后资源就一定会被收回。实际情况恰好相反，终结器只适合兜底和发现遗漏，不能替代明确的 Close；它什么时候运行、是否运行，以及运行前对象还是否可达，都不适合拿来当业务时钟。

先把“对象被回收”和“资源被关闭”分开

Go 的 GC 管的是堆上的对象；文件描述符、socket、外部句柄和内存映射则属于运行时之外的资源。一个结构体变得不可达，只能说明程序不再通过 Go 指针访问它，并不等于内核已经收到关闭请求。

runtime.SetFinalizer 的触发条件是 GC 发现对象不可达，并把终结器安排到单独的 goroutine 中执行。中间隔着 GC 周期、调度和终结器队列，所以不能写出“函数返回后马上关闭”的假设。

原始做法为什么在压力下变得不可控

下面这个示例可以帮助定位误区，但不要把它当成生产资源管理方案。创建对象后立刻丢掉引用，并不会给测试代码一个“马上执行 finalizer”的保证。

package main

import (
    "fmt"
    "runtime"
    "time"
)

type Handle struct {
    name string
}

func main() {
    h := &Handle{name: "report"}
    runtime.SetFinalizer(h, func(v *Handle) {
        fmt.Println("finalizer:", v.name)
    })
    h = nil
    runtime.GC()
    time.Sleep(10 * time.Millisecond) // 仅用于演示，不是同步手段
}

这里即使偶尔看到了输出，也只能证明这次运行中终结器被安排并执行了。把 time.Sleep 改成固定等待并不能修复竞态；程序退出、GC 时机和调度顺序都可能改变结果。

把显式 Close 放在主路径，终结器只做兜底

更稳妥的结构是：资源对象自己保存关闭状态，Close 负责真正释放，终结器只在调用方忘记关闭时发出诊断或执行最后的兜底动作。关闭动作要幂等，因为显式关闭和兜底关闭可能先后发生。

package resource

import (
    "errors"
    "runtime"
    "sync"
)

var ErrClosed = errors.New("resource is closed")

type Resource struct {
    mu     sync.Mutex
    closed bool
    fd     int
}

func New(fd int) *Resource {
    r := &Resource{fd: fd}
    runtime.SetFinalizer(r, (*Resource).finalize)
    return r
}

func (r *Resource) Close() error {
    r.mu.Lock()
    defer r.mu.Unlock()
    if r.closed {
        return nil
    }
    r.closed = true
    // 在这里调用真实的 fd.Close 或平台释放函数。
    runtime.SetFinalizer(r, nil)
    return nil
}

func (r *Resource) finalize() {
    _ = r.Close()
}

真实代码中应把底层句柄封装为可检查错误的类型，并在 Close 中记录释放失败。示例重点是生命周期：显式关闭成功后立即用 SetFinalizer(r, nil) 移除终结器，避免无意义的后续工作。

几个容易忽略的可达性边界

最后一次使用不等于函数末尾

编译器可能在函数剩余代码中不再需要某个指针时，把它视为不可达。若终结器与一段外部调用之间存在先后要求，应在最后一次使用之后调用 runtime.KeepAlive，明确告诉运行时这个对象至少要活到该位置。

useNative(r.fd)
runtime.KeepAlive(r)

终结器不要重新抓住拥有者

终结器应只接收必要的轻量状态，避免在回调里把拥有者放入全局队列、启动无法收敛的后台任务，或通过闭包重新持有资源对象。否则释放边界会变得更难推断，甚至形成新的可达路径。

不要用终结器顺序编排业务

多个对象之间如果有依赖关系，不要期待终结器按创建顺序或反向顺序执行。依赖资源应由同一个拥有者显式协调关闭，或者通过 defer 组合清晰表达。

上线前用一张表检查资源释放策略

• 调用方是否知道谁拥有资源，并在成功创建后立刻登记 defer Close？
• Close 是否幂等，重复调用是否不会破坏错误处理？
• 显式关闭后是否移除了 finalizer，避免把正常路径拖进 GC 队列？
• 是否把终结器当成监控/诊断补偿，而不是连接池、事务或锁的计时器？
• 测试是否验证了关闭结果，而不是仅等待日志打印？

相关问题

SetFinalizer 能保证程序退出前释放文件吗？

不能。进程退出时未执行的终结器可能来不及运行，关键文件和连接必须显式关闭。

为什么调用 runtime.GC 后仍看不到终结器输出？

GC 只推动可达性判断，终结器还要等待运行时调度；对象仍可能可达，或者程序在回调运行前就结束。

终结器和 defer 应该怎么选？

同一作用域内由调用方拥有的资源优先用 defer Close；只有无法可靠约束所有调用方时，才把终结器作为最后的补偿机制。

结语

SetFinalizer 解决的是“对象遗失后还有没有补救机会”，不是“资源何时释放”。把所有权、显式 Close、幂等状态和必要的 KeepAlive 先设计清楚，终结器才能退回它适合的位置：发现遗漏，偶尔兜底，而不是替业务代码做生命周期管理。