Go atomic 操作混用普通读写为什么仍不安全

Go 里把写操作改成 atomic.Store，并不意味着同一个共享变量的普通读取也自动安全。只要某条 goroutine 仍然用普通表达式读取或写入该变量，原子通道和普通通道就可能形成数据竞争。正确做法是先界定共享状态，再让所有入口统一使用原子类型或同一把互斥锁。

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

• 资产：一个会被多个 goroutine 读取和修改的共享变量。
• 风险：atomic 操作之间有同步语义，但普通访问不会被 atomic 自动“包住”。
• 控制：同一变量的所有读写统一为 atomic.Int64、atomic.Value 或 sync.Mutex。
• 验证：代码搜索找全入口，再用 go test -race 检查实际并发路径。

界定受保护资产与风险边界

sync/atomic 提供的是低级原子内存操作。官方文档把 Load、Store、Add、Swap 和 CompareAndSwap 定义为原子等价操作，并说明原子操作之间可以形成顺序一致的观察关系。这个保证的对象是“原子操作”，不是变量地址本身，更不是所有读写语句。

因此下面的资产边界应当写清楚：如果 status 是共享状态，就不能只保护发布端而把读取端留成 if status == 1。读取端没有使用同一套同步方式时，调用者看到的并发关系仍然是不完整的。

用最小案例识别混用路径

最容易漏掉的是“写端已经原子化，读端只是查看一下”的代码。查看本身也属于访问，不能因为它没有修改值就排除在并发审计之外。

package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

var status int64

func main() {
	var wg sync.WaitGroup
	wg.Add(2)

	go func() {
		defer wg.Done()
		// 写端使用原子 Store，表示发布状态的动作不可拆分。
		atomic.StoreInt64(&status, 1)
	}()

	go func() {
		defer wg.Done()
		// 普通读取没有加入 atomic 的同步关系，不能与上面的写端混用。
		if status == 1 {
			fmt.Println("ready")
		}
	}()

	wg.Wait()
}

这段代码的关键问题不是某次运行一定打印错误，而是同一个 status 存在两种访问协议：写入走 atomic，读取走普通表达式。用 race detector 观察并发路径时，问题应按“访问协议不一致”处理，而不是只盯着最终值是否正确。

如果状态变量已经使用原子方式，修复读取端的最小改动是同样使用原子 Load：

func isReady() bool {
	// 读取端与写入端使用同一原子访问协议。
	return atomic.LoadInt64(&status) == 1
}

选择统一访问策略

统一访问不等于所有场景都必须使用 atomic。单个整数计数器、布尔开关或指针状态可以使用类型化原子值；需要整体替换一个不可变配置时，可以用 atomic.Value；如果状态包含多个字段并要求一起检查和修改，互斥锁通常更容易维护。

type Counter struct {
	value atomic.Int64
}

func (c *Counter) Add(delta int64) int64 {
	// 所有增量都通过同一个原子对象进入，避免暴露普通字段。
	return c.value.Add(delta)
}

func (c *Counter) Value() int64 {
	// 读取也走原子 Load，调用者不直接接触内部存储。
	return c.value.Load()
}

若多个字段必须保持一致，例如余额和版本号要成组更新，直接把每个字段分别原子化仍可能产生组合状态不一致。这时用一把锁包住完整临界区更清楚：

type Snapshot struct {
	mu      sync.Mutex
	value   int64
	version uint64
}

func (s *Snapshot) Update(value int64) {
	s.mu.Lock()
	defer s.mu.Unlock()
	// 两个字段必须在同一个临界区内更新，读者不会看到半套状态。
	s.value = value
	s.version++
}

func (s *Snapshot) Read() (int64, uint64) {
	s.mu.Lock()
	defer s.mu.Unlock()
	// 读取与写入使用同一把锁，形成完整的访问边界。
	return s.value, s.version
}

建立审计与验证清单

修复时不要只改报错行，先以共享变量名为中心做一次入口盘点。重点搜索直接赋值、比较、取地址、结构体字段暴露和格式化输出；这些位置都可能是普通访问。

# 先列出共享字段的直接读写位置，再逐项确认保护协议。
rg -n "status|value|version" --glob '*.go'

# 用 race detector 运行测试，观察并发读写是否仍被报告。
go test -race ./...

审计记录至少保留四项：共享变量的所有者、允许的访问 API、是否需要多字段一致性、race detector 覆盖到的测试路径。若测试只覆盖串行调用，未出现报告也不能证明并发入口已经完整覆盖。

常见问题

atomic.Store 已经是原子的，普通读取为什么还不行？

原子性只描述这次 Store 操作；普通读取没有自动加入 atomic 的同步协议。同一共享变量应当让读取端也使用对应的 Load，或者统一交给互斥锁保护。

把变量声明成 int64 就能安全使用吗？

不能。类型宽度与并发同步是两件事。需要原子访问时使用类型化原子对象或对应的 atomic 函数，需要组合一致性时使用互斥锁。

为什么没有看到错误输出也要修？

数据竞争属于访问关系问题，结果可能偶尔看起来正常。应结合代码入口审计和 go test -race 检查，而不是用一次输出替代并发证明。

结论可以收敛为一句话：保护的是共享变量的全部访问路径，而不是其中某一个写操作。只要把读写入口统一到同一种原子或互斥策略，atomic 混用普通读写带来的风险才真正被关闭。