Go finalizer 设置在短命对象上为什么可能不运行

我第一次遇到这个问题，是把一个很快就失去引用的 Go 对象交给 runtime.SetFinalizer，然后立刻等待日志。日志没有出现，并不等于 GC 出错：finalizer 只会在对象不可达后，于运行时选择的时间排队执行，进程退出前也没有执行保证。短命对象尤其容易把“已经不可达”“已经排队”和“回调已经跑完”混成一件事。

为什么短命对象的 finalizer 可能一直看不到

SetFinalizer(obj, f) 记录的是一个运行时兜底动作，不是析构函数。GC 发现对象不可达后，会清掉关联并把 f(obj) 放进 finalizer 队列；对象还会因为传给回调而短暂“复活”，回调结束后还要经过后续回收。这个过程没有固定延迟。

我现在排查时先问三个问题：最后一个引用是否真的消失？回调是否只是排队还没执行？程序是不是很快返回了？finalizer 由一个运行时 goroutine 顺序处理，前一个回调阻塞时，后面的短命对象也会继续等待。

先检查对象形态，再判断是不是代码问题

官方文档明确列出了几类“不保证运行”的情况。零大小对象可能和别的零大小对象共享地址；包级变量初始化阶段创建的对象可能由链接器安排，不在堆上；很小且无指针的对象可能被运行时批量放进同一个分配槽，槽里只要还有存活对象，单个 finalizer 就可能没有机会触发。

引用环也很关键。对象自己通过字段指回自己，或者一串带 finalizer 的对象互相相连，GC 没有满足依赖顺序的回收办法，回调就不能当作必然事件。短命程序还有一个更直接的边界：进程退出不会等待 finalizer。

把“验证回调”与“释放资源”分开

测试 finalizer 时不要把打印日志当断言，也不要写成“调用一次 GC 就结束”。可以用带超时的通道等待回调；超时只能说明在测试窗口内没有完成，不能证明对象永远不会回收。

package main

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

type handle struct{ id int } // 保留非零字段，避免把零大小边界混进示例

func main() {
    done := make(chan struct{})
    h := new(handle)
    runtime.SetFinalizer(h, func(*handle) {
        close(done) // 只发送测试信号，不在这里承担关键业务提交
    })
    h = nil
    runtime.GC() // 这一步只促使运行时发现不可达对象并排队

    select {
    case 

生产代码里，文件、连接、锁和映射等外部资源仍应由拥有者显式释放。若底层调用只拿着裸句柄，Go 指针可能在调用过程中已经被判定为不可达，finalizer 甚至会提前关闭句柄；这时要把 runtime.KeepAlive(h) 放在最后一次使用之后，而不是用它等待 finalizer。

什么时候换成 AddCleanup 更合适

Go 1.24 起，runtime.AddCleanup 提供了另一种低层机制：清理函数接收独立的参数，而不是重新拿到原对象。这样可以减少对象复活、引用环和只能把 finalizer 挂在对象起始位置等问题。它同样不保证在进程退出前执行，也不能替代显式关闭。

我的取舍顺序是：资源 owner 先提供 Close，业务在确定时机调用；需要防止底层调用期间过早回收时补 KeepAlive；只有“忘记释放时尽量补救”才考虑 finalizer 或 cleanup。cleanup 函数不要捕获被清理对象，也不要把对象本身作为参数传进去，否则对象仍可达，清理反而不会发生。

相关问题

调用 runtime.GC 后为什么还要等待？

因为 runtime.GC 不等待 finalizer 函数执行完成，只能让不可达对象进入后续处理。测试应使用通道、状态位或其他明确完成信号。

finalizer 能替代 Close 吗？

不能。资源数量和释放时机通常受业务与系统限制，GC 的调度并不知道这些约束。finalizer 适合做错误路径的尽力补救。

KeepAlive 会让对象更快触发 finalizer 吗？

不会。它只保证对象至少活到调用点，防止回调过早发生；回调何时排队仍由运行时决定。