Go sync/atomic 怎样原子更新指针指向的不可变配置

Go 中用 atomic.Pointer[T] 更新不可变配置，更新的是“当前配置指针”，不是原地改写共享配置。正确做法是在私有对象中完成所有字段和 map 的构造，再调用 Store 发布；读侧通过一次 Load 取得快照，并且不修改它及其可达数据。

面对“路由配置读取频繁、完整配置偶尔替换”的需求，我会先确认读路径是否真的值得调整，再考虑这种结构。下面用构造的 worker 路由场景讲解，没有真实线上基线或压测结果；示例也未在本机运行，不把 API 的原子性直接等同于性能提升。

官方地址：https://pkg.go.dev/sync/atomic

先确定需要优化的是读取还是配置构建

我会先记录读取频率、更新频率、读操作耗时，以及每次配置构建的分配量。如果业务开销主要在网络或磁盘，换掉配置读取的同步方式不一定有可见收益；如果配置本身很大，整版复制带来的分配和内存峰值也不能忽略。

这个方案的假设是：读者只需某一版完整配置，不要求在每个读操作中看见最后一次业务提交；写入方能够提交完整快照，而不是反复对共享 map 打补丁。示例采用单写入方，不承诺多写者的版本排序。

构造独立快照再 Store 指针

atomic.Pointer 从 Go 1.19 起提供，零值保存 nil。下面用 ConfigStore 包装原子指针，用内部 config 保存 revision 和 routes。Reload 复制输入 map，失败时不发布半成品；Lookup 返回需要的标量，不把共享 map 直接交给调用方修改。

package main

import (
    "fmt"
    "log"
    "sync/atomic"
)

// config 及其可达数据在发布后只读；Go不会自动强制不可变。
type config struct {
    revision uint64
    routes map[string]string
}

type ConfigStore struct {
    current atomic.Pointer[config]
}

// Reload接收完整版本；调用方不能在此函数复制期间并发修改输入map。
func (s *ConfigStore) Reload(revision uint64, routes map[string]string) error {
    if revision == 0 {
        return fmt.Errorf("配置版本必须大于零")
    }
    copied := make(map[string]string, len(routes))
    for name, target := range routes {
        if name == "" || target == "" {
            return fmt.Errorf("路由名和目标不能为空")
        }
        copied[name] = target // 字符串值复制即可；嵌套指针需另行复制。
    }
    next := &config{revision: revision, routes: copied}
    // 所有字段准备完成后发布；发布后不再写next或copied。
    s.current.Store(next)
    return nil
}

func (s *ConfigStore) Lookup(name string) (uint64, string, bool) {
    snapshot := s.current.Load() // 同一次读取只取得一个版本。
    if snapshot == nil {
        return 0, "", false // 零值atomic.Pointer尚未初始化。
    }
    target, ok := snapshot.routes[name]
    return snapshot.revision, target, ok
}

func main() {
    var store ConfigStore // 使用后只通过指针传递，不复制store。
    input := map[string]string{"report": "worker-blue"}
    if err := store.Reload(1, input); err != nil {
        log.Fatal(err)
    }
    // Reload已复制map；这里没有并发复制发生，修改输入不会改已发布快照。
    input["report"] = "worker-green"
    revision, target, ok := store.Lookup("report")
    fmt.Println(revision, target, ok)

    if err := store.Reload(2, input); err != nil {
        log.Fatal(err)
    }
    revision, target, ok = store.Lookup("report")
    fmt.Println(revision, target, ok)
}

这里最关键的不是 Store 这一行多短，而是 Store 之前已经完成独立副本。输入 map 的复制过程本身不是原子操作，所以调用方必须保证复制期间没有并发写入；仅在复制之后改输入，才是示例展示的隔离关系。

Go 的内存模型规定：当一个原子操作观察到另一个原子操作的效果时，两者建立相应同步关系。因此，读侧观察到已发布的指针后，可以读取发布前准备好的字段；这不授权任何人在发布后继续无同步修改这些字段。

一次 Load 保持同一版配置

Lookup 先保存 snapshot := s.current.Load()，再从 snapshot 读取 revision 与 routes。这样，单次查找中版本号和目标来自同一个对象。不要为每个字段分别 Load：两次调用之间可能发生发布，进而拼出不同版本的字段组合。

持有旧快照的读者可以继续读取旧对象，只要对象始终不可变；新配置发布不意味着所有已开始的读取都立刻切换。对于这个只有普通 Go 数据的例子，旧对象在不再被引用后可由垃圾回收器处理，不需要手动释放。但如果配置持有文件、连接等外部资源，替换指针不等于旧资源已没有使用者，不能马上关闭。

我更愿意把这种设计理解为“读一版配置”，而不是“每个字段都追最新”。如果一次请求要跨多个函数保持同版，也应先确定一份快照的使用范围，而不是让每个函数各自重新取当前值。

把正确性检查和性能比较分开

读者自行运行上面的演示时，第一组预期仍是版本 1 的 worker-blue，第二组预期是版本 2 的 worker-green；这是按代码定义的预期关系，不是本文的输出日志。更重要的检查是：发布后是否仍有代码改写快照，是否有途径把 routes 暴露出去，以及是否在首次初始化之前就开放读取。

在实际项目中，可以自行补充并发读取与周期性 Reload 的测试，再单独使用竞态检测；性能比较应保持相同的配置大小、读写比例、CPU 设置和返回语义。以下只是供读者执行的方法命令，不是本文已经执行的检查。没有 Benchmark 函数时，第二条命令不会自动替你生成基准。

# 在项目已有测试中检查实际执行路径上的数据竞争。
go test -race ./...
# 在相同条件下重复运行已有配置基准；不要把竞态检测开销混入性能比较。
go test -run '^$' -bench Config -benchmem -count=5 ./...

结果对比必须同时看读侧收益与更新分配。本文没有这些数据，因此结论只到“这是一种可用的不可变快照发布结构”，不写“更快多少”“没有 GC 成本”或“所有场景都优于锁”。竞态检测也不能证明所有未执行路径都正确。

哪些写入方式不适合这个例子

如果多个更新者必须合并修改，就需要另行选择写侧串行化或 CompareAndSwap 重试协议。原子 Store 本身不理解 revision，也不保证业务版本递增。本文只展示完整快照的单写方发布，不把增量合并问题藏在实现细节里。

map 的值是切片时还够吗？

不够。复制 map 只复制每个值，切片的底层数组、指针所指对象仍可能共享。需要按数据结构递归复制，或从设计上保证共享部分不再修改。

为什么不直接返回 config 指针？

可以设计只读访问约定，但 Go 不会自动冻结对象。示例选择返回标量来减少误改入口；真实包内代码仍必须遵守发布后只读。

能不能每次读取都复制完整配置？

能，但会改变读侧成本和语义。这里的目标是发布时构建一次独立快照、读时复用，不应再把整版复制藏进高频 Lookup。

参考文档：https://pkg.go.dev/sync/atomic#Pointer；https://go.dev/ref/mem。