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