Go atomic.Uint64 Load 读取时为什么不提供业务快照一致性

如果一个服务同时维护 total、success 和 failed 三个计数器，分别调用 atomic.Uint64.Load() 并不能得到“同一时刻”的业务报表。Load 只对它绑定的那个 64 位整数负责：每次读取都是原子的，但三次读取之间可能已经发生了新的写入。

要的是单个计数器的实时值，就用 Load；要的是多个字段彼此匹配的快照，就必须把它们放进同一个同步边界，或一次性替换整个不可变对象。

Load 保证的是一个数，不是一份报表

sync/atomic 文档把 Load 定义为原子地加载并返回存储在对象中的值；Uint64 的零值为 0，并且对象第一次使用后不能复制。这些保证的对象都是一个 Uint64，不是包含多个对象的业务结构。

因此下面的写法没有数据竞争，但没有快照一致性：

type Counters struct {
	total  atomic.Uint64
	success atomic.Uint64
	failed  atomic.Uint64
}

func (c *Counters) Report() (uint64, uint64, uint64) {
	// 三次 Load 各自原子，但不属于同一次组合读取。
	return c.total.Load(), c.success.Load(), c.failed.Load()
}

假设读取 total 后，另一个 goroutine 完成了一次成功请求，再读取 success，结果可能是旧的总数配上新的成功数。每个返回值都“真实存在过”，组合起来却不一定对应任何一个完整业务时刻。

为什么多个原子计数器会读出混合时刻

可以把一次报表读取看成三个独立事件：读取总数、读取成功数、读取失败数。并发写入穿插在这些事件之间时，读者拿到的是不同时间点的切片。顺序一致性只描述原子操作在程序中的排序关系，并不会把相邻的三次方法调用合并成一次事务。

用 RWMutex 让组合读取落在同一边界

如果字段更新本来就是一个业务动作，最直观的方式是用锁保护整个结构体。写入成功数和总数时持有写锁，生成报表时持有读锁。这样读操作看到的是某次写入之前或之后的完整状态。

type Snapshot struct {
	Total   uint64
	Success uint64
	Failed  uint64
}

type Counters struct {
	mu sync.RWMutex
	s  Snapshot
}

func (c *Counters) Add(success bool) {
	c.mu.Lock()
	defer c.mu.Unlock() // 保证异常返回时也释放写锁
	c.s.Total++
	if success {
		c.s.Success++
	} else {
		c.s.Failed++
	}
}

func (c *Counters) Report() Snapshot {
	c.mu.RLock()
	defer c.mu.RUnlock() // 复制值后再离开临界区
	return c.s
}

这个方案的关键不是把字段改成普通整数，而是让“更新总数和分类数”成为一次临界区操作。若写入非常频繁、读取远多于写入，读锁竞争仍可能成为成本，这时可以考虑下一种方案。

读多写少时一次性替换不可变快照

将一组统计值封装为不可变的 Snapshot，每次更新都创建新对象，再用 atomic.Pointer[Snapshot] 一次发布。读者拿到的是一个指针指向的完整对象，不需要分别读取多个原子字段。

type Snapshot struct {
	Total   uint64
	Success uint64
	Failed  uint64
}

type Counters struct {
	current atomic.Pointer[Snapshot]
}

func NewCounters() *Counters {
	c := &Counters{}
	c.current.Store(&Snapshot{}) // 先发布一个可读取的零值快照
	return c
}

func (c *Counters) Report() Snapshot {
	return *c.current.Load() // 一个指针对应一组相互匹配的字段
}

func (c *Counters) Replace(s Snapshot) {
	c.current.Store(&s) // 发布后不要再修改 s 的字段
}

示例适合由单个聚合者计算新值、多个 goroutine 读取的场景。Snapshot 发布后必须视为不可变；若还要原地修改它，就重新引入并发问题。atomic.Pointer 也不能在第一次使用后复制。

根据业务关系选择同步方式

先判断字段之间是否必须同时成立：独立的监控计数器可以分别使用 atomic.Uint64；比率、配额、账务摘要或状态机中的多个字段通常需要组合一致性。

• 写入和读取都较多，更新逻辑简单：优先 sync.RWMutex，代码最容易审查。
• 读很多、写入由少数路径集中完成：构造新 Snapshot 后用 atomic.Pointer 发布。
• 只需要一个累计值或单个开关：直接用 Uint64.Load、Add 或 Store。
• 需要跨进程、跨节点一致：内存原子操作不够，还要使用数据库事务、消息确认或外部协调机制。

常见问题

atomic.Uint64.Load 会不会读到半个数字？

它保证单个 Uint64 的原子读取，不会因为并发写入而得到撕裂的半值；这不等于多个读取组成业务快照。

把三个 Load 放进一个函数就一致了吗？

不会。函数边界不是同步边界，仍需锁、不可变快照或其他能覆盖整组字段的发布协议。

可以把 Snapshot 的字段改成 atomic.Uint64 吗？

可以表达各字段独立变化，但仍不能让一次读取自动获得组合一致性；若快照要求字段匹配，发布整体对象更清楚。

atomic.Uint64 结构体能不能按值传递？

第一次使用后不要复制。把它放在长期存活的结构体中，通过指针调用方法，避免返回或赋值时复制同步状态。

参考：Go sync/atomic Uint64 官方文档、Go Memory Model。