Golang atomic.Pointer[T]实现线程安全交换

atomic.Pointer[T]仅用于多goroutine间安全读写指针变量，不保护所指对象内容；适用配置热替换、无锁数据结构头指针更新等场景，禁用作复合操作同步或替代互斥锁。

atomic.Pointer[T] 什么时候该用，什么时候不该用

它只解决一个具体问题：在多个 goroutine 之间安全地读写一个指针变量（*T），且不依赖锁。不是万能“线程安全容器”，不能替代 sync.Mutex 或 sync.RWMutex 去保护结构体字段或复合操作。

典型适用场景是实现无锁栈、链表头指针更新、配置热替换（比如把旧的 *Config 原子替换成新的）、或者作为轻量级状态标记（如 *int32 表示运行中/停止）。

常见误用是试图用它来“保护整个对象”——atomic.Pointer 只保证指针本身的读写原子性，不保证它指向的 T 内容线程安全。如果多个 goroutine 同时修改 *T 的字段，依然要加锁或用其他同步机制。

初始化和 Load/Store 的基本写法

必须显式初始化，否则 Load() 可能 panic（因为内部 unsafe.Pointer 未归零）。不能直接赋值，必须用 Store()。

• var p atomic.Pointer[int] 是合法声明，但此时 p.Load() 返回 nil，不是空指针解引用 panic，但你得自己处理 nil 情况
• 正确初始化方式：p.Store(new(int)) 或 p.Store(&someInt)，不能写 p = atomic.Pointer[int]{}（结构体字面量赋值绕过原子性）
• Load() 总是返回当前指针值（可能是 nil），不阻塞；Store(ptr *T) 要求参数非 nil？不，Store(nil) 是允许的，表示清空指针

CompareAndSwap：为什么它比 “先 Load 再 Store” 更关键

很多初学者以为“我每次 Load() 出来改完再 Store()” 就行了——这完全不安全，中间可能被其他 goroutine 覆盖。真正需要原子条件更新时，必须用 CompareAndSwap(old, new *T)。

它只在当前值等于 old 时才把指针设为 new，并返回是否成功。这是实现无锁算法的基础原语。

• 失败不 panic，返回 false，你要自己重试（通常套个 for 循环）
• old 必须是之前 Load() 或上一次 CompareAndSwap() 成功返回的值，不能凭空构造（比如 &v 新取地址）
• 示例：想把指针从旧配置 oldCfg 替换为新配置 newCfg：

  for {
      if p.CompareAndSwap(oldCfg, newCfg) {
          break
      }
      // 重新 Load 获取最新值，更新 oldCfg，再试
      oldCfg = p.Load()
  }

和 unsafe.Pointer / sync/atomic 其他函数的兼容性坑

atomic.Pointer[T] 底层用的是 unsafe.Pointer，但它封装了类型安全。你不能混用老式 sync/atomic 函数（如 atomic.LoadPointer）去操作它的 unsafe.Pointer 字段——它没公开那个字段，强行反射或 unsafe 转换会破坏类型系统且不可移植。

• 不要试图用 unsafe.Pointer 绕过泛型约束；atomic.Pointer[struct{...}] 是合法的，但别把它转成 atomic.Pointer[any] —— Go 不支持这种协变
• Go 1.19+ 才有 atomic.Pointer，低于此版本只能手写基于 unsafe.Pointer + atomic.LoadPointer/atomic.SwapPointer 的等效逻辑，但会丢失类型检查
• 注意 GC：只要指针被 Store() 进去，GC 就认为它被引用；即使你后续 Store(nil)，之前存过的对象若没其他引用，才会被回收——这点和普通指针一致，但容易在长期运行服务里忽略泄漏路径

最常被跳过的细节是：它不提供“原子读-改-写”的组合操作，所有复合逻辑都得靠 CompareAndSwap 循环实现，而循环里怎么避免 ABA 问题、要不要加 backoff、是否要结合内存屏障（一般不用，CompareAndSwap 自带顺序保证），这些才是真正卡住人的地方。