Go 内存模型与并发重排序

TL;DR

• 硬件与编译器为提升执行性能广泛采用指令重排序与写缓冲（Store Buffer），使得并发程序背离直观的顺序一致性（SC）。
• DRF-SC（无数据竞争即顺序一致性）是现代语言共识：只要程序不存在未同步的并发读写竞争，其执行表现就等价于全局串行交错。
• 与 C/C++ 允许数据竞争引发任意未定义行为（Undefined Behavior / Catch Fire）不同，Go 拒绝“凭空产生值”（Out-Of-Thin-Air），并将并发冲突视为错误。
• Go 内存模型基于 Happens-Before 偏序关系定义跨 Goroutine 的可见性，覆盖了 Goroutine 生命周期、Channel 缓冲通信、sync.Mutex 与 sync.Once 的同步界限。

硬件内存一致性基线

在单核处理器上，由于硬件和编译器严格维护“单线程程序逻辑不变性”（As-If 规则），程序员无需关心底层重排序细节。然而在多核并发环境下，内存读写可见性变得极其微妙。

// 假设全局变量 x = 0, done = 0
// 处理器 1 (Thread 1)        // 处理器 2 (Thread 2)
x = 1;                        while (done == 0) { /* 循环等待 */ }
done = 1;                     print(x);

在多核物理机上，Thread 2 最终打印出 x 的值是否可能为 0？ 答案是：完全可能。在 ARM 或 POWER 架构弱内存模型下，或者当编译器将循环内的读操作提升到寄存器优化时，Thread 2 可能会观察到 done == 1 但读取到的 x 依然是初始值 0。

顺序一致性与试金测试（Litmus Test）

Leslie Lamport 在 1979 年提出了**顺序一致性（Sequential Consistency, SC）**模型：程序在多核环境下的所有可能执行结果，都等价于各个线程的操作按照某种全局顺序进行串行交错（Interleaving），且每个线程内部的操作严格维持源代码顺序。

为了判断特定硬件或运行时是否满足顺序一致性，计算机科学采用试金测试（Litmus Test）：

// 初始状态: x = 0, y = 0
// 线程 1                      // 线程 2
x = 1;                        r1 = y;
y = 1;                        r2 = x;

// 初始状态: x = 0, y = 0
// 核心 1                      // 核心 2
x = 1;                        y = 1;
r1 = y;                       r2 = x;

Go 语言内存哲学与竞争边界

与 C/C++11 内存模型将数据竞争归类为完全失控的未定义行为（Undefined Behavior，允许编译器假设竞争不可能发生从而抹除保护代码）不同，Go 坚持更保守实用的工程哲学：

1. 将竞争定性为程序缺陷：Go 官方坚决推行“竞争即 Bug”理念，并提供高度集成的内存竞态检测器（go test -race），在开发测试期拦截潜在竞争。
2. 拒绝凭空捏造（No Out-Of-Thin-Air）：即便存在数据竞争，Go 运行时对于机器字长（Word-sized）以内的内存读取，也坚决保证读取到的必须是某一个 Goroutine 真实写入过的有效值，严禁凭空伪造不受控的内存垃圾数据。

Happens-Before 偏序关系全集

Go 语言内存模型通过数学上的严格偏序关系定义事件的相对发生顺序：如果事件 $e_1$ 发生在事件 $e_2$ 之前，记作 $e_1 \prec e_2$（$e_1$ happens before $e_2$）。此时，$e_1$ 对内存的写入对 $e_2$ 绝对可见。

单 Goroutine 内部顺序

在单个 Goroutine 内部，读写操作严格遵循源代码顺序所体现的依赖结果： $W \prec R$ 编译器允许在单线程逻辑不变的前提下任意乱序重排，但多核并发视角下不可依赖此无锁假设。

Goroutine 生命周期事件

1. Goroutine 创建：执行 go 关键字创建新 Goroutine 的语句，Happens-Before 该新 Goroutine 内部所有代码的物理开始执行：

   var a string
   func f() {
       print(a) // 保证打印 "hello"
   }
   func main() {
       a = "hello"
       go f()
   }

2. Goroutine 退出：Goroutine 内部所有执行的完成，并不保证 Happens-Before 外部观察者的任何事件。必须通过通道或锁显式等待。

Channel 通信同步法则

Channel 是 Go 中最基础的 Happens-Before 关系构建者：

1. 无缓冲 Channel 同步交汇（Rendezvous）： 从无缓冲通道完成一次接收，Happens-Before 对应的发送操作返回；同时，发送操作准备就绪，Happens-Before 接收操作完成。两者构成硬性时间同步屏障。
2. 带缓冲 Channel 容量屏障： 向容量为 $C$ 的通道执行的第 $k$ 次发送，Happens-Before 从该通道完成的第 $k$ 次接收。反之，第 $k$ 次接收完成，Happens-Before 第 $k + C$ 次发送操作完成。
3. 通道关闭（Close）： 执行 close(ch) 操作，Happens-Before 任何接收者从该 Channel 读取到表示通道已关闭的零值返回值。

互斥锁与 sync 包机制

• sync.Mutex / sync.RWMutex：对同一把互斥锁的第 $n$ 次 Unlock() 调用，Happens-Before 任何后续发起的第 $n+1$ 次 Lock() 成功返回。
• sync.Once：once.Do(f) 中传入的函数 f() 执行完成，Happens-Before 任何后续并发或串行调用的 once.Do(f) 返回。调用返回时，f 的所有副作用对外部完全可见。