Go SetFinalizer 为什么不能保证进程退出前执行

我曾经写过一个很短的 Go 工具，把缓冲区的 Flush 放进 runtime.SetFinalizer，以为 main 返回前运行时会“顺手清理”。结果文件偶尔是空的。问题不在 finalizer 写错了，而在我把垃圾回收的兜底机制误当成了进程退出钩子。

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

SetFinalizer 只能安排对象在变为不可达后由运行时择机执行 finalizer；Go 不保证进程退出前会执行它。凡是必须刷盘、提交事务、发送确认、释放额度或完整关闭的动作，都应由显式 Close、defer 或受控 shutdown 完成。

先确认是不是把 finalizer 当成退出钩子

下面这种写法看上去给缓冲区加了保险，实际上把数据完整性押在一次不保证发生的回调上：

package main

import (
    "bufio"
    "os"
    "runtime"
)

func main() {
    f, _ := os.Create("report.txt")
    w := bufio.NewWriter(f)

    // 错误示例：finalizer 不能承担退出前刷盘责任
    runtime.SetFinalizer(w, func(w *bufio.Writer) {
        _ = w.Flush()
    })

    _, _ = w.WriteString("important result\n")
    // main 很快返回，进程不会等待 finalizer
}

即使这段程序在某些运行中写出了内容，也不能说明设计正确。对象可能一直到 main 返回时仍可达，短命进程也可能根本没有触发一次能发现它的 GC；即便 GC 已经发现对象，finalizer 仍只是被调度，进程没有义务等它跑完。

finalizer 执行前要跨过四道门

理解这个问题的关键，是把“注册成功”和“回调执行”分开。调用 SetFinalizer(obj, f) 只建立关联，后面至少还依赖四件事：

1. 程序不再能从根对象追踪到 obj，对象真正变为不可达；
2. 垃圾回收器开始一轮回收并发现这个不可达对象；
3. 运行时清除关联并把 finalizer 安排到执行路径；
4. 负责 finalizer 的 goroutine 获得调度并实际运行回调。

进程退出可以发生在任何一道门之前。Go 的 runtime 文档因此明确说明：finalizer 会在对象不可达后的某个任意时间被安排执行，并不保证在程序退出前运行。所有 finalizer 还由单个 goroutine 顺序执行；如果某个回调阻塞或耗时，后面的回调也会继续等待。

按未执行原因逐层检查

对象在退出时仍然可达

对象只要还能从全局变量、活跃栈或其他可达对象追踪到，就不会进入 finalizer 调度。把指针放进全局缓存、map、闭包或长期 goroutine，都会延长它的生命周期。此时手动调用几次 runtime.GC() 也没有用，因为 GC 不会把仍然可达的对象当成垃圾。

进程太短，GC 和调度来不及完成

命令行工具常见的路径是分配对象、完成少量工作、马上返回。没有内存压力时，程序可能不需要触发 GC；即使显式触发 GC，它也只是增加发现和调度的机会，不会把 finalizer 变成同步调用，更不会建立退出前完成的契约。

对象本身落在不保证执行的边界

官方文档还列出几个容易忽略的边界：零大小对象可能与其他零大小对象共享地址；包级变量初始化阶段创建的对象可能由链接器分配；很小且不含指针的对象可能与其他对象批量放在同一分配槽中；带 finalizer 的循环引用也可能因为无法建立依赖顺序而不被回收。这些情况都说明 finalizer 不是业务完成信号。

回调被前面的 finalizer 拖住

所有 finalizer 顺序执行。如果一个 finalizer 做网络请求、等待锁或执行长任务，其他回调会排在后面。需要长时间处理时，文档建议 finalizer 自己启动新的 goroutine，但这依旧不能提供进程退出前完成保证，也不适合承载关键业务动作。

必须完成的资源清理改成显式 Close

我后来把规则改得很简单：资源由谁创建，谁就负责在清晰的控制流里关闭；finalizer 只能作为泄漏后的兜底。缓冲写入应当显式 Flush，文件也应显式关闭，并把错误返回给调用方：

package report

import (
    "bufio"
    "fmt"
    "os"
)

