Go weak.Pointer 为什么适合做弱缓存：对象回收与并发读取边界

做图片解码、模板编译或元数据索引时，缓存通常希望“有就复用，没有就重建”，却不希望缓存本身把所有对象永久留在堆上。Go 的 weak.Pointer 正好提供了这个边界：缓存只保存弱引用，对象仍可被垃圾回收；读取时必须接受引用已经失效，并在拿到强引用后完成一次安全使用。

弱缓存的正确心智模型是“命中不保证，失效可重建”：用 Make 写入弱引用，用 Load 尝试取回对象，取回后用 runtime.KeepAlive 保证本次使用期间对象仍被强引用。

弱缓存解决的是“复用”和“回收”的冲突

强引用缓存会让命中率更稳定，但缓存容量一旦没有上限，解码结果、反射元数据或临时索引就可能长期占用堆。弱缓存把取舍反过来：只在对象仍然存活时复用，内存压力上来后允许 GC 回收它，下一次请求再付出重建成本。

这个策略适合“重建有成本、但丢失也不影响正确性”的数据。它不适合保存订单状态、权限结果或必须可靠送达的任务，因为这些数据不能依赖垃圾回收决定是否存在。

用 Make 保存对象，用 Load 接受一次可能的失效

下面的缓存只保存字符串切片的弱引用。Make 接收一个仍由业务代码持有的指针，返回 weak.Pointer；之后 Load 可能返回原对象，也可能返回空指针。空指针不是 bug，而是弱缓存正常的未命中分支。

package main

import "weak"

type Metadata struct {
    Name  string
    Bytes []byte
}

type WeakCache struct {
    value weak.Pointer[Metadata]
}

func (c *WeakCache) Put(v *Metadata) {
    c.value = weak.Make(v)
}

func (c *WeakCache) Get() *Metadata {
    return c.value.Load()
}

注意 weak.Pointer 只描述“如何观察对象是否仍在”，不提供并发安全的更新协议。实际项目里，WeakCache 的字段需要放进互斥保护，或者把整个缓存槽封装进已有的并发数据结构。

Load 之后要把强引用使用到最后

弱引用真正容易出错的地方在读取边界。读取代码应该把 Load 的结果放进局部强引用，在完成字段访问或方法调用后，再用 runtime.KeepAlive 明确告诉编译器：这个对象至少要活到这条语句之后。

package main

import (
    "runtime"
    "weak"
)

func readName(p weak.Pointer[Metadata]) (string, bool) {
    value := p.Load()
    if value == nil {
        return "", false
    }

    name := value.Name
    runtime.KeepAlive(value)
    return name, true
}

runtime.KeepAlive 不会阻止整个缓存对象被回收，也不会把弱引用升级成强引用；它只标出本次局部使用的生命周期终点。若 Load 已经返回空值，先重建，再把新对象交给 Make。

并发重建要防止一轮请求重复造对象

多个 goroutine 同时遇到 Load 空值时，弱缓存不会替你合并请求。最小实现可以用互斥锁把读取和重建包在一起；真正的昂贵构建也可以再换成项目已有的 singleflight 方案，但那属于并发去重，不是 weak.Pointer 的能力。

type SafeWeakCache struct {
    mu    sync.Mutex
    value weak.Pointer[Metadata]
}

func (c *SafeWeakCache) GetOrBuild(build func() *Metadata) *Metadata {
    c.mu.Lock()
    defer c.mu.Unlock()

    if value := c.value.Load(); value != nil {
        return value
    }
    value := build()
    c.value = weak.Make(value)
    return value
}

示例把锁覆盖到返回前，是为了让“检查、构建、替换”成为一个可验收的状态变化。生产代码还要处理 build 返回空值、构建失败和锁内耗时过长等问题；如果构建过程可能递归访问同一个缓存，不要直接照搬这段锁范围。

三个边界决定它是否值得采用

重建成本是否低于长期占用成本

弱缓存不是免费内存。GC 回收后再次构建会增加延迟，所以只有在对象大、访问有重复、且丢失后能快速重建时，收益才明显。

数据丢失是否影响业务正确性

弱缓存只能放派生数据。凡是丢失后会改变结算、权限、状态机或审计结果的数据，都应该使用有明确生命周期和持久化语义的存储。

是否已经定义并发重建策略

至少要说明是否允许重复构建、是否允许旧对象和新对象并存，以及构建失败如何返回。weak.Pointer 只负责弱引用观察，不能替代这些业务决策。

相关问题

Load 返回 nil 是不是说明 GC 刚刚发生？

不一定。它只说明当前弱引用没有可用对象，原因可以是对象已经被回收，也可以是这个缓存槽从未写入；调用方都应按未命中处理。

runtime.KeepAlive 能不能让缓存永远保留对象？

不能。它只延长当前调用中的可证明使用边界，不能改变 weak.Pointer 的弱引用语义。

弱缓存需要替代普通 map 吗？

不需要。普通 map 仍可保存键和弱引用槽；需要重新评估的是并发保护、空值重建和键空间清理，而不是把所有 map 都改成弱缓存。

weak.Pointer 的价值不在于保证命中，而在于允许派生对象在内存紧张时退出缓存。只要把 Make、Load、runtime.KeepAlive 和并发重建边界写清楚，它就能成为一种可控的“尽力复用”策略。