Go atomic.Int64 怎样安全更新并发计数器

如果多个 goroutine 同时维护请求总数、在途任务数或库存尝试次数，直接写 count++ 不是并发安全的：读取、加一、写回是多个动作，交错后会丢更新。一个只需要维护单个整数状态的场景，可以使用 sync/atomic 提供的 atomic.Int64。它的常用边界很清楚：Add 负责原子增减，Load 读取快照，Store 替换整个值，条件更新则使用 CompareAndSwap。

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

先把普通自增的竞态拆开

假设服务要统计当前正在处理的请求数。普通整数的自增大致包含“读出旧值、计算新值、写回”三个阶段，两个 goroutine 可能同时读到 10，最后都写回 11，实际应有的两次增量就少了一次。

atomic.Int64 把这个单值更新动作交给原子操作完成。它可以使用零值直接声明，不需要先调用构造函数；但一个原子值第一次使用后就不应再复制，应该让多个 goroutine 共享同一个实例。

用 Add 和 Load 维护在途计数

package counter

import "sync/atomic"

// InFlight 记录当前正在处理的任务数量；零值即可使用。
type InFlight struct {
	value atomic.Int64
}

// Begin 增加一个任务，并返回增加后的计数。
func (c *InFlight) Begin() int64 {
	// Add 是原子增量，避免多个 goroutine 同时更新时丢失结果。
	return c.value.Add(1)
}

// End 在任务结束时配对减少计数。
func (c *InFlight) End() int64 {
	// 用负数回收一次任务；调用方应保证 Begin 与 End 成对。
	return c.value.Add(-1)
}

// Current 读取一个当下快照，不会锁住后续的更新。
func (c *InFlight) Current() int64 {
	return c.value.Load()
}

这里的关键不是把所有状态都换成原子类型，而是把状态缩小为一个整数。处理函数开始时调用 Begin，退出路径用 defer c.End() 配对；监控端调用 Current 得到的是某一时刻的快照，不应把它理解为一份长时间有效的承诺。

有上限时不要把 Load 和 Add 分成两步

“当前值小于上限才加一”是一个复合条件。如果先 Load，再判断，最后 Add，多个 goroutine 仍可能同时通过判断，导致上限被突破。此时应该用 CompareAndSwap 循环，把“确认旧值”和“写入新值”绑定在一次条件更新中。

package limiter

import "sync/atomic"

// Counter 表示一个只允许增长到 limit 的并发计数器。
type Counter struct {
	value atomic.Int64
	limit int64
}

// TryAdd 尝试增加一个名额；返回 false 表示已经达到上限。
func (c *Counter) TryAdd() bool {
	for {
		old := c.value.Load()
		if old >= c.limit {
			// 先读快照做快速拒绝，避免无意义的 CAS。
			return false
		}
		// 只有旧值仍未变化时才提交这次占用。
		if c.value.CompareAndSwap(old, old+1) {
			return true
		}
		// 竞争者已经更新，重新读取并判断新的边界。
	}
}

CAS 失败不是异常，而是说明期间有其他 goroutine 改过计数。循环重新读取即可。若业务还要同时修改用户状态、记录明细并发送通知，就不应只靠一个原子整数拼出“事务”；那类多对象一致性更适合互斥锁、channel 或数据库事务。

四个容易忽略的边界

• 不要复制：包含 atomic.Int64 的结构体应使用指针传递；第一次使用后复制会破坏并发语义。
• 不要混用普通读写：对同一个字段，不能一边用 Add，另一边直接访问底层整数。
• 不要误解 Load：它只返回瞬时快照，读取后再做多步业务判断时仍要考虑竞争。
• 不要滥用原子操作：多个字段必须一起变化时，原子整数无法替代锁或更高层的协调机制。

总结与常见问题

单值并发计数优先从 atomic.Int64 的 Add、Load 开始；有严格上限时使用 CompareAndSwap 循环；涉及多个状态的整体一致性时回到互斥锁或 channel。这样既能避免普通自增丢更新，也能让同步边界保持可读。

为什么不用 Store 做自增？因为 Load 后再 Store 仍是分离的读改写，竞争时会丢更新；自增应使用 Add 或 CAS。

atomic.Int64 能保证一组字段同时更新吗？不能。它只覆盖自身这个整数的位置，跨字段约束需要锁、channel 或外部事务来协调。