Go的sync/atomic函数最终编译为对应CPU架构的硬件原子指令：x86-64下atomic.AddInt64生成lock xaddq，CAS生成lock cmpxchgl；ARM64下则用ldxr/stxr指令对配合DMB屏障实现，均依赖硬件保证原子性与缓存行排他访问。
sync/atomic 的 Go 函数最终编译成什么汇编指令？
Go 的 sync/atomic 函数不是纯软件模拟，而是直接映射到 CPU 原子指令。以 x86-64 为例：atomic.AddInt64(&x, 1) 编译后通常是 lock xaddq；atomic.CompareAndSwapInt32(&v, old, new) 对应 lock cmpxchgl。ARM64 下则用 ldxr/stxr 指令对配合内存屏障实现。这些指令的共性是：必须由硬件保证执行期间不被中断，且对缓存行（cache line）有排他访问语义。
“LOCK 前缀”到底锁了什么？不是锁内存地址
很多人误以为 lock 是锁某个内存地址，其实它锁的是 CPU 与内存之间的数据通路——在早期 x86 中表现为“总线锁定（Bus Locking）”，即禁止其他核心通过前端总线访问同一缓存行；现代 CPU 多采用更轻量的“缓存锁定（Cache Locking）”，依赖 MESI 协议将目标缓存行置为 Exclusive 或 Modified 状态，此时其他核心对该行的读写请求会被阻塞或失效。这意味着：
-
lock指令的开销与缓存一致性协议强相关，而非内存带宽 - 若操作跨缓存行（如未对齐的 8 字节
int64在某些旧架构上），可能退化为真实总线锁，性能骤降 - ARM64 不支持
lock前缀，所以 Go 在该平台必须用ldxr/stxr循环重试，本质是乐观自旋
为什么 atomic.StoreUint64 有时比 atomic.StoreUint32 慢？
这不是 Go 实现的问题，而是硬件限制。在 32 位系统或某些 ARM 架构上，uint64 存储无法用单条原子指令完成，Go 运行时会 fallback 到基于 atomic.CompareAndSwapUint64 的循环写入（即 CAS loop），而 uint32 可直通硬件原子指令。即使在 64 位 x86 上，若变量未按 8 字节对齐（例如嵌套在 struct 中且前面字段导致偏移非 8 倍数），go tool compile -S 会显示生成的是 call runtime∕internal∕atomic·Store64 ——这是运行时兜底函数，含锁逻辑，彻底失去无锁优势。
atomic.Value.Load 的汇编行为容易被忽略
atomic.Value 是 Go 提供的任意类型原子容器，但它的 Load() 方法底层并非单条原子指令。它实际是先原子读一个 unsafe.Pointer，再做类型转换和内存屏障插入。关键点在于：atomic.Value 的零值不是安全的初始状态，必须显式调用 Store() 初始化一次，否则首次 Load() 可能 panic 或读到未定义内存。它的汇编输出里看不到 lock，但包含 mov + lfence（或等效屏障），因为 Go 编译器会在 atomic.LoadPointer 后自动插入内存顺序约束（默认 seqcst）。
真正踩坑的地方往往不在“用了 atomic”，而在于假设“所有 atomic 操作都对应一条硬件指令”——对齐、平台差异、类型大小、内存顺序隐含开销，任何一个没对齐，就悄悄退化成软件回退路径。
