Go 中原子操作是否建立 happens-before 关系？-Golang-PHP中文网

Go 中原子操作是否建立 happens-before 关系？

Go 的原子操作（如 atomic.StoreUint32 和 atomic.LoadUint32）虽不显式构成 Go 内存模型定义的 happens-before 链，但在当前实现中具有顺序一致性语义，能有效防止编译器重排和 CPU 乱序执行，从而在实践中保证写入顺序对读取可见。

go 的原子操作（如 `atomic.storeuint32` 和 `atomic.loaduint32`）虽不显式构成 go 内存模型定义的 happens-before 链，但在当前实现中具有顺序一致性语义，能有效防止编译器重排和 cpu 乱序执行，从而在实践中保证写入顺序对读取可见。

在原始非原子示例中，a = 1; b = 2 的写入可能被编译器或 CPU 重排，且 g() 中的普通读取无法感知其他 goroutine 的写入顺序，因此可能出现 b=2 而 a=0 的结果——这正是缺乏同步导致的数据竞争。

而使用原子操作后：

var a, b uint32

func f() {
    atomic.StoreUint32(&a, 1) // 原子写 a
    atomic.StoreUint32(&b, 2) // 原子写 b
}

func g() {
    fmt.Println(atomic.LoadUint32(&b)) // 输出 2 或 0
    fmt.Println(atomic.LoadUint32(&a)) // 若上行输出 2，则本行必为 1（实践中保证）
}

虽然 Go 官方内存模型（截至 Go 1.22）并未将连续的 atomic.Store 自动定义为 happens-before 关系（即不保证 StoreUint32(&a,1) happens-before StoreUint32(&b,2) 对所有观察者可见），但关键在于：

Go 编译器禁止对原子操作进行重排序；
底层指令（如 amd64 上的 XCHG、MOV + MFENCE 组合）提供全内存屏障（full memory barrier）语义；
所有原子操作默认以 Relaxed 以外的更强语义实现（实际等效于 SequentiallyConsistent）。

因此，在 g() 中若观测到 b == 2，说明 f() 已执行完 atomic.StoreUint32(&b, 2)；由于 StoreUint32(&a, 1) 在程序顺序上先于该操作，且无重排，它必然已完成——故 a 必为 1。这一行为在所有支持架构（amd64/arm64/ppc64）上均被 Go 运行时严格保障。

⚠️ 注意事项：

不可依赖未文档化的语义：Go issue #5045 明确指出，当前“原子操作隐含顺序一致性”属于实现细节，未来版本理论上可放宽（例如引入更轻量的 atomic.StoreRelaxed）。
正确做法是显式建立 happens-before：若需强保证，应使用 sync.Mutex、sync.WaitGroup，或搭配 atomic.CompareAndSwap + 循环等待，或采用 atomic.Store/atomic.Load 配对并辅以 runtime.Gosched() 等防御性措施。
避免误用 atomic.Value 替代数值原子操作：atomic.Value 适用于任意类型载荷，但开销更大，且不提供数值比较逻辑。