Go 中不能自行编写 CAS 汇编指令，必须使用 sync/atomic 包提供的固定类型原子函数，因其涉及 GC、内存模型与竞态检测等运行时强约束。
CAS 在 Go 里不能直接用汇编指令手写，必须通过 sync/atomic 包提供的原子操作函数实现，且仅支持固定类型和固定操作——这是最常被误以为“能自由 CAS”的认知偏差源头。
为什么不能自己写 CompareAndSwap 汇编逻辑
Go 运行时（runtime）对调度器、GC、栈增长等深度依赖内存模型和原子指令的语义一致性。手动内联汇编或绕过 sync/atomic 调用底层 CMPXCHG 会破坏：
- GC 对指针字段的扫描（非 unsafe.Pointer 类型无法被识别）
- 编译器对内存顺序的优化判断（如重排序、缓存行对齐）
- go build -race 竞态检测器失效
所以 Go 明确禁止用户自行实现 CAS 原语，所有合法 CAS 必须走 sync/atomic 导出的函数。
sync/atomic.CompareAndSwap* 系列函数怎么选
Go 只为有限类型提供 CompareAndSwap：
- 整数类：CompareAndSwapInt32、CompareAndSwapInt64、CompareAndSwapUint32、CompareAndSwapUint64、CompareAndSwapUintptr
- 指针类：CompareAndSwapPointer（唯一支持任意结构体地址的入口，但需配合 unsafe.Pointer 转换）
- 注意：CompareAndSwapBool 不存在，需用 int32 模拟（0/1）
- 不支持 float、struct、interface{} 直接 CAS；若需更新结构体字段，必须拆成字段级原子变量，或用 CompareAndSwapPointer 替换整个结构体指针（并确保旧值可安全释放）
用 CompareAndSwapPointer 实现无锁栈的典型陷阱
常见错误是忽略内存可见性与生命周期管理：
- CompareAndSwapPointer 本身只保证指针值的原子替换，不自动同步所指向数据的修改
- 若新节点在 CAS 前被 GC 回收（比如局部变量逃逸失败），会导致悬垂指针
- 正确做法：节点必须分配在堆上（如 &node{}），且旧节点引用需在 CAS 失败后显式保留（避免提前释放）
- 示例关键片段：
type Node struct {
Value int
Next *Node
}
func (s *Stack) Push(v int) {
for {
top := atomic.LoadPointer(&s.head)
newNode := &Node{Value: v, Next: (*Node)(top)}
if atomic.CompareAndSwapPointer(&s.head, top, unsafe.Pointer(newNode)) {
return
}
// 不要在这里调用 runtime.GC() 或 free newNode —— 它可能正被其他 goroutine 读取
}
}注意：unsafe.Pointer 转换必须严格配对，且 Node 不能含 interface{} 或 map 等需 GC 跟踪的字段（否则 GC 可能漏掉）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
性能与调试：CAS 失败率高时的实际表现
高频 CAS 冲突不会 panic，但会显著拖慢吞吐：
- 每次失败都意味着重试循环 + CPU 自旋，可能引发 cache line bouncing（多核间反复无效化同一缓存行）
- go tool trace 中会显示大量 “ProcStatus” 切换和 “Syscall” 尖峰（因调度器被迫介入）
- 推荐策略：
- 用 runtime.Gosched() 在重试间隙主动让出时间片（尤其在预期冲突率 > 10% 时）
- 避免在单个 CompareAndSwap* 上封装复杂逻辑（比如先计算再 CAS），应把计算提到循环外
- 测试时务必用 GOMAXPROCS=4 以上 + -race 运行，否则很难暴露 ABA 问题（Go 中虽较少见，但在指针复用场景仍存在）
真正难的不是调用 CompareAndSwapPointer，而是设计时想清楚：哪些状态必须原子切换、旧值是否还被其他 goroutine 持有、GC 是否能正确追踪所有指针路径——这些决定了你的“无锁”到底是高效并发，还是更隐蔽的竞态温床。
