Go weak.Pointer Value 返回 nil 时怎么重建缓存

遇到 weak.Pointer.Value() 返回 nil，不要把它当成异常指针继续解引用。它表达的是：原对象已经只剩弱引用，缓存不再拥有它的生命周期。正确做法是把这次读取视为一次缓存未命中，回源构造新对象，返回一个强引用，并将新的弱引用回填到缓存。

Value 返回 nil 代表弱缓存已经失去对象

weak.Pointer[T] 在 Go 1.24 进入标准库。它和普通指针最大的区别，是不会因为自身存在而让目标对象保持可达。只要对象没有其他强引用，垃圾回收器就可以回收它；此后 Value() 可能得到 nil。

所以判断顺序应该是先取值，再决定命中还是重建。不要写成“先根据缓存键认定对象存在，再直接访问字段”，也不要把空指针当成需要重试的临时网络错误。弱引用没有保证某个时间点一定变成 nil，反过来也不能依赖它长期不变。

用强引用完成命中判断，再回填新的弱指针

下面的实现把弱缓存当作“可以随时丢失的加速层”。loadEntry 代表数据库、文件或远端配置读取；文章只展示缓存边界，不把回源数据写死在内存缓存里。

package cache

import (
    "fmt"
    "sync"
    "weak"
)

type Entry struct {
    Key   string
    Value string
}

type Cache struct {
    mu    sync.Mutex
    items map[string]weak.Pointer[Entry]
}

func (c *Cache) Get(key string) (*Entry, error) {
    c.mu.Lock()
    defer c.mu.Unlock() // 让检查、创建和回填保持在同一个临界区

    if wp, ok := c.items[key]; ok {
        if value := wp.Value(); value != nil {
            return value, nil // 先拿到强引用，再离开临界区
        }
        delete(c.items, key) // 弱引用已失效，清理旧槽位
    }

    value, err := loadEntry(key)
    if err != nil {
        return nil, err // 回源失败时不要写入空弱指针
    }
    c.items[key] = weak.Make(value) // 缓存不拥有 value 的生命周期
    return value, nil                // 返回值本身仍是强引用
}

func loadEntry(key string) (*Entry, error) {
    if key == "" {
        return nil, fmt.Errorf("empty cache key") // 示例中的输入边界
    }
    return &Entry{Key: key, Value: "loaded"}, nil // 实际项目换成真实回源
}

这里最关键的不是 delete，而是把“读取弱指针、判断 nil、回源创建、写回弱指针”作为一个完整的并发决策。这样多个 goroutine 同时请求同一个键时，不会在同一时刻都看见失效槽位并重复创建对象。若键数量很大，可把全局锁换成按键锁或 singleflight，但判断规则不变。

并发重建时要区分缓存命中与唯一创建

上面的互斥锁保证同一个 Cache 实例一次只执行一条重建路径，代价是不同键也会互相等待。如果回源操作很慢，建议把锁粒度缩小到键级别，或者使用按键去重组件。不要简单地先解锁、再创建、最后无条件写回：那会让多个请求都创建对象，最后一个写入的弱指针还可能覆盖前一个结果。

如果业务只要求“最终拿到可用对象”，允许少量重复构造，也可以使用 sync.Map 加 CAS 替换失效的 weak.Pointer。但无论采用哪种结构，都必须在 Value() 返回后立即保存强指针；缓存中的弱指针不能作为后续字段读取的安全凭证。

GC 与 KeepAlive 是边界，不是重建触发器

不要用 runtime.GC() 来“修复”缓存，也不要假设调用一次 GC 后每个弱引用都会立刻变成 nil。Value() 的 nil 时机由对象可达性和运行时决定。相反，如果一段代码必须让对象存活到某个操作结束，应在最后一次需要存活的位置之后调用 runtime.KeepAlive，而不是把强引用塞进弱缓存来延长生命周期。

常见问题

Value 返回 nil 是不是 weak.Pointer 用错了？

不一定。只要目标对象已经不可达，返回 nil 就是设计行为；应回源重建并重新保存弱引用。

把 weak.Pointer 存在 map 里会不会阻止 GC？

不会。map 只持有弱指针，目标对象仍需由业务中的强引用、全局引用或当前调用链保持可达。

能不能把 Value 返回的指针再次放回 weak.Pointer？

可以重新用 weak.Make 创建，但通常只有在你已经确认这是一个新的强引用对象时才这样做；失效弱指针本身不能恢复目标。