Go语言内存模型面试要点_Golang happens-before规则详解-Golang-PHP中文网

go并发读写共享变量安全与否取决于能否建立happens-before关系，而非有无锁；无同步原语显式建立该关系即为未定义行为，-race会报data race。

go语言内存模型面试要点_golang happens-before规则详解

Go 并发读写共享变量是否安全，不取决于“有没有锁”，而取决于能否建立 happens-before 关系。 没有同步原语显式建立该关系，哪怕只读一次、只写一次，也是未定义行为（UB），go run -race 会报 Data Race —— 这不是概率问题，是规范层面的禁止。

它不保证 A 比 B “早几纳秒执行”，只保证：如果 A happens-before B，那么 A 对变量的所有写入，对 B 的读取一定可见。编译器重排、CPU 缓存、写缓冲区都可能让“写”延迟到达其他 goroutine，happens-before 是唯一能穿透这些层的逻辑约束。

只有语言规范明确定义的同步事件才起作用。以下每一条都是硬规则，错配或漏用就会打破可见性：

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

ch happens-before 从同一 channel <code> 成功接收完成（注意：必须是“对应”的收发，且接收确实等到了这次发送）
mu.Unlock() happens-before 同一把 sync.Mutex 的下一次 mu.Lock() 返回
wg.Done() happens-before 同一 sync.WaitGroup 实例上 wg.Wait() 返回
once.Do(f) 中的 f() 执行 happens-before 所有后续 once.Do(f) 调用返回
atomic.StoreUint64(&x, 42) happens-before 后续 atomic.LoadUint64(&x)（但 atomic.LoadUint64(&x) 和普通 println(x) 之间仍无保证）

这些写法看似合理，实则全部违反内存模型，-race 必报，上线后行为不可预测：

用 var done bool + for !done {} 等待另一个 goroutine 设置 done = true —— 无同步，读写无 happens-before
在 mutex 临界区外读取本应在锁内保护的变量（如 mu.Lock(); data = 42; mu.Unlock(); println(data)）
混用 atomic 和普通读写：atomic.StoreUint64(&x, 42) 后直接 println(int(x)) —— 类型转换绕过了原子语义
误以为带缓冲 channel 的发送立即建立接收可见性：ch := make(chan int, 1); ch —— 接收 goroutine 可能尚未启动，<code>ch 和 <code> 之间无 happens-before
关闭 channel 后读取零值，就认为“关闭 happened before 所有读取” —— 关闭只对后续的接收操作可见，不排序之前已发出的发送