Go atomic.Pointer 更新对象后为什么旧对象还不能立刻释放

先给结论：atomic.Pointer[T].Store 只替换了“以后 Load 从哪里取”的入口，不会撤销读者已经拿到的旧指针。只要某个 goroutine 仍把旧指针保存在局部变量、闭包或派生对象中，旧对象就仍然可达；即使已经没有读者，Go 的垃圾回收也不会承诺在 Store 返回后立刻回收它。

因此，原子指针适合发布不可变快照。对象本身由 GC 管理时，让旧对象自然失去可达性通常就够了；对象里面如果持有文件、连接、句柄等外部资源，则必须另行设计读者退出和资源关闭边界。

消息是什么：Store 更新的是入口，不是读者手里的对象

atomic.Pointer[T] 的 Load 会原子地取出当前的 *T，Store 会原子地写入新的 *T。这解决的是并发读写指针本身的同步问题，不等于“旧对象已经没人使用”。

可以把它想成一个公告栏：发布者把公告栏上的地址换成新版本，已经抄下旧地址的读者不会因为公告栏变化而自动忘记旧地址。读者只要还在使用自己的快照，旧对象就不能被当作无人使用的对象处理。

快速试用：先构造完整快照，再一次 Store

配置、路由表或规则集合可以采用“构造新对象—原子发布—读者只读”的方式。关键点是 Store 之前完成初始化，发布之后不再修改其中的 map、slice 或嵌套字段。

package config

import "sync/atomic"

type Config struct {
	Version int
	Rules   map[string]string
}

var current atomic.Pointer[Config]

func Publish(version int, rules map[string]string) {
	// 发布前复制输入，避免调用方之后修改同一张 map。
	snapshot := make(map[string]string, len(rules))
	for key, value := range rules {
		snapshot[key] = value
	}

	// 对象先完整初始化，再一次性替换入口。
	next := &Config{Version: version, Rules: snapshot}
	current.Store(next)
}

func Read() *Config {
	// 局部变量会持有本次读取到的快照，直到调用方不再使用它。
	return current.Load()
}

这里的 snapshot 只是示例中的浅层复制；如果字段里还有可变 slice、指针或嵌套 map，也要沿着读者会访问的路径建立不可变边界。发布后若继续执行 current.Load().Rules["x"] = "y"，就把原子指针安全发布和对象内部的数据竞争重新混在了一起。

和旧方案对比：原子替换、互斥保护与手工回收不是一回事

尤其不要把“旧指针从入口消失”当成“旧资源可以马上 Close”。一个读者可能已经执行了 cfg := current.Load()，随后在网络慢、锁等待或业务回调中继续使用 cfg。Store 不会等待这段使用结束。

采用风险：旧对象能不能释放，要看它由谁管理

如果旧对象只是 Go 堆上的数据，读者结束后不再引用它，GC 会在之后的回收周期中处理；不能把某一次 GC 的时间当成程序契约。对于带有文件、连接、映射区或 C 资源的对象，GC 是否最终回收 Go 外壳，也不能替代明确的关闭协议。

工程上可以按下面的边界检查：

• 读者 Load 后只读快照，不在 Store 后原地修改旧对象。
• 需要关闭外部资源时，让读者通过引用计数、epoch、租约或集中协调器声明“使用结束”。
• 不要在发布新指针后立即关闭旧对象，除非已经有明确的无人使用证明。
• atomic.Pointer 本身不能被复制到另一个实例继续使用；发布器和读取器应共享同一个 Pointer。

Go 内存模型说明，原子操作可以建立同步关系；它关注的是并发访问的可见性与顺序，不会替应用程序定义业务对象的最后一个读者。把这两层职责分开，才能解释“指针已更新，但旧对象还不能立刻释放”这个现象。

常见追问

Store 之后旧对象一定还在内存里吗？

不一定。若没有任何可达引用，它可能在之后的 GC 周期被回收；但 Store 的语义不承诺立即回收，也不保证某个固定时间点完成回收。

只要使用 atomic.Pointer，就能安全修改对象字段吗？

不能。它只保护指针的 Load、Store、Swap 和 CompareAndSwap；对象字段仍需保持不可变，或使用锁、原子字段等独立同步方案。

一句话总结：Store 替换的是共享入口，旧对象的生命周期由仍然持有它的读者和对象内部资源协议决定；GC 数据可以等待自然不可达，外部资源则必须等待明确的读者退出。