Go weak.Pointer 怎样保存可回收对象的弱引用

Go 的 weak.Pointer 适合保存“对象还活着就复用、对象不再需要就允许回收”的引用。它不会让目标对象保持可达，读取时必须接受 Value() 返回 nil。实际使用可以归纳成一句话：弱引用只负责观察，不负责保活；需要稳定结果时保留普通指针，需要可丢弃缓存时再保存 weak.Pointer。

weak.Pointer 与普通指针的生命周期差异

普通指针会让垃圾回收器沿着引用继续追踪对象；弱指针则不会。Go 1.24 起，标准库 weak 提供了这层语义，典型用途是可丢弃缓存、规范化表和弱键结构。弱指针记录的是创建时的对象及偏移关系，即使对象后来被回收，两个由相同原始地址创建的 Pointer 仍可以比较；它并不因此重新变成强引用。

下面的示例只演示生命周期判断。它没有依赖某一次 GC 必然发生，因为 GC 的触发和回收时间由运行时决定。

package main

import (
    "fmt"
    "runtime"
    "weak"
)

type Entry struct {
    Name string
}

func readWeak() {
    entry := &Entry{Name: "session-schema"}
    ref := weak.Make(entry)

    if current := ref.Value(); current != nil {
        // Value 只在对象仍可达时给出可用指针，业务必须准备 nil 分支。
        fmt.Println(current.Name)
    }

    runtime.KeepAlive(entry)
    // KeepAlive 放在最后一次需要 entry 的操作之后，用来明确可达性边界。
}

Value 读取必须把 nil 当成正常结果

Pointer.Value 返回创建弱引用时的原始指针。如果目标对象已经被垃圾回收，结果就是 nil。因此正确的读取路径不是“取出后直接使用”，而是“读取、判断、命中则复用，未命中则降级或重建”。对于缓存来说，nil 通常意味着重新加载；对于规范化结构来说，nil 意味着重新创建规范实例。

不要用 runtime.GC() 把示例包装成确定性测试。官方文档明确指出，Value 不保证最终一定返回 nil；小型、无指针对象还可能因分配批处理而延后表现。测试应关注 nil 分支和重建逻辑，而不是依赖某个固定时间点。

KeepAlive 只划定最后一次使用边界

函数参数或接收者可能在最后一次被编译器判定为不再使用的位置变得不可达。如果外部操作仍需要对象保持存活，就在该操作完成后调用 runtime.KeepAlive(obj)。它影响的是本次调用期间的可达性，不会让 weak.Pointer.Value 永远返回非 nil，也不会改变垃圾回收的调度。

func useEntry(entry *Entry, ref weak.Pointer[Entry]) string {
    current := ref.Value()
    if current == nil {
        // 弱引用失效时走重建、跳过或返回缓存未命中，不能解引用 nil。
        return "cache-miss"
    }

    name := current.Name
    runtime.KeepAlive(entry)
    // 这里的 KeepAlive 表示 entry 至少活到本次读取完成，不是永久保活。
    return name
}

把弱引用放在合适的边界内

弱指针最适合被封装在缓存或对象规范化组件内部，让调用方拿到“命中对象或重新构造”的普通接口。若把弱指针直接暴露给业务层，调用方很容易忘记 nil 判断，或者误以为它能替代关闭文件、释放连接等确定性资源管理。

排查弱引用问题时按这份清单走：先确认是否还存在普通强引用；再确认每次 Value 是否判断 nil；最后确认需要保活的最后一次访问之后是否有 KeepAlive。如果只是想观察对象何时消失，也不要把 GC 时机写成业务协议，因为清理时间没有这样的保证。

常见问题

weak.Pointer 会让对象保持存活吗？

不会。只有其他可达路径能让对象继续存活，弱指针本身不参与可达性追踪。

Value 返回 nil 是错误吗？

不是。它表示原始对象已经不可达或已被回收，缓存应把它当作未命中并准备替代路径。

可以用 weak.Pointer 管理文件句柄吗？

不建议。文件句柄需要显式关闭；弱引用和 GC 都不提供确定的释放时刻。