atomic.AddInt64 与 mutex.Lock/Unlock 基准测试需拆分为独立函数，各自使用隔离变量、预重置值、仅含核心操作；atomic.LoadInt64 读快于 RWMutex.RLock 但无读-判-写原子性；高争用下 false sharing 会导致 atomic 反而更慢，需填充缓存行。
atomic.AddInt64 和 mutex.Lock/Unlock 基准测试怎么写才不歪
直接在同一个 benchmark 函数里混用 atomic.addint64 和 mu.lock() 测同一变量，结果必然失真——因为状态残留、缓存污染、初始化未重置都会干扰。必须拆成两个独立函数，各自管理自己的变量。
关键操作点：
- 每个函数用独立的全局变量或结构体字段：比如
var atomicCounter int64和var muCounter int64，绝不能共用x - 每次迭代前重置值：
atomic.StoreInt64(&atomicCounter, 0)和muCounter = 0（注意：后者需在b.ResetTimer()前完成） - 循环体内只放核心同步操作：
atomic.AddInt64(&atomicCounter, 1)或mu.Lock(); muCounter++; mu.Unlock() - 禁用任何非内联副作用：不要
fmt.Println、不分配新 slice、不调用带锁逻辑的辅助函数
为什么 atomic.LoadInt64 读比 RWMutex.RLock + Load 快，但不能随便换
atomic.LoadInt64 是单条 CPU 指令（如 mov 或 ldxr），延迟通常在 1–3 ns；而 RWMutex.RLock() 即使无争用也要走 CAS、队列检查、可能触发调度器介入，实测常在 8–20 ns 范围。
但前提是：读操作本身是“孤立”的。一旦你读完之后要基于这个值做判断再写（比如 “如果值为 0 才设为 1”），atomic.LoadInt64 就不够用了——它不提供读-判-写的原子性，必须升级到 atomic.CompareAndSwapInt64 或直接上锁。
典型误用场景：
- 用
atomic.LoadInt64(&x) == 0判断后执行x = 1→ 竞态暴露 - 读多个字段（如
atomic.LoadInt64(&a)和atomic.LoadInt64(&b)）期望它们“配对”，但中间可能有其他 goroutine 只改了其中一个 → 一致性断裂
高争用下 atomic.AddInt64 反而比 mutex 慢？先查 false sharing
不是原子操作变慢了，而是多个 goroutine 频繁更新内存中相邻的 int64 字段（比如结构体里紧挨着的两个计数器），导致它们落在同一 CPU 缓存行（64 字节）。每次写都会让其他 core 的副本失效，引发大量缓存同步开销。
验证方式：go tool trace 看 runtime.usleep 占比低但 sync.runtime_SemacquireMutex 也低，却出现大量自旋等待，大概率是 false sharing。
修复手段：
- 给原子变量前后加填充：
type PaddedCounter struct { _ [12]byte; v int64; _ [12]byte } - 避免把高频更新的原子变量塞进大结构体头部或尾部，优先单独声明为包级变量
- 争用超过 15% 写操作比例、goroutine 数远超 CPU 核数时，
sync.Mutex的休眠机制反而更稳，别硬扛
Atomic.Value 存 map 后直接改内部字段会 panic
Atomic.Value 只保证 Store 和 Load 整个值指针的原子性，不保护内部字段。你 Store 一个 map[string]int，然后在多个 goroutine 中并发执行 m["k"] = 1，Go 运行时会直接 panic：「concurrent map writes」。
正确做法只有两种：
- 存不可变对象：比如
struct{ a, b int }或*Config（且后续只读不改字段） - 存可变容器时，必须外包一层锁：
sync.RWMutex包住 map，或者改用sync.Map（注意它 API 不同，不是Atomic.Value替代品）
真正难的从来不是写对语法，而是判断哪些字段需要强一致性、哪些操作链必须保序——这没法靠 go vet 或 benchmark 报出来，得从数据流和业务语义里抠。
