runtime finalizer 为什么不能当作确定性清理机制

如果资源必须在某个确定的时间释放，就不要把 runtime.SetFinalizer 当作析构函数。finalizer 只有在对象被垃圾回收器判定为不可达后才可能被调度，而且执行时间可能很晚，进程退出前也不保证一定执行。文件、网络连接、锁和系统句柄的主清理路径应该由业务代码显式负责。

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

可以把它记成一句工程规则：显式关闭负责确定性，finalizer 只负责兜底提醒；最后一次底层调用还依赖对象时，再用 runtime.KeepAlive 延长可达性。下面沿着对象与资源的生命周期拆开这个边界。

先区分对象回收与外部资源释放

Go 的垃圾回收器管理的是 Go 堆上的对象，而文件描述符、网络连接、内存映射和操作系统句柄属于另一套资源系统。一个 Go 包装对象变得不可达，并不等于外部资源应该“现在”释放。

因此，finalizer 解决的是“对象已经没人引用时，是否还有机会补做一次清理”，而不是“资源在什么时候必须关闭”。两者的责任边界不能混在一起。

拆开 SetFinalizer 的生命周期

runtime.SetFinalizer(obj, fn) 会把一个回调关联到对象。当垃圾回收器发现对象不可达时，runtime 会清除这层关联，并在独立 goroutine 中运行回调；回调执行时对象会暂时重新变得可达。这个过程至少包含三个不应被业务逻辑依赖的时间点：

1. 对象何时变得不可达，可能早于函数的直觉终点，也可能晚于预期。
2. 垃圾回收器何时扫描到它，没有固定的业务时间表。
3. finalizer goroutine 何时获得执行机会，受调度和进程是否继续运行影响。

如果对象形成带 finalizer 的循环引用，官方文档还明确指出，这个循环不保证能够被回收，finalizer 也不保证执行。即便没有循环，程序退出时也不能把 finalizer 当成必达的收尾逻辑。

package main

import (
    "fmt"
    "runtime"
)

type BufferOwner struct {
    id string
}

func main() {
    owner := &BufferOwner{id: "request-17"}

    // finalizer 只能作为遗漏清理的兜底提醒，不能承诺执行时间。
    runtime.SetFinalizer(owner, func(v *BufferOwner) {
        fmt.Println("fallback cleanup:", v.id)
    })

    // 这里显式解除引用只是示意；不能据此推断回调会立刻执行。
    owner = nil
    runtime.GC()
}

这个示例的重点不是观察某一次输出，而是理解 API 契约：调用 runtime.GC 也不能把 finalizer 变成确定性的业务回调。真实程序不应靠打印日志、睡眠或反复触发 GC 来“等待”资源释放。

用显式关闭建立确定性路径

资源包装类型应该提供明确的关闭操作，并让拥有它的函数在成功获取资源后尽快安排 defer。这样释放时机由函数控制流决定；如果关闭失败，还可以沿着返回值、日志或监控路径处理错误，而不是把错误藏在 finalizer goroutine 中。

func readConfig(path string) ([]byte, error) {
    f, err := os.Open(path)
    if err != nil {
        return nil, err
    }
    // 获取成功后立即登记关闭，保证函数返回时释放文件描述符。
    defer f.Close()

    data, err := io.ReadAll(f)
    if err != nil {
        return nil, err
    }
    // 返回前由 defer 执行 Close；资源释放不依赖下一次 GC。
    return data, nil
}

如果关闭本身的错误必须被调用方感知，就应把它显式合并到返回值，而不是假设 finalizer 会替你补报。例如写入器要先处理 Flush，再处理 Close；这类顺序属于业务协议，不适合交给 GC。

用 KeepAlive 防止最后一次调用过早失去对象

还有一种更隐蔽的风险：函数参数或接收者在最后一次被 Go 代码使用后，可能已经不再被认为是可达对象。若 finalizer 负责关闭底层句柄，而后面的系统调用仍在使用这个句柄，就可能出现调用尚未结束、资源却已被关闭的情况。

func writeNative(f *File, data []byte) error {
    n, err := syscall.Write(f.fd, data)
    // 明确把对象的最后使用点放在系统调用之后，避免 finalizer 过早关闭 fd。
    runtime.KeepAlive(f)
    if err != nil {
        return err
    }
    if n != len(data) {
        return io.ErrShortWrite
    }
    return nil
}

KeepAlive 只解决“对象在这次调用期间仍需可达”的问题，不会把 finalizer 变成确定性清理机制，也不会替代显式的 Close。它应该紧贴最后一次依赖对象的系统调用放置。

什么时候才考虑 finalizer 或 AddCleanup

对于可预测的资源生命周期，优先级可以按下面的顺序判断：

1. 能由调用方决定结束点：提供 Close、Stop 或归还接口，并在拥有资源的作用域中用 defer 安排。
2. 底层调用可能提前失去可达性：在最后一次调用后使用 runtime.KeepAlive。
3. 需要防止遗漏但不能依赖时间：才把 finalizer 作为兜底清理或诊断信号，并保证回调足够短、线程安全。
4. 新代码需要 runtime 提供的清理辅助：先阅读当前版本 runtime.AddCleanup 文档，确认它的语义适合你的对象关系，再决定是否采用。

当前 runtime 文档已经建议新代码考虑 AddCleanup，理由是它比 SetFinalizer 更不容易误用。但这并不改变核心结论：只要业务要求“在这里释放”，就应该把释放动作放在显式控制流中，而不是等待回收器。

结论：把清理责任写回拥有者

finalizer 不是 Go 版析构函数。它的触发依赖对象可达性、GC 扫描、调度以及进程是否继续运行，因此无法提供资源释放的时间保证。工程上更稳妥的分工是：拥有者通过显式接口和 defer 负责主路径，KeepAlive 保护最后一次底层调用，finalizer 只做遗漏兜底；采用其他 runtime 清理 API 前也要按当前官方文档确认语义。

常见追问

调用 runtime.GC 后 finalizer 就一定会执行吗？

不一定。GC 请求不等于业务层面的 finalizer 完成通知，循环引用、对象形态和程序退出都可能影响结果。

finalizer 能不能代替 defer Close？

不能。defer Close 绑定的是函数控制流，finalizer 绑定的是 GC 发现不可达后的运行时调度，两者的确定性不同。

KeepAlive 会延长外部资源的生命周期吗？

它只保证对象在指定调用点之后仍被视为可达，不负责关闭或续期外部资源；资源释放仍由显式接口负责。

finalizer 里可以执行很重的清理吗？

不建议。finalizer 由程序中的单独 goroutine 依次运行，长时间工作会拖延其他 finalizer；更重要的清理应改成显式流程。