原子类型与普通字段混用导致竞态的修复

我遇到过一种很容易被误判的 Go 并发问题：统计总数一直在增长，看起来像是原子操作已经把结构体保护好了，但同一次快照里的 lastID 偶尔回退，go test -race 却直接指出普通字段存在并发读写。根因不是 atomic 失效，而是同一个对象里有两套同步规则。

修复原则很简单：每个共享字段的所有访问都必须走同一种同步方式；如果多个字段必须代表同一个时刻，就要让同步边界覆盖整个快照，而不能只把其中一个字段改成原子类型。

原子字段只保证自己的访问原子，不能替同一结构体里的普通字段“自动加锁”。独立数值可以全部改用 atomic；有关联一致性的字段，应统一放进 mutex 或不可变快照的边界内。

竞态现场：原子计数正常，普通字段不稳定

下面这个结构体在代码评审里很像合理实现：计数用 atomic.Int64，最后处理的 ID 只是一个整数，读取成本低，于是保留成普通字段。

package stats

import "sync/atomic"

type Stats struct {
	total  atomic.Int64 // 计数器使用原子类型
	lastID int64        // 这个普通字段仍会被多个 goroutine 访问
}

func (s *Stats) Record(id int64) {
	s.total.Add(1) // 这次加法本身是原子的
	s.lastID = id  // 普通写入没有同步保护
}

func (s *Stats) Snapshot() (int64, int64) {
	return s.total.Load(), s.lastID // 读取路径同样混用了两套规则
}

当 Record 和 Snapshot 在不同 goroutine 中并发执行时，total 的访问是原子的，但 lastID 仍然是一条普通读写边。竞态检测器看到的正是后者；它不会因为两个字段属于同一个 Stats 就推断它们共享同步关系。

触发条件：一次原子访问不能覆盖相邻字段

这里最容易混淆的是“原子操作有顺序一致性”和“整个结构体是一致快照”是两件事。sync/atomic 只定义参与原子操作的那个地址如何被访问；lastID 没有使用 Load 或 Store，仍然属于普通内存访问。

因此下面三种情况要分开看：

• 只有 total 共享：所有读写都用 Load、Store 或 Add，可以使用原子类型。
• lastID 也独立共享：它必须改成 atomic.Int64，并禁止直接读写底层值。
• total 与 lastID 必须配对：两个独立原子字段仍可能分别读到不同时间点，应该用锁或一次性发布的快照。

Go 内存模型把并发普通读写定义为数据竞态；只有所有相关访问都采用原子数据访问或其他同步原语，程序才拥有可推理的 happens-before 关系。不要把“当前机器上读到的值看起来正常”当成同步证明。

修复要点：让同步边界覆盖完整对象

如果两个值互不依赖，最小改法是把普通字段也改为原子类型：

type Stats struct {
	total  atomic.Int64 // 独立计数全部通过方法访问
	lastID atomic.Int64 // ID 的读写也必须走原子方法
}

func (s *Stats) Record(id int64) {
	s.total.Add(1)     // 原子增加计数
	s.lastID.Store(id) // 原子写入最后 ID
}

func (s *Stats) LastID() int64 {
	return s.lastID.Load() // 不暴露底层字段，避免调用方绕过边界
}

但如果调用方要求 total 和 lastID 代表同一批处理状态，就不要只做字段级原子化。更直接的办法是用互斥锁保护组合快照：

import "sync"

type Snapshot struct {
	Total  int64 // 与 LastID 必须来自同一次快照
	LastID int64
}

type Stats struct {
	mu sync.RWMutex // 锁覆盖整组相关字段
	v  Snapshot
}

func (s *Stats) Record(id int64) {
	s.mu.Lock()
	defer s.mu.Unlock() // 保证异常返回时也释放写锁
	s.v.Total++
	s.v.LastID = id
}

func (s *Stats) Snapshot() Snapshot {
	s.mu.RLock()
	defer s.mu.RUnlock() // 读快照期间阻止并发写入
	return s.v
}

读多写少、且状态可以整体替换时，也可以构造不可变 Snapshot 后通过 atomic.Value 一次发布。选择哪种方式取决于“字段是否需要成组一致”，而不是取决于代码里有没有出现 atomic。

防止复发：把同步规则藏进 API

我最后保留了三条简单的复查规则：第一，结构体里的共享字段不允许一部分通过方法访问、另一部分直接读写；第二，命名为 Snapshot 的返回值必须说明是否要求同一时刻；第三，修改并发结构后用 go test -race ./... 做针对性复查，不只观察业务输出是否“看起来正常”。

如果一个字段只是独立计数，使用 atomic.Int64 很合适；如果多个字段描述一条业务状态，优先让一个方法返回完整值，并在方法内部统一使用锁或原子快照。同步边界越清楚，后续维护时越不容易再次把普通字段混进原子结构。

相关问题

把 lastID 改成 atomic.Int64 后，就一定能得到一致快照吗？不一定。它能消除该字段自身的普通读写竞态，但两个原子字段分别读取时仍可能来自不同更新时刻；需要成组一致时仍应使用锁或整体发布的不可变快照。

为什么不直接给所有字段都加 atomic？原子类型适合独立值，不能表达复杂对象的事务性更新。字段之间有不变量时，锁或整体替换通常更清楚。