Go atomic.Pointer 怎样安全替换配置

配置会被定时刷新、请求线程却一直在读取时，最容易出现的错误不是“指针交换不够快”，而是发布方一边修改同一个 Config，一边让读方拿到它。Go 的 atomic.Pointer[T] 适合解决另一种更清晰的边界：先构造完整的不可变配置快照，再原子替换保存快照地址的槽位，读方始终通过 Load 取得一份完整对象。

官方文档：https://pkg.go.dev/sync/atomic

安全做法是“新建一份完整 Config，再 Store 到 atomic.Pointer”；不要 Store 之后继续原地修改旧对象，也不要把 atomic.Pointer 复制成多个副本。

先把问题缩小到配置快照的发布边界

假设服务请求只需要读取路由、超时时间和灰度开关。若刷新逻辑直接改写共享 struct，读方可能先看到新超时、再看到旧路由。即使每个字段单独写入是安全的，多个字段之间的整体关系仍然没有被保护。

这时可以把 Config 视为“构造完成后只读”的值，把并发变化收敛到一个指针槽位：发布方负责创建快照，读取方只复制当前指针。图中的边界是静态说明图，不是运行截图。

把发布和读取写成最小可用实现

Pointer[T] 的零值是 nil，第一次读取前要先发布初始快照。发布时使用 Store，读取时使用 Load；两个操作只负责原子地替换和读取指针，不会替你保护 Config 内部后续的原地修改。

package config

import "sync/atomic"

// Config 是一次构造完成的快照；发布后不再修改其中字段。
type Config struct {
	Routes  map[string]string
	Timeout int
	Canary  bool
}

// Snapshot 保存当前配置快照的地址，不复制这个值。
type Snapshot struct {
	current atomic.Pointer[Config]
}

// NewSnapshot 先发布初始值，避免读方在初始化阶段拿到 nil。
func NewSnapshot(initial *Config) *Snapshot {
	s := &Snapshot{}
	s.current.Store(initial)
	return s
}

// Load 返回当前完整快照；调用方只读，不修改返回对象。
func (s *Snapshot) Load() *Config {
	return s.current.Load()
}

// Replace 先接收构造完成的新快照，再一次性替换指针槽位。
func (s *Snapshot) Replace(next *Config) {
	s.current.Store(next)
}

这里的关键不是把每个字段都改成原子类型，而是让“整份 Config”成为发布单位。读请求拿到旧指针时，可以完整读完旧快照；发布完成后，新读请求会拿到新快照。不要在 Replace 后继续写 next.Routes，否则原子指针只保护了地址替换，没保护 map 或其他字段的并发访问。

遇到并发更新时再考虑 CompareAndSwap

如果只有一个配置刷新器，Store 就足够。若多个刷新器可能基于同一个旧版本计算新配置，就需要用 CompareAndSwap 表达“只有当前仍是我读到的版本才替换”。

// ReplaceIfCurrent 只在当前快照仍是 old 时发布 next。
func (s *Snapshot) ReplaceIfCurrent(old, next *Config) bool {
	return s.current.CompareAndSwap(old, next)
}

CAS 返回 false 时，说明槽位已经被其他发布者换过；此时应重新 Load、重新合并或直接放弃本次更新，不能把失败当成成功。若配置更新不是“基于旧值计算新值”，不要为了形式上的并发而额外使用 CAS。

最后复查四个容易踩到的边界

• 先初始化再读取：让构造函数完成第一次 Store，或者让 Load 明确处理 nil；不要把 nil 当成正常配置。
• 不复制 Pointer：atomic.Pointer 第一次使用后不能复制；把它放进长期存活的 Snapshot 中，通过指针接收者访问。
• 快照发布后只读：如果 Config 内有 map、slice 或嵌套指针，构造阶段完成复制；发布后不要从任何 goroutine 原地改它们。
• 原子指针不是互斥锁：它适合“整份值替换、并发读取”的场景；需要保护多步事务或多个可变对象时，仍应使用 mutex 或其他同步方案。

常见问题

atomic.Pointer 能替代所有配置锁吗？

不能。它适合不可变快照的整体替换；如果更新过程需要连续修改多个共享对象，应该围绕事务边界选择 mutex 或其他同步结构。

Load 返回的 Config 可以修改吗？

不建议。只要其他 goroutine 仍可能读取这份快照，修改其中的 map、slice 或指针字段就会重新引入数据竞争。需要变更时复制并构造下一份快照。

什么时候用 Swap 而不是 Store？

当发布方还需要拿到旧快照做回收、统计或比较时，可以使用 Swap；只关心发布新快照时，Store 更直接。

归根结底，atomic.Pointer 解决的是“谁能看到哪一份完整快照”的发布问题。把对象构造、指针替换和只读约束一起设计清楚，通常比给每个配置字段单独加锁更容易复查。