原子指针替换配置对象时的可见性边界

我在给服务做配置热更新时，最容易误判的一点是：把指针换成原子操作，并不等于配置对象里的每个字段都自动获得并发保护。atomic.Pointer 真正解决的是“读写哪个配置版本”的原子发布和同步关系；要让可见性边界清楚，还必须在 Store 前完成快照构造，并在发布后把快照当成只读对象。

这篇只讨论一个小而实用的模式：写侧构造完整的 Config，读侧一次 Load 得到当前版本，更新时用新指针整体替换，异常时保留旧指针回滚。

先区分指针可见性和对象字段安全

sync/atomic 文档为泛型 Pointer[T] 提供了 Load、Store、Swap 和 CompareAndSwap。当读协程观察到写协程发布的原子值时，两次原子操作之间形成同步关系。因此，下面的重点不是“读到的地址会不会撕裂”，而是“这个地址指向的对象是否已经构造完成”。

安全边界可以记成一句话：先构造，后发布；发布后只读。如果写协程先把指针存进去，再继续改 Timeout、Rules 或 map 内容，读协程虽然原子地拿到了指针，却仍可能和写协程同时访问对象字段。

构造完整快照后再 Store

配置结构最好把一次业务请求需要的值集中在一个版本里。更新函数先生成新对象，检查失败就不触碰当前版本；只有检查通过后才调用 Store。下面的示例故意不提供任何发布后的字段写入口：

package config

import "sync/atomic"

type Config struct {
	Version int
	Timeout int
	Endpoint string
}

type Holder struct {
	// Pointer 只负责发布完整快照，初始化后不能再复制 Holder。
	current atomic.Pointer[Config]
}

func (h *Holder) Load() *Config {
	// 读侧拿到一次快照，后续逻辑都使用同一个指针。
	return h.current.Load()
}

func (h *Holder) Replace(version, timeout int, endpoint string) bool {
	// 先在局部变量中构造并检查新版本，失败不会影响旧版本。
	next := &Config{Version: version, Timeout: timeout, Endpoint: endpoint}
	if next.Timeout 

这里的“可见”不表示所有读协程会在同一纳秒切换到新版本；它表示读协程通过原子 Load 观察到新指针后，可以把这个已经构造完成的对象作为一个版本使用。正在处理的请求仍可能持有旧快照，这是正常的版本边界。

一次请求只 Load 一次，避免自己制造版本不一致

读侧不要为了取两个字段而连续调用两次 Load。更新恰好发生在两次读取之间时，Timeout 可能来自旧版本，Endpoint 却来自新版本，虽然每次指针读取都原子，业务关系仍被拆开了。

func handleRequest(h *Holder) error {
	cfg := h.Load()
	if cfg == nil {
		return ErrConfigUnavailable
	}

	// 同一次请求固定使用一个版本，避免中途切换造成字段组合不一致。
	endpoint := cfg.Endpoint
	timeout := cfg.Timeout
	return call(endpoint, timeout)
}

如果 Config 里包含 slice、map 或嵌套指针，也要把“不变”贯彻到它们：可以在构造快照时复制并整理，不能在 Store 后继续追加、删除或改写共享容器。需要频繁修改的状态应另用锁、channel 或专门的并发结构。

用 race 检查原地修改和回滚路径

排查时我会先把问题分成两条路径：如果每次更新都是新对象整体替换，重点看初始化和读侧是否只绑定一个快照；如果更新后还拿着旧指针改字段，优先怀疑真实数据竞态，而不是怀疑 Load 没有生效。

# 用 race 检测覆盖“更新配置”和“读取配置”同时发生的测试路径。
go test -race ./...

回滚也应当是一次整体替换：保留上一个合法的 *Config，新版本检查失败时不发布；已经发布但被业务判定不可用时，直接 Store(old)，不要把当前对象的字段逐个改回去。这样日志里的版本号、指针版本和请求看到的快照仍然能对应起来。

结论与常见追问

atomic.Pointer 的可见性边界可以落成四个动作：完整构造、原子发布、单次加载、只读使用。它适合读多写少的配置快照，不是给可变业务对象加上的隐形互斥锁。只要把发布后的对象当作不可变版本，读侧就能自然地接受旧版本与新版本在切换时短暂并存。

旧快照什么时候可以释放？

Go 的垃圾回收会在没有引用后回收旧对象；代码只要不把旧对象交给外部不受控的长期引用，就不需要手工释放。正在处理请求持有旧指针时，旧对象仍然有效。

可以用 Swap 代替 Store 吗？

可以。需要拿到被替换的旧指针时使用 Swap，需要根据当前版本做条件更新时使用 CompareAndSwap；但无论选择哪种原子操作，发布后只读的对象约束都不变。