Go atomic.Int64记录并发计数的初始化与读取方式

并发计数最容易出问题的地方，不是把字段改成 int64，而是让多个 goroutine 同时读写它。Go 现代版本可以直接使用 sync/atomic 提供的 atomic.Int64：字段类型本身表达“这是一个原子值”，写入用 Add 或 Store，读取用 Load，不再把原始整数和原子操作混在一起。

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

如果计数只需要递增和读取，把它声明为 atomic.Int64，创建后用 Load 读取、用 Add(1) 递增；只有需要覆盖当前值时才使用 Store。

atomic.Int64 的字段声明与初始化边界

类型化原子值适合放在计数器、并发请求数、队列长度等共享状态中。它的零值就是 0，因此下面的结构体不需要额外构造函数也能开始计数：

package counter

import "sync/atomic"

type Stats struct {
	// Requests 只能通过 Add、Load、Store 等原子方法访问。
	Requests atomic.Int64
}

func (s *Stats) Record() int64 {
	// Add 返回递增后的值，适合顺便判断当前阈值。
	return s.Requests.Add(1)
}

func (s *Stats) Current() int64 {
	// Load 获取一个原子快照，不保证后续仍保持这个数值。
	return s.Requests.Load()
}

如果业务起点不是 0，可以在对象创建阶段调用 Store。初始化完成后，计数路径仍然应该统一使用原子方法，避免一部分代码通过普通赋值修改同一状态。

用 Add 记录并发事件，用 Load 读取当前值

Add(delta) 是记录事件的主路径。多个 goroutine 同时调用 Add(1) 时，每次增量都会参与原子更新；返回值是本次更新之后的结果，可以直接用于限流提示、批量刷新或采样。

func (s *Stats) RecordAndCheck(limit int64) bool {
	// 返回值属于本次递增后的状态，适合做一次性的边界判断。
	current := s.Requests.Add(1)
	return current >= limit
}

func (s *Stats) Snapshot() (int64, bool) {
	// 读取与判断使用同一个快照，避免同一函数里重复读取造成语义漂移。
	current := s.Requests.Load()
	return current, current > 0
}

需要注意，Load 只保证这次读取本身是原子的。它不能把“读取、判断、再修改”自动组合成一个不可分割的事务。例如“只有低于上限才加一”就不能仅靠 Load 加 Add 保证，需要根据业务改用 CAS 循环，或者把状态交给互斥锁保护。

Store、Add 与普通整数读写的选择

可以把几个操作的语义放在一起比较，减少因为方法名相近而产生的误用：

“累计一次”用 Add，“读取一次”用 Load，“明确重置”才用 Store。不要写成普通的 s.Requests = 1 或把原子值转换成 int64 后再赋回去；这种混用会让调用约定失效，也可能重新引入数据竞争。

复制限制与并发计数的排查清单

类型化原子值应当在声明后保持稳定的内存位置。尤其不要在它开始工作后复制包含 atomic.Int64 的结构体，也不要通过值接收者把整个计数器复制到方法内部。更稳妥的接口是使用指针接收者，并让共享对象在 goroutine 之间传递指针。

排查时可以依次确认：

• 所有写入是否都集中在 Add、Store 或明确的 CAS 逻辑中。
• 所有读取是否都经过 Load，日志和指标代码没有直接读普通镜像字段。
• “判断后修改”是否真的需要原子复合操作，而不是两个独立原子方法。
• 结构体是否在第一次使用后被复制，构造函数和方法是否保持指针语义。

最后运行 go test -race ./... 检查计数器周围的共享数据。竞态检测不能证明业务阈值逻辑正确，但能帮助发现把原子计数和非原子字段绑在一起的遗漏。

常见问题

atomic.Int64 的零值可以直接使用吗？

可以。零值可直接调用 Add 和 Load；如果初始值来自配置或上一个窗口，建议在对象交给并发代码前显式调用 Store。

Add 和 Store 都能写入，为什么不统一使用 Store？

Store 是覆盖，多个 goroutine 用它模拟累加会互相覆盖结果；计数递增应使用 Add，只有重置或载入新基线才使用 Store。

Load 后再判断上限安全吗？

读取本身安全，但“读取后再修改”不是一个原子事务。若上限判断必须和更新绑定，应使用 CAS 循环或互斥锁保护完整业务动作。