weak 指针与 finalizer 配合时怎样避免对象复活

直接说结论：weak 指针本身不会让对象复活，真正造成复活的是 finalizer 获得对象的强指针后，又把这个指针保存到全局变量、长生命周期闭包、通道或其他可达对象中。要避免复活，最稳妥的做法是让 finalizer 只处理与原对象脱离的数据，不向程序重新发布原对象；对于 Go 1.24 及之后的新代码，优先用 runtime.AddCleanup 传递独立资源句柄，而不是继续用 runtime.SetFinalizer 接收原对象。

我第一次把 weak 缓存和 finalizer 放在一起时，直觉上以为“弱指针失效后，对象就彻底消失了”。实际语义更微妙：对象一旦不可达，GC 可以把 finalizer 加入队列；此时指向它的 weak.Pointer.Value() 就可以返回 nil。随后 finalizer 被调用时，运行时为了把对象指针传给回调，会临时让对象重新可达。如果回调再把它发布出去，对象就真的活回来了。

官方资料：https://pkg.go.dev/weak
GC 指南：https://go.dev/doc/gc-guide
运行时 API：https://pkg.go.dev/runtime#AddCleanup

先看清 weak、finalizer 与对象复活的关系

对象正常被强引用持有时，weak 指针只是一个不参与保活的观察入口。当最后一个强引用消失，GC 发现对象不可达，带 finalizer 的对象不会立即释放：运行时会清除 finalizer 关联，并把 finalizer 排队。为了稍后调用 f(obj)，运行时必须重新构造一条到对象的强引用，这就是 finalizer 天生具有“复活能力”的原因。

这里有两个很容易混淆的事实：

• weak.Pointer.Value() 在对象被真正释放以前就可能返回 nil；如果对象带 finalizer，它会在 finalizer 被排队时失效。
• 对象经 finalizer 复活后，再从这个强指针创建的新 weak 指针，与复活前创建的旧 weak 指针不相等。不要把 weak 指针当作跨“死亡—复活”过程稳定不变的身份令牌。

所以，设计目标不应是“让旧 weak 指针重新指到复活对象”，而应是根本不让原对象从 finalizer 逃逸。缓存如果读到 nil，就按照普通未命中处理，重新创建一个拥有新生命周期的对象。

最危险的写法：在 finalizer 中重新发布对象

下面的示例看起来像是在“保留最后一次回收现场”，其实它把 finalizer 参数写进包级变量，直接建立了新的 GC 根路径。对象不会按预期结束生命周期，旧 weak 指针也不能作为它复活后的稳定身份。

package badcache

import (
    "runtime"
    "weak"
)

type Entry struct {
    Key  string
    Data []byte
}

var rescued *Entry // 错误：包级强引用会让 finalizer 参数长期存活

func NewEntry(key string, data []byte) (*Entry, weak.Pointer[Entry]) {
    e := &Entry{Key: key, Data: data}
    w := weak.Make(e)

    runtime.SetFinalizer(e, func(dead *Entry) {
        // 错误：把对象写回全局变量，形成从 GC 根到对象的新强引用
        rescued = dead
    })
    return e, w
}

同类问题不只发生在全局变量。把 dead 发送到仍有接收者的通道、追加到全局切片、保存进缓存、注册进回调表，效果都一样。finalizer 闭包如果捕获外层对象，也可能让对象从一开始就无法变成不可达，导致 finalizer 永远不运行。

我会把 finalizer 当作一个“只允许向外发送资源编号，不允许发送对象本身”的边界。只要回调代码需要访问对象的业务字段、调用对象方法或把对象传给别的 goroutine，就说明职责还没有拆干净。

优先方案：用 AddCleanup 传递脱离对象的资源句柄

runtime.AddCleanup 的关键变化是：清理函数收到的不是原对象，而是调用者明确提供的独立参数。只要该参数和清理闭包都不能反向到达原对象，运行时就不必为了执行清理而复活对象。对于文件描述符、C 内存地址的安全封装、映射区句柄等资源，这是更自然的所有权结构。

package resource

import (
    "runtime"
    "sync/atomic"
    "weak"
)

type Handle struct {
    id     int
    closed atomic.Bool
}

func releaseID(id int) {
    // 真实项目在这里释放与对象分离的底层资源，不接收 *Handle
    _ = id
}

func NewHandle(id int) (*Handle, weak.Pointer[Handle]) {
    h := &Handle{id: id}
    w := weak.Make(h)

    runtime.AddCleanup(h, func(resourceID int) {
        // 正确：清理参数只有整数句柄，无法沿引用图回到 h
        releaseID(resourceID)
    }, id)
    return h, w
}

func (h *Handle) Close() {
    if h.closed.CompareAndSwap(false, true) {
        // 显式关闭应是主路径，cleanup 只负责遗漏关闭时的兜底
        releaseID(h.id)
    }
    runtime.KeepAlive(h) // 确保资源操作完成前 h 仍然可达
}

这个例子表达的是结构原则，不是要求所有资源都用整数表示。清理参数可以是一个小结构体，但它不能包含 *Handle，也不能包含能回到 Handle 的容器或闭包。官方文档还明确指出：如果 arg 就是传给 AddCleanup 的对象指针，调用会直接 panic，用来阻止最明显的误用。

需要注意，cleanup 不是确定性析构器。它不保证在进程退出前执行，执行时间也不确定。因此 Close、Release 这类显式接口仍是主路径；cleanup 适合作为使用方忘记关闭时的兜底，而不能承担刷新缓冲区、提交事务等必须完成的动作。

