Go atomic 操作和普通读写混用为什么仍有数据竞争

我排查这类 Go 并发问题时，最容易被忽略的不是 atomic.Store 本身，而是同一个共享变量还有一条普通读写路径。结论很明确：atomic 只约束实际调用 atomic API 的那次访问，不能替旁边的普通赋值或普通读取建立统一的并发协议。只要这些访问可能并发发生，普通读写和其它访问之间就可能形成数据竞争。

官方文档：https://pkg.go.dev/sync/atomic；内存模型：https://go.dev/ref/mem。

修复这类问题的关键不是“给某一次写加 atomic”，而是让同一个共享状态的所有并发访问都使用同一套协议：全部原子访问，或者全部放进同一把互斥锁保护的临界区。

为什么一次 atomic.Store 不能保护旁边的普通读写

下面的代码看起来像是“写入已经原子化”，但读取仍然直接访问普通变量：

var ready int64

func publish() {
	// 这一次写入具备原子语义，但只覆盖当前调用。
	atomic.StoreInt64(&ready, 1)
}

func isReady() bool {
	// 普通读取没有加入同一套同步协议，不能与上面的写配对。
	return ready == 1
}

如果一个 goroutine 调用 publish，另一个 goroutine 同时调用 isReady，它们访问的是同一个内存位置，而且一边写、一边读。问题不在于整数是否“通常一次写得完”，而在于这两次访问的同步关系不一致。Go 内存模型把并发读写同一变量且至少一方写入定义为数据竞争，只有涉及的访问都属于原子数据访问时才不属于这类竞争。

因此，“写入用了 Store”和“这个变量是安全的”是两句话。变量的安全性取决于所有并发访问点，而不是某个函数名里出现了 atomic。

同一个变量怎样统一成完整的原子访问

如果共享状态就是一个独立的整数、布尔值或指针，最简单的做法是封装访问入口，禁止业务代码绕过入口直接读写：

var ready atomic.Int64

func publish() {
	// Store 与 Load 使用同一个原子变量类型，避免出现旁路普通访问。
	ready.Store(1)
}

func isReady() bool {
	// 读也必须通过原子方法完成，访问协议才是完整的。
	return ready.Load() == 1
}

旧式的 atomic.StoreInt64 和 atomic.LoadInt64 也可以使用，但要把指针传递、对齐和所有调用点管理好。使用 atomic.Int64、atomic.Bool 等类型时，通常更容易在代码评审中发现“漏掉一次普通读取”的问题。

需要“读取旧值、判断条件、写入新值”时，普通的 Load 加 Store 仍然可能丢更新，应使用 CompareAndSwap：

var quota atomic.Int64

func tryAcquire() bool {
	for {
		old := quota.Load()
		// 先读出当前值，达到上限时不再修改共享状态。
		if old >= 10 {
			return false
		}
		// CAS 失败表示期间有别的 goroutine 更新，循环重新读取。
		if quota.CompareAndSwap(old, old+1) {
			return true
		}
	}
}

这里的重点仍然是“所有访问都原子化”。如果另一个位置还写着 quota = 0，即使竞争者都使用 CAS，协议也会被普通写破坏。

什么时候应该改用 Mutex

atomic 适合一个小而独立的状态，例如计数器、开关或发布一个不可变指针。如果一次操作要同时维护多个字段，就不要把每个字段分别做成 atomic 再期待它们天然一致：

type Snapshot struct {
	Version int
	Name    string
}

type Store struct {
	mu   sync.RWMutex
	data Snapshot
}

func (s *Store) Update(v int, name string) {
	s.mu.Lock()
	defer s.mu.Unlock() // 释放锁，保证异常返回时也不会遗留临界区。
	s.data = Snapshot{Version: v, Name: name}
}

func (s *Store) Read() Snapshot {
	s.mu.RLock()
	defer s.mu.RUnlock() // 读操作也遵守同一把锁的访问协议。
	return s.data
}

当你需要“读取字段、检查条件、修改多个字段”这一整段不可分割时，Mutex 往往比拼接多个原子变量更直观。判断标准是共享不变量：只要读者不能看到半更新状态，就应把相关数据放进同一个临界区，或发布一个完整且不可变的快照。

怎样用 race 检测确认修复方向

Go 自带的 race detector 只能发现实际执行到的竞争路径，所以测试要让多个 goroutine 真正同时访问同一个状态。常见命令如下：

# 用竞态检测运行当前模块的测试，覆盖测试实际走到的并发路径。
go test -race ./...

# 如果问题只在服务运行期间出现，也要用 -race 构建后压测或回放真实流量。
go build -race ./cmd/server

看到报告后，先按报告中的读写位置回到同一个共享变量，再检查是否存在一条普通访问路径。不要因为某次 -race 没报错就认定代码绝对安全：官方说明也强调，检测器只能发现运行时发生的竞争，测试覆盖不足时仍可能漏报。

可以用下面这张速查表做最后判断：

相关问题

atomic.Load 和 atomic.Store 都用了，还会有数据竞争吗？

如果同一内存位置的所有并发访问都确实通过匹配的原子操作完成，通常不会因为这些访问本身形成普通数据竞争；但仍要检查指针指向的对象、其它字段和复合不变量是否被并发普通访问。

为什么加了 atomic 还是可能读到旧值？

原子访问解决的是访问的同步与可见性边界，不等于业务条件已经满足，也不代表多个变量的更新组成一个整体。需要复合条件时，应重新设计状态协议或使用锁。