如何在 Go 中利用 atomic 保证操作的可见性

atomic.LoadInt64 读不到最新值？大概率是读写没配对。核心原则很简单：用 atomic.StoreInt64 写入的值，必须用 atomic.LoadInt64 去读取。一旦混入普通读写，就绕过了内存屏障，happens-before 同步机制失效。此外，int64 地址必须 8 字节对齐，否则可能引发 panic。 ### atomic.LoadInt64 读不到最新值？一定是没配对用 Store 直接 `fmt.Println(counter)` 或 `val := counter` 去读一个被 `atomic.StoreInt64(&counter, 100)` 写过的变量，大概率看到旧值。这还真不是 bug，而是绕过了内存屏障——普通读写不参与 Go 的 happens-before 同步机制。 必须严格配对：`atomic.StoreInt64` 写的值，只能靠 `atomic.LoadInt64` 读到最新；反之亦然。混用就等于放弃可见性保证。 - 错误示范：`atomic.StoreInt64(&x, 42)` 后用 `fmt.Println(x)` 读 - 正确做法：所有读写都走 atomic 函数，哪怕只是“看看值” - 验证方式：加 `-race` 运行，这类混用会被竞态检测器直接标出 ### 为什么 int64 普通读写本身可能原子，却还要用 atomic.Load/Store？ 在 64 位系统且地址 8 字节对齐时，`*int64` 的单次读或写确实是硬件原子的（不会读到“高低 32 位撕裂”）。但 atomic 的核心价值不在防撕裂，而在建立内存顺序。 没有 atomic，CPU 和编译器可能重排指令，导致其他 goroutine 看到“写 ready = 1”成功，却仍读到旧的 data 值。而 `atomic.StoreInt64` 插入释放屏障（release fence），`atomic.LoadInt64` 插入获取屏障（acquire fence），强制形成 happens-before 关系。 - 生产者：先写 `data = 123`，再 `atomic.StoreInt64(&ready, 1)` - 消费者：先 `atomic.LoadInt64(&ready) == 1` 成立，之后的 `atomic.LoadInt64(&data)` 才能确保看到 123 - 漏掉任意一个 atomic，整个同步链就断了 ### CompareAndSwap 失败不是错误，是并发常态 `atomic.CompareAndSwapInt64(&x, old, new)` 返回 `false`，只说明“你基于的 `old` 值已过期”，不是操作失败。它本质是“读→算→比→换”四步组合，中间任何一步被抢占，就会失败。 正确模式必须循环重试，不能只调一次： ```go for { old := atomic.LoadInt64(&x) if atomic.CompareAndSwapInt64(&x, old, old+1) { break } // 高竞争下可加 runtime.Gosched()，但多数场景不需要 } ``` - 漏掉循环 → CAS 可能永远不生效，逻辑卡死 - 把 `old` 提前算好再进循环 → 更糟，old 值从一开始就是错的 - CAS 不是设值工具，而是“条件更新”的同步原语，别当普通赋值用 ### 结构体里放 int64 做原子字段，对齐不是可选项 在 ARM32、32 位 x86 或启用 `-gcflags="-d=checkptr"` 时，`atomic.LoadUint64` 对未对齐地址会 panic。Go 要求 `uint64` 地址必须是 8 字节对齐。 结构体字段顺序直接影响偏移量，`unsafe.Offsetof(s.Count) % 8` 必须为 0： - 危险写法：`type Bad { Name string; Count uint64 }` —— `Name` 长度不确定，`Count` 可能不对齐 - 稳妥写法：`type Good { Count uint64; _ [0]byte }` 或把 `uint64` 放最前面 - 验证命令：`go run -gcflags="-d=checkptr" main.go`，运行时立刻暴露对齐问题 指针类型原子操作（`StorePointer`/`LoadPointer`）同样要求存取时类型完全一致，且对象生命周期不能提前结束——这点容易被忽略，但一旦出错就是静默数据损坏。