Go的内存屏障是编译器和运行时自动插入的，非手动调用；sync.RWMutex.Unlock、atomic.LoadInt32等API内部隐含屏障语义，确保操作顺序与可见性，且区分内存屏障（同步多核读写）与GC写屏障（并发标记专用）。
Go 的内存屏障不是你手动加的指令
Go 语言里没有 memory_barrier() 或 __asm__ volatile("mfence") 这类显式调用。它的内存屏障是编译器和运行时在关键位置自动插入的，比如 sync.RWMutex.Lock、sync.RWMutex.Unlock、atomic.LoadInt32、atomic.StoreInt32 等函数内部。你调用这些 API，就等于间接触发了屏障语义。
常见错误现象：写了个无锁结构，靠 atomic 更新状态，但没用 atomic 读取——结果旧值被缓存，协程看到“过期”的状态；或者用了 unsafe.Pointer + 普通赋值模拟指针更新，却漏掉写屏障，GC 可能误回收对象。
- 所有
sync/atomic包的读写操作都带内存序保证（默认SeqCst），不是“原子”就完事，还管重排和可见性 -
sync.RWMutex的写锁释放（Unlock）会插入全屏障（full barrier），确保临界区内的写对其他 goroutine 立即可见 - 读锁的
RUnlock不需要强屏障，但RLock在检测到写者等待时会触发一次轻量同步，防止读者“插队”
写屏障（Write Barrier）只在 GC 期间生效，和 sync.Mutex 无关
别混淆两个“屏障”：sync 包里的内存屏障（Memory Barrier）是 CPU/编译器层，用于同步多核间读写顺序；而 GC 的写屏障（Write Barrier）是运行时层，专为三色标记服务，仅在 GC 标记阶段启用。
典型误用场景：以为给一个指针字段加了 atomic.StorePointer 就能替代写屏障——不行。GC 写屏障是 runtime 注入的额外 hook，它拦截的是堆上指针的赋值动作（如 p.field = q），不是你调用 atomic 的时候才触发。
立即学习“go语言免费学习笔记（深入）”；
- 写屏障开启条件：GC 处于并发标记阶段（
gcBlackenEnabled == 1），且目标变量在堆上 - 栈上指针赋值不走写屏障（因为栈生命周期明确，GC 不依赖它判断可达性）
- 手动调用
runtime.GC()不会立刻激活写屏障，要等进入标记阶段才生效
逃逸分析失败时，内存屏障效果可能被绕过
如果变量本该分配在栈上，但因逃逸分析失败被抬升到堆，它就落入 GC 管理范围——此时不仅涉及写屏障，还牵连到读写可见性是否仍受预期屏障保护。
例如：一个局部 struct 字段被取地址并传给 goroutine，编译器判定其逃逸；后续对该字段的 atomic 操作看似安全，但如果该 struct 整体被 GC 移动（如发生栈缩容或内存整理），而你的代码又依赖其地址不变，就会出问题。
- 用
go build -gcflags="-m"检查变量逃逸，避免意外堆分配破坏同步假设 - 不要对逃逸后的对象字段做“非原子+非同步”的跨 goroutine 访问，哪怕它看起来只是个
int - struct 中混用原子字段和普通字段时，注意普通字段的读写不自动获得原子操作的屏障辐射
ARM 或 RISC-V 上的屏障强度比 x86 更敏感
x86 架构天然提供较强内存序（load-load、load-store、store-store 都有序），所以很多 Go 程序在 x86 上跑没问题，一换到 ARM64 就出现竞态——不是 bug 少了，而是原本被硬件兜底的行为暴露了。
Go 的 atomic 和 sync 实现在不同平台生成不同指令：x86 用 LOCK 前缀，ARM64 用 ldar/stlr，RISC-V 用 lr.w/sc.w。这些指令隐含的屏障级别不同，但 Go 运行时已统一抽象为 SeqCst 语义。
- 别依赖“x86 跑得通”就认为逻辑正确；CI 中至少跑一次
GOARCH=arm64 - 自定义同步原语（比如手写 spinlock）必须显式使用
atomic操作，不能只靠volatile或空循环 - Go 1.20+ 对 RISC-V 的屏障支持已稳定，但老版本（如 1.16）在某些指令序列下可能漏屏障
RWMutex 保护一个 map，但忘了对 map 的每个元素访问都加锁——屏障再强，也拦不住数据竞争。 
