Go atomic.Uint64 怎么实现无锁计数并读取一致快照

接口请求数、已处理任务数、缓存命中数这类指标，通常只需要一个不断递增的整数。多个 goroutine 同时执行 count++ 时，读改写不是一个原子动作，结果可能丢失；直接给同一个 uint64 读写也不能替代同步。更合适的做法是把计数器声明为 atomic.Uint64，写入用 Add，读取用 Load。

Go atomic.Uint64 的接口目标是把共享计数变成原子值

atomic.Uint64 是 sync/atomic 提供的类型化原子整数，零值为 0。它的接口目标很窄：让一个共享的无符号 64 位整数能够被多个 goroutine 原子更新和读取，而不是替你保护旁边的业务字段。

调用方最常用的三个方法是：Add(delta) 原子加法并返回新值，Load() 原子读取当前值，Store(value) 原子替换当前值。需要条件更新时再考虑 CompareAndSwap(old, new)。实例在第一次使用后不要复制，也不要把它放进会被整体复制的值类型流程里；如果需要共享，传递指针或让它属于长期存活的结构体。

Add 与 Load 怎样配合完成无锁计数

下面的计数器把“事件发生”与“读取展示”分开：工作 goroutine 只调用 Add，统计接口只调用 Load。这里的无锁，指这个计数路径不需要由调用方显式持有互斥锁；它不表示没有硬件原子指令或内存同步成本。

package counter

import "sync/atomic"

type Requests struct {
	// 首次使用后不要复制这个原子字段所在的结构体。
	total atomic.Uint64
}

func (r *Requests) Record() uint64 {
	// Add 返回递增完成后的值，适合记录或触发阈值判断。
	return r.total.Add(1)
}

func (r *Requests) Snapshot() uint64 {
	// Load 只读取这个计数器，不会阻塞其他 goroutine 的 Add。
	return r.total.Load()
}

如果只想“记一笔”，可以忽略 Add 的返回值；如果要在达到阈值时做一次动作，返回值也不能自动保证动作只执行一次，仍要用 CAS 或其他协调手段保护触发权。相比手写 Load、加一、Store，Add 把读改写合并成一个原子操作，避免两个 goroutine 读到同一个旧值后互相覆盖。

一致快照能保证什么，不能保证什么

对单个 atomic.Uint64 而言，Load 不会返回半个旧值和半个新值；它返回某个原子读取看到的完整整数。Go 内存模型也规定，原子操作之间具有同步语义，并按顺序一致的方式观察原子操作。

但“读取一致快照”必须先定义对象。若快照只有 total 一个字段，Load 就足够。若快照同时包含 success、failed 和 lastError，分别调用三个 Load 只能得到三个独立时刻的值：期间另一个 goroutine 可能已经更新了其中一个字段。此时应把完整快照封装成不可变对象，再用 atomic.Pointer 发布，或让读写都经过同一把 mutex；不要用多个原子字段拼出未经定义的事务状态。

还有一个边界：原子计数只同步它自己。它不会让一个普通 map、切片或结构体字段自动变得并发安全。若计数更新必须与业务状态同时成功，优先把两者放入同一个临界区，而不是靠“先 Add、再改字段”猜测顺序。

常见问题：什么时候仍然需要互斥锁

atomic.Uint64 能替代所有计数场景的 mutex 吗？

不能。单个独立计数器适合 atomic；更新计数同时还要维护 map、切片或多个相互约束的字段时，mutex 更容易表达整体不变量。

为什么 Add 后马上 Load 仍可能不是我想要的快照？

当前 goroutine 能观察到自己的原子更新，但其他 goroutine 仍可能在两次操作之间继续 Add。若需要“读取并清零”这样的组合动作，应使用 Swap(0)，而不是拆成 Load 加 Store。

atomic.Uint64 可以直接复制吗？

不可以。文档明确要求原子类型第一次使用后不能复制；把它放进会被复制的结构体、按值传参或值接收者方法中，都可能破坏这个约束。