weak.Pointer.Value 偶尔返回零值是不是数据竞争

weak.Pointer.Value() 偶尔返回的“零值”实际是指针零值 nil，它本身不等于数据竞争。只要目标对象已经不可达并被 GC 回收，Value() 就会返回 nil；零值 weak.Pointer[T] 的 Value() 也始终返回 nil。真正的数据竞争，必须是多个 goroutine 对同一内存位置存在未同步的读写或写写冲突。

官方语义：https://pkg.go.dev/weak

Value 返回 nil 时，先看对象是否已经不可达

weak.Pointer[T] 不阻止目标对象被回收。官方文档明确说明：只被弱指针指向的对象不算可达，对象一旦不可达，Value() 可能返回 nil。这是一种生命周期结果，不是对并发错误的诊断。

还要注意两个边界。第一，函数参数或局部变量可能在源码最后一次使用后就被运行时视为不可达，不必等到函数返回。第二，Value() 不保证最终一定返回 nil，微小且不含指针的对象可能因合并分配而长期留在同一分配槽里。因此，既不能把“偶尔 nil”直接当作 race，也不能把“迟迟不 nil”当作泄漏证明。

一个最小排查配方：强所有者、引用容器、目标字段

看到偶发 nil 时，可以按三个位置拆开检查：

这三个位置互相独立：对象可能在完全没有数据竞争的程序中被正常回收；也可能 Value() 始终非 nil，但目标字段存在真实竞争。

共享 weak.Pointer 字段要在锁内复制

最小可用写法是让锁只保护共享的 weak.Pointer 字段。读取时先在读锁内复制一份引用值，释放锁后再调用 Value()。这样“发布/替换引用”和“读取引用”有清楚的同步边界，目标对象是否仍存活则由 Value 的返回值表达。

package weakbox

import (
	"sync"
	"weak"
)

type Item struct {
	ID   string
	Data []byte
}

type Box struct {
	mu  sync.RWMutex
	ref weak.Pointer[Item]
}

func (b *Box) Store(item *Item) {
	b.mu.Lock()
	defer b.mu.Unlock()
	// 在写锁内替换共享引用，避免与并发 Load 发生字段读写竞争。
	b.ref = weak.Make(item)
}

func (b *Box) Load() (*Item, bool) {
	b.mu.RLock()
	// 锁内复制 weak.Pointer；锁只保护引用容器，不负责让目标保活。
	ref := b.ref
	b.mu.RUnlock()

	item := ref.Value()
	// nil 是允许的查询结果，表示零值引用或目标已经被回收。
	return item, item != nil
}

这里不需要在锁内一直持有到业务使用结束，因为 Value() 一旦返回非 nil，返回的 *Item 就是普通强指针，调用方持有它期间目标保持可达。但这并不自动保护 Item.Data 的并发修改。

三种容易误判为同一个问题的情况

对象只剩弱引用

创建 weak.Pointer 后立即丢掉所有强引用，稍后 Value() 返回 nil 是预期结果。若业务需要对象稳定存在，就必须由业务所有者持有 *Item，不能要求弱引用承担所有权。

共享 weak.Pointer 自身被并发替换

如果一个 goroutine 直接给共享字段赋新值，另一个 goroutine 同时读取该字段，而且没有 happens-before 关系，这才符合 Go 内存模型中的数据竞争定义。修复点是引用容器的同步，而不是反复调用 Value()。

func (b *Box) unsafeStore(item *Item) {
	// 错误示例：若另一个 goroutine 同时读取 b.ref，这次赋值可能形成数据竞争。
	b.ref = weak.Make(item)
}

目标对象字段被并发读写

Value() 返回的是正常指针。一个 goroutine 修改 item.Data，另一个 goroutine 同时读取，而对象内部没有锁，仍会产生普通字段竞争。weak.Pointer 只处理弱可达性，不提供目标对象的数据同步。

用 race detector 查竞争，用 KeepAlive 表达存活区间

Go 的数据竞争定义是：对同一内存位置的写，与另一个读或写并发发生，并且这些访问没有通过原子操作或同步关系排序。排查时应运行 race detector，它会观察共享内存访问，而不是把一次 nil 返回当作告警。

# 开启 race detector 检查测试中的共享内存读写冲突；它不负责判断对象何时被 GC 回收。
go test -race ./...

如果测试要求“在这一段代码结束前对象必须仍然可达”，应在该区间最后调用 runtime.KeepAlive(owner)。它不是加锁，也不能修复字段竞争，只是明确延长对象的可达区间。

func TestLoadWhileOwnerAlive(t *testing.T) {
	box := &Box{}
	owner := &Item{ID: "job-7", Data: []byte("ready")}
	box.Store(owner)

	got, ok := box.Load()
	// 强所有者仍应存活，因此 Load 必须返回同一个对象。
	if !ok || got != owner {
		t.Fatalf("want live item, got ok=%v item=%p", ok, got)
	}

	// 明确要求 owner 至少存活到断言完成，避免过早不可达干扰测试。
	runtime.KeepAlive(owner)
}

不要把“设置 owner=nil，调用一次 runtime.GC()，然后断言必为 nil”写成稳定单测。官方文档并不保证 Value() 最终一定返回 nil，这类测试会把 GC 实现细节当成业务契约。

完整片段：引用同步和对象所有权分开处理

实际项目可以把强所有者放在明确的生命周期组件中，把 Box 只当可失效查询入口。下面的使用方式同时展示命中处理和 nil 分支：

func useBox(box *Box, owner *Item) error {
	// Store 只发布弱引用；owner 参数仍是这一调用区间的强所有者。
	box.Store(owner)

	item, ok := box.Load()
	if !ok {
		// nil 按缓存未命中处理，可重建对象或返回业务级未找到。
		return errors.New("item is no longer reachable")
	}

	// 拿到 *Item 后是普通强引用，但修改共享字段时仍要使用对象自己的同步策略。
	consume(item.Data)

	// 保证 owner 在 consume 完成前保持可达；这不是并发锁。
	runtime.KeepAlive(owner)
	return nil
}

常见问题

零值 weak.Pointer 为什么也返回 nil？

零值 Pointer 的行为等价于对 nil 调用 weak.Make，因此它的 Value() 始终为 nil。这通常说明引用尚未初始化，不代表 race。

连续两次 Value 会不会一次非 nil、一次 nil？

如果第一次返回的强指针没有被保留到第二次调用，目标可能在两次调用之间变得不可达。需要稳定使用时，保存第一次返回的 *T，不要只反复查询弱引用。

加了 RWMutex 为什么 race detector 还报警？

锁可能只保护了 weak.Pointer 字段，而报警位置位于目标对象的切片、map 或普通字段。应根据 race 报告中的读写栈定位同一内存位置，并在目标对象层补同步。