Go SetFinalizer 不适合资源关闭的替代方案

Go 的 runtime.SetFinalizer 由垃圾回收决定触发时机，不能代替文件描述符、连接、mmap 或 C 资源的确定性关闭。更稳妥的组合是：公开一个幂等的 Close，调用方在成功创建资源后立即用 defer 兜底；如果还需要防止调用方忘记关闭，再把 runtime.AddCleanup 放在包内部做 best-effort 清理。

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

把资源所有权放进 Close，而不是放进 GC 时机

SetFinalizer 的问题不在于“完全不能运行”，而在于它的契约与业务关闭不同：对象变得不可达后，finalizer 才会在某个未来时间被调度；进程退出前也没有执行保证。文件描述符和连接受到系统数量限制，GC 却不了解“现在必须释放”的业务截止点。因此，创建资源的一方应拥有关闭责任，调用方也应能从 Close 返回值中看到释放错误。

下面这个结构把释放动作集中到状态对象中。sync.Once 不是为了掩盖错误，而是为了让重复关闭只执行一次底层释放；真实项目中应把 releaseHandle 换成对应平台或库的关闭调用。

type handleState struct {
    once   sync.Once
    handle uintptr
    err    error
}

func (s *handleState) close() {
    s.once.Do(func() {
        // 只在第一次关闭时释放外部句柄，并保留底层错误。
        s.err = releaseHandle(s.handle)
    })
}

type Resource struct {
    state   *handleState
    cleanup runtime.Cleanup
}

func (r *Resource) Close() error {
    if r == nil || r.state == nil {
        return nil // 让重复清理或空资源保持幂等。
    }
    r.state.close()
    r.cleanup.Stop() // 显式关闭后撤销尚未入队的兜底清理。
    return r.state.err
}

func useResource() error {
    r, err := OpenResource()
    if err != nil {
        return err
    }
    defer r.Close() // 作用域结束时执行确定性的主路径关闭。
    return doWork(r)
}

用 runtime.AddCleanup 做丢失 Close 的兜底

如果调用方忘记 Close，可以在构造函数中注册 AddCleanup。它和 finalizer 的关键差别是：清理函数接收独立的参数，不需要把原始 Resource 重新交给清理函数。参数必须是轻量状态，并且不能通过字段、闭包或其他引用回到 Resource，否则对象仍然可达，清理可能永远没有资格执行。

func OpenResource() (*Resource, error) {
    handle, err := acquireHandle()
    if err != nil {
        return nil, err
    }
    state := &handleState{handle: handle}
    r := &Resource{state: state}

    // cleanup 只拿独立状态，不捕获 r，避免反向延长 r 的生命周期。
    r.cleanup = runtime.AddCleanup(r, func(s *handleState) {
        s.close() // 仅作为忘记 Close 时的最终兜底。
    }, state)
    return r, nil
}

这里不要把 r 直接作为清理参数，也不要在匿名函数里引用 r。显式 Close 成功后，可以保存返回的 runtime.Cleanup 并调用 Stop，减少已不需要的兜底任务；不过如果清理已经入队，Stop 不会撤销正在执行的调用。无论如何，AddCleanup 都不能替代主路径。

参数与边界：什么时候选 Close、AddCleanup 或旧式 finalizer

Go 官方文档已建议新代码优先考虑 AddCleanup，因为 finalizer 会让对象暂时重新可达，规则更多；但这不是把清理变成可靠定时器。涉及 C 分配内存时，清理机制可以作为最终释放保障；涉及非内存资源时，仍应让 API 的 Close 语义清楚、可重复调用并能被测试覆盖。

相关问题

为什么不能只调用 runtime.GC 触发关闭？

runtime.GC 只会请求一次回收，并不把资源关闭变成业务契约；终结器或 cleanup 仍可能延后，程序退出也可能来不及执行。

AddCleanup 能保证清理函数一定运行吗？

不能。对象可能仍然可达，参数可能形成反向引用，零大小对象和包级初始化对象也有特殊边界，进程退出前同样没有保证。

Close 和 AddCleanup 会不会重复关闭句柄？

如果两条路径共享 sync.Once，底层释放动作只执行一次；不要让 Close 和 cleanup 各自维护一套无锁的关闭标志。