go 的 sync/atomic 仅支持 int32、int64、uint32、uint64、uintptr 和 unsafe.pointer 等对齐基础类型，不支持 int、uint 及复合类型字段；其原子性限于单操作，无法替代 sync.mutex 提供临界区保护。
Go 的 sync/atomic 不是用来替代互斥锁的通用并发工具，而是为极少数特定场景（如计数器、标志位、无锁数据结构基础操作）提供底层、无锁、单指令级的原子保障。
哪些类型支持 atomic 操作？
Go 要求必须是「可寻址的、底层内存布局对齐的」基础整数类型和指针，包括：int32、int64、uint32、uint64、uintptr、unsafe.Pointer。注意：int 和 uint 不被支持——它们在 32 位和 64 位平台宽度不一致，无法保证原子性。
常见错误现象：cannot call atomic.AddInt with int 或运行时 panic（如用 atomic.StoreUint64(&x, uint64(y)) 但 x 是 int64 类型变量，类型不匹配）。
- 必须显式声明为
int32/int64等，不能依赖类型推导 - 切片、map、struct 字段不能直接原子操作；需操作其字段（且该字段本身是支持类型）
-
atomic.Value是特例，可安全读写任意类型（内部用接口+指针+内存屏障实现），但开销比原生整数操作大
为什么不能用 atomic 替代 sync.Mutex？
原子操作只保证「单个读/写/修改」的不可中断性，不提供「临界区」语义。比如两个 goroutine 同时执行 atomic.AddInt64(&counter, 1)，结果一定正确；但若想「先读再判断再写」（即 check-then-act），atomic 无法保证中间不被抢占——这正是竞态根源。
立即学习“go语言免费学习笔记（深入）”；
典型误用场景：
- 用
atomic.LoadInt64(&flag)判断是否初始化，然后手动 new 对象并atomic.StorePointer—— 这里存在双重检查锁定（DCL）问题，缺少内存屏障或同步原语，可能看到部分构造的对象 - 试图用多个
atomic操作组合模拟锁逻辑（如自旋锁），极易出错且性能未必更好；Go 标准库的sync.Mutex在非竞争时已高度优化（futex + fast path）
atomic.CompareAndSwap 的正确使用姿势
atomic.CompareAndSwapInt64(ptr, old, new) 是实现无锁逻辑的核心，但它不是“乐观锁”魔法：它只返回成功与否，不阻塞、不重试、不处理 ABA 问题。
常见陷阱：
- 忘记检查返回值 —— 失败时必须决定是重试、放弃还是降级为加锁
- 把
old写成字面量（如0），而非当前加载的值，导致 CAS 总失败 - 在循环中调用 CAS 时未重新
Load当前值，造成无限重试或逻辑错误
一个安全的自增计数器片段示例：
for {
old := atomic.LoadInt64(&counter)
if atomic.CompareAndSwapInt64(&counter, old, old+1) {
break
}
}
注意：这不是推荐写法，仅说明原理；日常请直接用 atomic.AddInt64。
内存顺序与 sync/atomic 的隐含约束
Go 的 sync/atomic 所有函数默认提供「sequential consistency」（顺序一致性），即所有 goroutine 观察到的原子操作顺序一致。但这会带来一定性能代价；而像 atomic.LoadAcquire 或 atomic.StoreRelease 这类带显式内存序的函数（Go 1.19+）需谨慎使用——它们绕过默认屏障，容易因重排序引发隐蔽 bug。
绝大多数业务代码无需接触 acquire/release：atomic.LoadInt64 / atomic.StoreInt64 已足够安全；只有在实现高性能无锁队列、状态机等底层组件时，才需精确控制内存可见性边界。
容易被忽略的一点：即使用了原子操作，如果同时混用非原子读写同一变量（比如一边 atomic.StoreInt64，另一边直接 val = counter），Go race detector 会报竞态，且行为未定义。
