Go runtime.SetFinalizer 怎样解释对象未及时回收

如果给 Go 对象设置了 runtime.SetFinalizer，却迟迟看不到清理动作，通常不是“垃圾回收失效”，而是把 finalizer 误当成了定时器。它只有在对象变得不可达、垃圾回收器发现它并把 finalizer 排入运行队列后才可能执行；这个时间没有实时保证，进程退出前也不保证执行。

官方文档：https://pkg.go.dev/runtime

排查顺序应是：对象是否仍可达、finalizer 是否被闭包或引用环重新连回对象、GC 是否只是尚未发生、finalizer 队列是否拥堵，以及程序是否已经退出。

SetFinalizer 什么时候才会运行

SetFinalizer(obj, fn) 关联的是一个对象和一个清理函数。GC 发现对象不可达后，会先清除这层关联，再在独立 goroutine 中调用函数；调用过程又会让对象暂时重新可达，之后还需要再次被发现不可达，内存才可能真正释放。因此，设置 finalizer 到执行之间不是固定延迟。

它更适合给操作系统句柄提供兜底释放，而不适合承担业务提交、日志落盘或必须按时完成的任务。正常路径仍应显式调用 Close、Stop 或项目自己的释放方法。

先查对象是不是仍然可达

最常见的原因是程序中还留着引用。全局变量、长期存活的缓存、后台 goroutine 闭包都可能让对象继续可达。下面的写法把外层对象捕获进 finalizer，形成了自引用路径，清理函数反而可能阻止对象被回收：

type Resource struct {
    fd int
}

func wrong(r *Resource) {
    // 不要在闭包里捕获 r；这条引用可能让 finalizer 仍能找到对象。
    runtime.SetFinalizer(r, func(_ *Resource) {
        // 错误示例：直接读取外层 r 的字段。
        closeFD(r.fd)
    })
}

func right(r *Resource) {
    fd := r.fd
    // 只捕获独立值，避免 finalizer 函数重新持有整个对象。
    runtime.SetFinalizer(r, func(_ *Resource) {
        closeFD(fd)
    })
}

自引用结构和带 finalizer 的引用环也会造成类似结果。另一个容易忽略的边界是：零大小对象、包级变量初始化出来的对象，以及和仍存活的小对象共享分配槽的对象，都不适合用“最终一定会执行”来推断结果。

GC、队列和进程退出要分开判断

调用 runtime.GC() 也不能把 finalizer 当成同步函数等待。GC 负责发现并排队，真正的 finalizer 由一个 goroutine 依次执行；某个 finalizer 很慢，会让后面的清理继续等待。可以用运行时指标观察 queued 与 executed 的差距，但它们只能帮助定位趋势，不能把执行时间变成契约。

还要检查程序是否在等待清理前就结束了。Go 不保证进程退出前运行所有 finalizer，所以命令行程序或短生命周期测试很容易“看不到输出”。不要用 sleep 让生产逻辑碰运气，也不要让关键数据落盘依赖 finalizer。

把清理职责放回正确的位置

有三类问题不要混在一起：

• 资源必须及时关闭：让调用方显式调用 Close，finalizer 只做兜底。
• 对象在系统调用期间不能过早失活：在最后一次底层调用之后使用 runtime.KeepAlive(obj)，防止 finalizer 提前关闭句柄。
• 只需要弱化的兜底清理：新代码优先评估 runtime.AddCleanup，它比 SetFinalizer 更不容易形成对象回指；仍要设计好退出和并发边界。

func readFD(r *Resource, buf []byte) error {
    // 底层调用只拿到了 fd，编译器可能认为 r 已经不再使用。
    if err := syscallRead(r.fd, buf); err != nil {
        return err
    }
    // 保证 finalizer 不会在 syscallRead 返回前关闭 fd。
    runtime.KeepAlive(r)
    return nil
}

相关问题

为什么手动调用 runtime.GC 仍然没有 finalizer 日志？因为 GC 只负责发现和排队，队列执行还要经过调度；如果对象仍可达或进程很快退出，也不会得到预期日志。

finalizer 能不能替代 Close？不能。它没有时限保证，且单个慢 finalizer 会影响队列中的其他任务。

KeepAlive 是让对象更快回收吗？不是。它只延长对象到指定位置的可达性，防止资源在最后一次底层使用前被 finalizer 提前处理。