func Write(path string) (err error) {
    f, err := os.Create(path)
    if err != nil {
        return fmt.Errorf("create report: %w", err)
    }

    // 兜底关闭文件，并保留此前更重要的写入错误
    defer func() {
        if closeErr := f.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close report: %w", closeErr)
        }
    }()

    w := bufio.NewWriter(f)
    if _, err = w.WriteString("important result\n"); err != nil {
        return fmt.Errorf("write report: %w", err)
    }

    // Flush 是数据完整性要求，必须在正常控制流中检查
    if err = w.Flush(); err != nil {
        return fmt.Errorf("flush report: %w", err)
    }
    return nil
}

这里的区别不是“defer 比 finalizer 更快”，而是责任边界不同：函数正常返回时会执行 defer，调用方也能获得 Flush 或 Close 错误。若代码直接调用 os.Exit，defer 同样不会运行，因此服务和 CLI 应让主流程正常返回，而不是在深层函数突然退出进程。

长运行服务要有受控 shutdown

服务进程通常需要处理 SIGTERM 或中断信号，再按顺序停止接收请求、等待在途任务、刷新缓冲区并关闭资源。关键动作仍然由业务代码调用，不交给 GC：

package main

import (
    "context"
    "log"
    "os"
    "os/signal"
    "syscall"
)

type Store interface {
    Close() error
}

func run(ctx context.Context, store Store) error {
    // 业务循环在收到取消信号后退出
    

这类 shutdown 可以测试，也能设置超时和记录错误。它仍然无法处理 SIGKILL、机器掉电等强制终止，因此需要事务、原子替换、预写日志等持久化设计兜底；finalizer 更不可能解决这些场景。

KeepAlive 和 AddCleanup 也不是退出保证

runtime.KeepAlive(x) 解决的是另一个问题：编译器和 GC 可能在函数最后一次使用对象之后就认为它不可达，导致 finalizer 过早关闭对象内部资源。把 KeepAlive(x) 放在必须完成的底层调用之后，可以延长对象的可达性；它不会强制 finalizer 运行，也不会让退出过程等待回调。

Go 1.24 引入了 runtime.AddCleanup。官方建议新的 Go 代码优先考虑 cleanup，因为它比 SetFinalizer 更灵活，也避免把原对象传给回调造成的复活问题。不过 runtime 文档同样明确：cleanup 不保证执行，尤其不保证在进程退出前运行。它适合回收 C 分配的内存、mmap 等外部内存资源的兜底，仍不应负责刷写业务数据或提交事务。

退出前检查清单

• 搜索 SetFinalizer 与 AddCleanup，确认回调里没有 Flush、Commit、Ack 或必须发送的网络请求。
• 为文件、连接、锁句柄和外部内存提供幂等的 Close 或 Release。
• 让资源所有者在正常返回路径中调用清理，并处理清理错误。
• 服务通过信号触发受控 shutdown，限制等待时间并记录失败。
• 不要用 runtime.GC() 加 sleep 的测试结果证明退出保证。
• 需要 finalizer 或 cleanup 时，只把它当泄漏兜底，并让回调短小、线程安全。

常见问题

在 main 结束前调用 runtime.GC 能保证 finalizer 执行吗？

不能。它可能促使 GC 发现不可达对象，但 finalizer 仍需排队和调度，对象也可能仍然可达或落在不保证执行的边界。正确性不能依赖这条路径。

defer 是否一定比 SetFinalizer 可靠？

在函数正常返回或 panic 展开栈时，defer 具有明确的控制流语义；但 os.Exit、SIGKILL 和掉电不会执行它。关键持久化逻辑仍要考虑异常终止。

AddCleanup 能替代显式 Close 吗？

不能。它是更安全的 GC 关联清理机制，不是进程退出钩子。凡是有明确生命周期和错误结果的资源，仍应显式关闭。

SetFinalizer 适合什么场景？

它只适合作为长运行程序中非内存资源泄漏的最后兜底，或者少数需要复杂析构顺序的高级实现。大多数业务代码应优先使用清晰的所有权与显式释放。