Go runtime.SetFinalizer 为什么不适合当资源关闭器：可达性与回收时机验证

临时文件清理偶尔失效时，很多人会把 runtime.SetFinalizer 当成“对象不用了就自动关闭”的保险栓。实际排查后会发现，回调触发依赖对象可达性和垃圾回收时机，既不能替代资源所有权，也不能给文件、连接设置可靠的释放时间。

runtime.SetFinalizer 适合做兜底提醒或补救性清理；需要在某个业务步骤结束时释放资源，仍应显式调用 Close，并用 runtime.KeepAlive 保护仍在使用的对象。

问题不是回调能不能执行，而是何时执行

一个导出临时报告的服务在请求结束后留下了几批文件。最初的改法是给包装对象挂 finalizer，期待下一轮 GC 把文件清掉。这个思路的问题很快暴露出来：没有 GC，就没有可观察的回调时点；即使触发了 GC，也不能把回调时间当成业务上的“请求已结束”时间。

package main

import "runtime"

type tempReport struct {
    path string
}

func watchReport(report *tempReport) {
    runtime.SetFinalizer(report, func(r *tempReport) {
        println("回调执行:", r.path)
    })
}

这里真正发生的事情只有一件：SetFinalizer 登记了 回调执行。它没有把 path 变成一个定时任务，也没有保证进程退出前一定完成清理。生产代码如果把删除动作、连接归还或事务收尾全部压在这条路径上，故障时很难复盘。

用一个可复现实验看清可达性边界

为了验证判断，可以在测试程序里显式调用 runtime.GC，但要把它看成实验工具，不要把它当业务流程。下面的代码故意先把引用交给 watchReport，再让对象失去可达性；实验只能帮助观察回调是否出现，不能证明线上会在同样时间执行。

func runExperiment() {
    report := &tempReport{path: "./tmp/report.txt"}
    watchReport(report)
    report = nil
    runtime.GC()
}

report = nil 只是让这段代码不再持有引用，runtime.GC 提供一次尝试回收的机会。若把同样的对象交给底层系统调用，编译器可能判断最后一次显式使用已经结束，因此需要在调用后用 runtime.KeepAlive 把“仍然使用到这里”写清楚。

把显式 Close 放回资源生命周期

文件资源的正常路径应该由拥有它的函数负责关闭。finalizer 可以作为异常兜底，但不应成为唯一出口。下面的写法把“打开—使用—关闭”放在同一条调用链里，读者也能从错误返回判断哪一步失败。

func writeReport(path string, data []byte) error {
    file, err := os.Create(path)
    if err != nil {
        return err
    }
    defer file.Close()

    if _, err := file.Write(data); err != nil {
        return err
    }
    runtime.KeepAlive(file)
    return nil
}

这里的 Close 是业务可预测的：函数返回前会执行，写入失败也不会跳过 defer。runtime.KeepAlive 不负责关闭文件，它只用于表达对象在某个底层操作前后仍然活着；如果代码已经有清晰的 Go 引用和普通方法调用，别为了“看起来安全”到处添加它。资源仍在使用时，先保证关键调用完成，再进入 Close；不要把可能延后的回调执行当作关闭证明。

迁移时只保留 finalizer 的兜底角色

把旧实现改成显式关闭时，先列出资源的真正拥有者，再将释放动作放进拥有者的函数边界。若包装类型确实需要检测遗漏，可以保留 finalizer 记录诊断日志，但日志里要说明这是遗漏信号，而不是正常清理证明。

这一步的取舍很朴素：确定性资源用确定性 API，GC 回调只处理无法在正常路径解决的遗漏。别为了让测试“最终会变绿”而在测试里反复调用 runtime.GC，那只能改变实验条件，不能让 finalizer 变成可靠调度器。

相关问题

调用 runtime.GC 后一定能看到 finalizer 吗？

不一定。对象是否可达、回调登记条件、程序是否仍在运行都会影响结果，GC 只能提供一次回收尝试。

runtime.KeepAlive 会阻止对象被回收吗？

它把对象的可达性延长到指定调用点，适合表达底层操作仍需要对象的边界，但不等于资源关闭，也不替代 Close。

finalizer 完全不能用吗？

可以用于诊断遗漏或做低可靠性的兜底清理，但不要把它用于请求级收尾、连接池归还或任何有明确时间要求的释放动作。

小结

runtime.SetFinalizer 解决的是“对象最终可能被回收时做点事”，而不是“业务步骤结束时马上释放资源”。用 Close 管理正常生命周期，用 runtime.KeepAlive 表达必要的使用边界，再把 finalizer 限定为诊断和兜底，代码的行为才可测试、可解释。