Go并发编程中atomic包如何使用_Go原子操作讲解

atomic.LoadUint64总返回0通常因传入未初始化或栈上临时变量的地址；须确保指针指向包级变量或堆分配的持久内存。

atomic.LoadUint64 为什么总返回 0？检查是否用了未初始化的指针

常见错误是把 uint64 变量地址传给 atomic.LoadUint64，但变量本身没初始化，或者传了栈上临时变量的地址。该函数只接受 *uint64，且要求地址有效、生命周期足够长。

• 确保变量声明为包级变量或显式分配在堆上（如用 new(uint64)）
• 不要对局部变量取地址后传给原子操作函数，逃逸分析可能不保证安全
• 确认没有重复声明同名变量覆盖了原始指针（比如循环里 var x uint64; p := &x）

var counter uint64 = 100
// ✅ 正确：包级变量，地址稳定
fmt.Println(atomic.LoadUint64(&counter))

// ❌ 错误示例（编译能过，但行为未定义）：
// func bad() {
//     var x uint64 = 42
//     fmt.Println(atomic.LoadUint64(&x)) // x 在函数返回后失效
// }

CompareAndSwapInt32 的失败不是 bug，而是并发控制的正常反馈

atomic.CompareAndSwapInt32 返回 bool 表示“旧值匹配且已更新”。它不抛异常，也不重试——这是设计使然。你得自己决定是否重试、何时放弃、要不要加 backoff。

• 典型场景是实现无锁计数器、状态机跃迁（如从 0 → 1 表示“启动中”）
• 如果期望“一定成功”，需配合 for 循环 + 条件判断，即 CAS 自旋
• 注意：过度自旋会浪费 CPU，高竞争下建议结合 runtime.Gosched() 或短时休眠

var state int32 = 0
for !atomic.CompareAndSwapInt32(&state, 0, 1) {
    // 当前 state 不是 0，说明已被其他 goroutine 占用
    // 可选择继续等待、返回错误，或稍作让出
    runtime.Gosched()
}

StorePointer 和 LoadPointer 必须配对使用，且类型要严格一致

Go 的 atomic.StorePointer 和 atomic.LoadPointer 操作的是 unsafe.Pointer，不进行类型

检查。一旦存入和读出的底层结构不匹配（比如存了 *A 却当 *B 读），就会触发未定义行为，甚至崩溃。

• 务必用 unsafe.Pointer(&x) 存，用 (*T)(atomic.LoadPointer(&p)) 读，且 T 必须和存入时的原始类型完全一致
• 不能跨包直接传递裸 unsafe.Pointer，容易丢失类型上下文
• Go 1.19+ 支持泛型封装，可写个类型安全的 wrapper，避免手写 unsafe

var ptr unsafe.Pointer
type Config struct{ Timeout int }
cfg := &Config{Timeout: 5}
atomic.StorePointer(&ptr, unsafe.Pointer(cfg))
// ✅ 正确读取
loaded := (*Config)(atomic.LoadPointer(&ptr))
fmt.Println(loaded.Timeout) // 5

不要用 atomic 替代 mutex 处理复杂状态，尤其涉及多个字段时

原子操作只保证单个值的读写线性化，无法原子地更新两个关联字段（如 count 和 sum）。试图用多个 atomic 操作拼凑“逻辑原子性”，大概率导致中间态被其他 goroutine 观察到，引发数据不一致。

• 当需要保护一组字段、或执行多步条件逻辑（如“若余额 > X 则扣款并记录日志”），必须用 sync.Mutex 或 sync.RWMutex
• atomic 适合高性能热点路径：计数器、开关标志、单指针替换、序列号生成等
• 一个易忽略点：atomic 不提供内存屏障之外的同步语义，比如不会阻止编译器或 CPU 重排非原子访问

真正难的不是调用哪个函数，而是判断“这里到底需不需要原子性”以及“这个变量的修改是否独立于其他状态”。很多并发 bug 源于过早优化——先用 sync.Mutex 写正确，再看 profile 数据决定是否值得换成 atomic。