weak 缓存应把 nil 当作正常未命中

避免对象复活之后，缓存端还要接受一个现实：Value() 读到 nil 不是异常，而是生命周期已经结束的正常信号。读取代码必须完成 nil 检查，并在锁内再次确认，避免多个 goroutine 同时创建同一个逻辑键对应的新对象。

package cache

import (
    "sync"
    "weak"
)

type Item struct {
    Key string
}

type Cache struct {
    mu sync.Mutex
    m  map[string]weak.Pointer[Item]
}

func New() *Cache {
    return &Cache{m: make(map[string]weak.Pointer[Item])}
}

func (c *Cache) GetOrCreate(key string) *Item {
    c.mu.Lock()
    defer c.mu.Unlock()

    if w, ok := c.m[key]; ok {
        if item := w.Value(); item != nil {
            // 命中后立即保存在局部强指针中，返回期间对象保持可用
            return item
        }
        // weak 已失效，删除旧身份；不要等待 finalizer 把对象“救回来”
        delete(c.m, key)
    }

    item := &Item{Key: key}
    c.m[key] = weak.Make(item) // 新对象拥有新的生命周期和 weak 身份
    return item
}

这段代码特意没有用 weak 指针本身作为唯一业务身份。业务身份是字符串 key，weak 指针只负责关联“当前仍然存活的实例”。一旦实例死亡，就删除旧 weak 条目并创建新实例。这样即使底层地址将来被复用，也不会把一次新的生命周期误认为旧对象复活。

finalizer 暂时不能替换时的最小约束

有些老代码依赖 finalizer 的销毁顺序，不能一次性迁移到 cleanup。此时至少要把以下约束写进代码审查清单：

1. 回调不发布原对象：禁止写全局变量、长生命周期通道、缓存、注册表或跨 goroutine 队列。
2. 回调不捕获外层对象：只使用 finalizer 形参，避免闭包通过外层变量提前形成自引用。
3. 对象不形成引用环：带 finalizer 的对象若处在无法建立销毁顺序的环里，finalizer 可能永远不运行。
4. 清理逻辑短小：Go 的 finalizer 由单个 goroutine 串行执行；长任务会阻塞后续 finalizer。
5. 共享字段要同步：SetFinalizer(x, f) 与 f(x) 之间有同步关系，但对象此前的普通访问与 finalizer 访问仍应使用互斥锁或原子操作来避免竞态。
6. 不把 GC 时机当业务时钟：不要依赖“某次 GC 后一定完成”，也不要依赖进程退出前必定执行。

如果 finalizer 只为了释放一个与对象分离的句柄，那么迁移优先级很高，因为这种场景通常能直接换成 AddCleanup。如果 finalizer 必须读取复杂对象图，先问一句：这些数据能否在注册清理时提取成不可回到原对象的轻量值？能提取，就有机会消除复活。

测试重点是完成信号，不是 sleep

弱指针、cleanup 和 finalizer 的执行时机都不适合用固定睡眠时间验证。更稳的测试方式是：在测试开始前先触发一次 GC 建立基线；让待测对象离开强引用范围；再次触发 GC；由 cleanup 或 finalizer 向专用通道发送完成信号。测试应避免并行运行，并配合竞态检测检查清理函数与业务 goroutine 的共享访问。

func TestCleanupDoesNotResurrect(t *testing.T) {
    done := make(chan int, 1)

    func() {
        type wrapper struct{ id int }
        obj := &wrapper{id: 7}

        runtime.AddCleanup(obj, func(id int) {
            // 测试只回传独立句柄，不回传 obj，避免重新建立强引用
            done 

这里的超时只是防止测试永久挂起，真正的完成条件是通道信号。不要断言 GC 的精确轮次，也不要用 time.Sleep 后检查“应该已经回收”。官方 GC 指南同样强调，runtime.GC 只负责把符合条件的清理或 finalizer 排队，并不等待它们执行结束。

一张表判断该用哪种方案

常见问题

weak.Value 返回 nil 后，finalizer 里的对象还存在吗？

可能存在。对带 finalizer 的对象，Value() 会在 finalizer 被排队时返回 nil，而 finalizer 之后才收到对象指针。这个阶段差异正是不能用 weak 作为复活后身份的原因。

在 finalizer 中重新调用 SetFinalizer 可以延长生命周期吗？

技术上可以再次建立 finalizer 关联，但这会把生命周期变成难以推理的循环，并显著延迟内存回收。新代码应避免这种设计，把可确定的业务生命周期交给显式 API，把兜底清理交给 AddCleanup。

KeepAlive 能阻止对象永久回收吗？

不能。runtime.KeepAlive(x) 只保证对象在该调用点以前保持可达，适合标记资源操作的最后安全位置。调用之后若没有其他强引用，对象仍可进入回收流程。

AddCleanup 会不会也造成对象复活？

正确使用时不会，因为 cleanup 不接收原对象。但如果 cleanup 闭包或参数能反向到达原对象，对象会一直可达，清理函数反而不会运行。因此“参数与原对象断开”是最重要的设计条件。

最终可以把原则压缩成一句话：weak 只观察，业务代码负责重建；清理函数只拿独立资源值，绝不把原对象重新发布。这样对象死亡就是一次明确的生命周期结束，而不是一次可以被 finalizer 悄悄撤销的状态切换。