Go编译器不自动插入硬件内存屏障，但会在sync.Mutex、sync/atomic等同步原语处生成acquire/release语义指令；仅靠语法或runtime.Gosched()无法保证跨goroutine内存可见性，必须显式使用同步机制。
Go 编译器会自动插入内存屏障吗
不会，Go 编译器本身不为你插入硬件级内存屏障（如 MOV AL, [X] 后面加 MFENCE），但会在特定同步原语周围生成语义等价的指令序列——比如在 sync.Mutex.Lock() 入口和出口、sync/atomic 操作前后，插入带 acquire/release 语义的 CPU 指令（x86 上常是 LOCK XCHG，ARM 上是 LDAXR/STLXR 等）。
这意味着：你不能靠「写对了 Go 语法」就默认获得跨 goroutine 的内存可见性保障；必须显式使用同步机制，否则编译器和 CPU 都可能重排读写。
- 常见错误现象：
done变量被一个 goroutine 写为true，另一个 goroutine 死循环读它却永远看不到更新（即使加了volatile类语义也不行——Go 没这个关键字） - 正确做法：用
sync/atomic.StoreBool(&done, true)+sync/atomic.LoadBool(&done)，或包裹在sync.Mutex中 - 性能影响：纯原子操作比 mutex 轻量，但频繁的
atomic.Load在高争用下仍可能触发总线锁或缓存行 bouncing
为什么 runtime.Gosched() 不能替代内存屏障
runtime.Gosched() 只是让出当前 P 给其他 goroutine 运行，不产生任何内存序约束。它既不保证之前写的变量对别的 goroutine 可见，也不阻止编译器/CPU 对它前后的内存访问做重排。
典型误用场景：想靠它“等一会儿让写生效”，结果逻辑依旧随机失败。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误示例：
done = true; runtime.Gosched(); if done { ... }—— 这里done读写都未同步，行为未定义 - 真正需要的是同步原语：
sync.WaitGroup、chan、atomic或mutex - 兼容性注意：在非抢占式调度的老版本 Go（Gosched 更不可靠，但现在也别指望它管内存
sync/atomic 的 Load/Store 默认是什么内存序
Go 的 sync/atomic 所有函数（如 LoadInt64、StoreUint32）默认提供 sequentially consistent（顺序一致性）语义——这是最强的内存序，等价于带 acquire + release 的组合，且全局有序。
换句话说：所有原子操作看起来就像按某个全局时间顺序执行，不会出现“我看到 A 更新但没看到 B”这种乱序可见问题。
- 参数差异：没有额外 flag 控制内存序（不像 C++ 的
memory_order_relaxed），Go 选择简化模型，牺牲一点极致性能换确定性 - 代价：顺序一致性在某些架构上需更多 fence 指令，比如 x86 上
Store本身已具 release 语义，但 Go 仍可能补MFENCE保全局序 - 例外：
atomic.CompareAndSwap和atomic.Add等复合操作也遵循同一语义，无需额外处理
channel 发送接收是否自带内存屏障
是的，channel 的 操作天然带 acquire-release 语义：发送完成时，所有在发送语句之前的内存写入，对执行接收语句的 goroutine 是可见的；反之亦然。
这是 Go 并发模型的基石之一，也是推荐用 channel 而非裸共享变量通信的核心原因。
- 常见错误：用
chan struct{}做信号通知，但把数据写入放在close(c)之后——此时写入不被保证可见 - 正确顺序：
data = x; c 或 <code>data = x; close(c)（close 也具 release 语义） - 性能提示：无缓冲 channel 的收发有明显同步开销；有缓冲 channel 的 send/receive 在缓冲未满/空时不阻塞，但内存屏障语义不变
Go 的内存模型不暴露底层 fence 指令，而是把屏障语义绑定在少数几个明确同步点上：atomic 操作、mutex、chan、WaitGroup。漏掉其中任何一个，就等于主动放弃内存可见性保障——这点比“会不会死锁”更隐蔽，也更难 debug。
