Go 并发(三)：内存模型、happens-before 与同步语义

Table of contents

TL;DR

Go 内存模型定义了 happens-before 偏序关系，它是 sequenced-before（单 goroutine 内语句顺序）和 synchronized-before（跨 goroutine 同步操作）的传递闭包。只有通过 happens-before 关联的写操作才保证对读操作可见。2022 年（Go 1.19）修订正式赋予 sync/atomic 顺序一致性语义，与 C++ seq_cst、Java volatile 对齐。任何存在 data race 的 Go 程序行为未定义——不存在”良性竞争”。

实践速查表（happens-before 表格、race detector 用法）见 go-sync-包与并发原语.md 第 9 节。本文聚焦理论基础和形式化定义。

1. 为什么需要内存模型

1.1 问题的本质

现代计算机系统存在三个层面的重排序，它们共同导致”写操作的可见性”变得不确定：

源代码语句顺序
       │
       ▼
┌──────────────┐
│  编译器重排序  │  ← 编译器为优化性能可以重排无依赖的指令
└──────┬───────┘
       ▼
┌──────────────┐
│  CPU 乱序执行  │  ← 处理器流水线并行执行无数据依赖的指令
└──────┬───────┘
       ▼
┌──────────────┐
│  Store Buffer │  ← 写操作先进入本地缓冲区，延迟写入共享内存
└──────┬───────┘
       ▼
  其他 CPU 看到的顺序  ← 可能与源代码顺序完全不同

单线程程序不受影响：编译器和 CPU 保证重排序在单线程视角下不可观察（as-if-serial 语义）。但在多线程/多 goroutine 环境下，一个 goroutine 的写操作何时、以何种顺序被另一个 goroutine 看到，取决于硬件和编译器的具体行为——如果没有规则约束，就没有正确的并发程序可写。

1.2 内存模型提供什么

内存模型是一份契约：

• 对程序员说：你使用这些同步操作，我保证写操作按你期望的顺序对其他 goroutine 可见
• 对编译器/硬件说：只要不违反这些可见性保证，你可以自由优化

1.3 顺序一致性（Sequential Consistency）

Leslie Lamport 1979 年定义的最简模型：

“The result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program.”

即：所有处理器的操作像是在一个全局时间线上交替执行，每个处理器自身的操作保持程序顺序。

为什么真实硬件不提供它：因为太昂贵。每次写操作都必须等待全局可见后才能继续执行下一条指令，相当于禁用了 store buffer、指令流水线并行——性能损失可达数量级。

1.4 没有内存模型的后果

2. Go 内存模型的形式化定义

来源：go.dev/ref/mem，Version of June 6, 2022

2.1 三个核心偏序关系

Sequenced before（单 goroutine 内）

同一个 goroutine 内，语句按照 Go 语言规范定义的求值顺序执行。这是最直觉的部分：

// 在同一个 goroutine 中：
a = 1         // (1)
b = 2         // (2)
// (1) sequenced-before (2)

Synchronized before（跨 goroutine）

由同步操作创建的跨 goroutine 偏序关系。当一个同步写操作 w 被一个同步读操作 r 观察到时，w synchronized-before r。

Happens before（传递闭包）

Happens-before = sequenced-before ∪ synchronized-before 的传递闭包。

Goroutine 1              Goroutine 2
    │                        │
    ▼                        │
  a = 1       ───┐           │
    │             │ sequenced │
    ▼             │  before   │
  ch <- 0    ─────┼──────── ─┤    synchronized
    │             │           │       before
    │             │           ▼
    │             │       <-ch        ← ch send → ch recv
    │             │           │
    │             │           │ sequenced
    │             │           │  before
    │             │           ▼
    │             └──────── print(a)  ← 保证看到 a = 1

2.2 可见性规则

对变量 v 的读操作 r 可以观察到写操作 w，当且仅当：

1. w happens-before r
2. 不存在另一个写操作 w’，使得 w happens-before w’ 且 w’ happens-before r

即：r 能看到的是 happens-before 链上”最近的”那次写。

对于无 data race 的程序，读操作的结果是确定的——只有一个 w 满足上述条件。

2.3 DRF-SC 保证

Go 采用 DRF-SC (Data-Race-Free Sequential Consistency) 模型（源自 Adve & Hill, 1990）：

如果程序不存在 data race，其执行结果等价于某种顺序一致的 goroutine 交织。

这是一个精妙的契约：程序员负责消除 data race，编译器和硬件保证顺序一致性的表象。

2.4 内存操作的分类

Go 内存模型将内存操作分为两类：

Synchronizing 操作（atomic、Mutex、channel）同时建立 synchronized-before 关系；普通读写不建立。

3. 完整的同步操作与 happens-before 保证

以下是 Go 内存模型中所有建立 happens-before 关系的同步操作。

3.1 汇总表

3.2 细节解析

Package init

// 包 a
func init() { /* ... */ }  // 先完成

// 包 b（import "a"）
func init() { /* ... */ }  // 后执行

所有 init 函数在单个 goroutine 中按依赖拓扑序执行，全部完成后才启动 main.main()。

Goroutine 创建 vs 退出

// 创建：go 语句 happens-before f() 开始
a = "hello"
go f()  // f() 保证能看到 a = "hello"

// 退出：没有任何 happens-before 保证！
go func() {
    a = "hello"
}()
// 这里读 a 是 data race，即使 goroutine 已经"退出"
// 必须用 channel/WaitGroup/mutex 等同步 goroutine 退出

Channel：buffered vs unbuffered 的微妙区别

Unbuffered channel 有一条额外规则：第 k 次接收完成 happens-before 第 k 次发送完成。

这意味着对于 unbuffered channel，接收方”先完成”，发送方”后完成”。这看起来反直觉，但它是 unbuffered channel 能作为同步点的本质原因：

unbuffered channel:
  发送方                 接收方
     │                    │
  ch <- v  ─────────── <-ch
     │   rendezvous 同步点   │
     │                    │
  (发送完成) ← 发生在 → (接收完成)之后

接收完成 happens-before 发送完成
发送操作 happens-before 接收完成

对于 capacity=C 的 buffered channel，第 k 次接收完成 happens-before 第 (k+C) 次发送完成。当 C=0（unbuffered）时，第 k 次接收完成 happens-before 第 k 次发送完成，与上述规则一致。

Atomic 操作（Go 1.19+ 正式保证）

// 如果 atomic 操作 A 的效果被 atomic 操作 B 观察到，则 A happens-before B
var x atomic.Int64
var data string

// Goroutine 1
data = "hello"        // (1)
x.Store(1)            // (2)  — (1) sequenced-before (2)

// Goroutine 2
if x.Load() == 1 {    // (3)  — 如果观察到 Store，则 (2) synchronized-before (3)
    print(data)        // (4)  — (3) sequenced-before (4)
}                      //       传递性：(1) happens-before (4)，print "hello" 是安全的

4. 硬件内存模型与 Go 的抽象

4.1 x86/x64: Total Store Order (TSO)

x86-TSO 模型：
                    ┌─────────────┐
  CPU 0 ──write──→ │ Store Buffer │ ──drain──→ ┌──────────────┐
                    └─────────────┘            │              │
  CPU 0 ←──read──  直接看到自己的 Store Buffer   │  Shared       │
                    （store-buffer forwarding） │  Memory       │
                                               │              │
  CPU 1 ──write──→ ┌─────────────┐ ──drain──→ │              │
                    │ Store Buffer │            └──────────────┘
                    └─────────────┘
  CPU 1 ←──read──  看不到 CPU 0 的 Store Buffer

x86 只允许一种重排序：Store-Load 重排序。 即一个 CPU 的写操作可能还在 store buffer 中时，该 CPU 就执行了后续的读操作（读到另一个地址的旧值）。

后果：x86 上很多有 data race 的程序”碰巧能跑对”，因为 TSO 本身就提供了很强的顺序保证。

4.2 ARM/ARM64: Weak Ordering

ARM 采用弱内存模型，几乎所有重排序都可能发生：

唯一的不变量：对同一内存地址的写操作顺序（coherence），所有 CPU 必须达成一致。

4.3 内存屏障指令

Go runtime 在不同架构上插入的屏障指令：

Go 如何使用这些指令：

• sync/atomic 的 Load/Store/CAS 等操作编译为带适当屏障的机器指令
• channel 操作、mutex 操作通过 runtime 调用间接使用
• Go runtime 内部还定义了 publicationBarrier（ARM64 上编译为 DMB ISHST），用于保证新分配的对象对其他 goroutine 可见

来源：runtime/internal/atomic/asm_arm64.s、Go issue #43031

4.4 为什么 Go 程序员不需要关心硬件

Go 的内存模型是一个与硬件无关的抽象层。编译器和 runtime 负责在目标架构上插入正确的屏障指令，程序员只需要：

1. 使用正确的同步原语（channel、mutex、atomic）
2. 确保程序没有 data race

但理解硬件能解释一个关键现象：为什么 race bug 在 x86 上不复现，却在 ARM 上崩溃。x86 的 TSO 模型”免费”提供了很多顺序保证，掩盖了同步不足的 bug。当同样的代码运行在 ARM（如 Apple Silicon Mac、ARM 服务器、手机）上时，弱内存模型会暴露这些 bug。

5. 编译器重排序

5.1 Go 编译器可以做什么

在没有同步操作的情况下，Go 编译器可以：

• 重排无依赖的读写操作
• 合并连续的写操作
• 消除”冗余”的读操作（将内存读取缓存到寄存器中，不再重新读取）
• 重排函数内的操作（只要单 goroutine 语义不变）

5.2 Go 编译器不允许做什么（Go 1.19+ 明确规定）

来源：go.dev/ref/mem “Compiler Correctness” 一节

规则 1：不得将写操作移出条件分支

// 源代码
*p = 1
if cond {
    *p = 2
}

// 编译器不得重写为：
*p = 2       // ← 非法！如果 cond 为 false，其他 goroutine 会看到不应出现的 *p = 2
if !cond {
    *p = 1
}

规则 2：不得假设循环一定终止

n := 0
for e := list; e != nil; e = e.next {
    n++
}
i := *p     // 编译器不得将此读取移到循环之前
*q = 1      // 编译器不得将此写入移到循环之前

规则 3：不得假设函数一定返回或不含同步操作

f()         // 可能永不返回，或包含同步操作
i := *p     // 不得移到 f() 之前

规则 4：单次读取不得观察到多个值

i := *p
if i < 0 || i >= len(funcs) {
    panic("invalid")
}
// ... 大量代码 ...
funcs[i]()  // 编译器不得在此处重新从 *p 读取（可能已经被另一个 goroutine 改了）
            // 必须使用之前保存的 i 值

规则 5：单次写入不得写出多个值

*p = i + *p/2

// 编译器不得分解为：
*p /= 2     // ← 中间状态对其他 goroutine 可见
*p += i

5.3 同步操作作为”编译器屏障”

每个同步操作（channel 操作、mutex 操作、atomic 操作）同时充当编译器屏障——编译器不会将普通读写跨同步操作重排序。这是 happens-before 语义在编译器层面的实现基础。

5.4 一个”碰巧能工作”的危险例子

var data int
var ready bool  // 普通 bool，不是 atomic.Bool

// Goroutine 1
func setup() {
    data = 42     // (A)
    ready = true  // (B)
}

// Goroutine 2
func use() {
    for !ready {}  // (C) 忙等
    fmt.Println(data) // (D)
}

这段代码有三重问题：

1. 编译器可以重排 (A) 和 (B)：因为 data 和 ready 之间没有数据依赖
2. 编译器可以缓存 ready 到寄存器：(C) 的循环可能永远不终止（编译器把 ready 缓存到寄存器，永远不重新读取内存）
3. 即使在 x86 上碰巧工作：换到 ARM 或换一个优化级别就可能崩溃

正确做法：使用 atomic.Bool 或 channel 来同步。

6. Data Race：定义与后果

6.1 形式化定义

Data race 发生在：

• 两个内存操作访问同一内存位置
• 至少一个是写操作
• 至少一个是非同步操作（non-synchronizing）
• 两者之间没有 happens-before 关系（即既不是 A → B 也不是 B → A）

Data Race:
  Goroutine 1      Goroutine 2
      │                 │
    write x           read x        ← 两个操作访问同一个 x
      │                 │              至少一个是写
      │   (无 HB 关系)   │              两者之间没有 happens-before 关系
      │                 │
      ╰────── DATA RACE ──────╯

6.2 Go 的立场：Data Race = 未定义行为（但有限度）

Go 的 data race 语义介于 C/C++ 和 Java 之间：

Go 对 racy 程序的保证和限制：

保证（实现必须做到）：

• 单机器字（word）或更小的内存位置的读操作，必须观察到某次实际写入的值，而非凭空捏造
• 不允许因果循环（out-of-thin-air values）

不保证（可能出现）：

• 多字结构（interface、string、slice、map）的 racy 访问可能看到不一致的内部状态
• 例如：一个 interface value 的 (type, pointer) 对可能来自不同的写操作，导致任意内存腐败

// 危险：interface 是两个字（type + pointer），racy 访问可能看到混合值
var v interface{}

// Goroutine 1
v = "hello"       // type=string, ptr=&"hello"

// Goroutine 2
v = 42            // type=int, ptr=&42

// Goroutine 3
fmt.Println(v)    // 可能看到 type=string + ptr=&42 → 内存腐败！

6.3 “良性竞争”在 Go 中不存在

常见误区：“我只是读一个 bool，最多读到旧值，不会有问题。”

这是错误的。 在 Go（和 C/C++）中，data race 就是 undefined behavior。编译器可以基于”程序没有 data race”这个假设进行优化。具体来说：

1. 编译器可能将 bool 读取缓存到寄存器，导致循环永不终止
2. 编译器可能消除”冗余”的读取，即使另一个 goroutine 已经修改了值
3. 编译器可能重排序周围的操作，破坏你以为存在的顺序

Java 能容忍”良性竞争”是因为 JMM 对 racy 读有明确语义（至少看到某次写入的值，且保持类型安全）。Go 选择不提供这个保证——为了给编译器更大的优化空间。

6.4 Race Detector

Go 的 race detector 基于 ThreadSanitizer v2 (TSan)，通过编译时插桩实现。

工作原理：

• 每个 goroutine 维护一个 vector clock（向量时钟）
• 每个内存位置记录最近一次读/写的 goroutine 及其时钟
• 每次内存访问检查是否与记录的访问形成 data race
• 同步操作（channel、mutex、atomic）会更新 vector clock，建立 happens-before 关系

开销：

• CPU：约 5-10x 减速
• 内存：约 5-10x 增长
• 只能检测运行时实际执行路径上的 race（静态分析无法替代）

必须在 CI 中启用：

go test -race ./...

race detector 只能检测实际执行到的 race。一个测试覆盖率低的项目即使 -race 通过也不代表无 race。race detector 是必要条件，不是充分条件。

来源：ThreadSanitizer 论文（Serebryany & Iskhodzhanov, 2009）；Go 自 1.1 版本引入 race detector

7. 2022 年修订深度解析（Go 1.19）

7.1 修订背景

Russ Cox 在 2021 年 6-7 月发表了三篇系列博文，系统分析了硬件和编程语言内存模型的现状，为 Go 内存模型的修订奠定了理论基础：

1. Hardware Memory Models — 分析 x86-TSO、ARM/POWER 弱内存模型
2. Programming Language Memory Models — 对比 Java JMM、C++ 内存模型、JavaScript 规范
3. Updating the Go Memory Model — 提出 Go 内存模型的修改方案

7.2 修订前的问题

2009 年版 Go 内存模型存在以下缺陷：

7.3 四项核心变更

变更 1：定位说明（Overview）

明确 Go 介于 C/C++（完全 UB）和 Java（完全定义）之间：

“Programs with data races are invalid in the sense that an implementation may report the race and terminate the program. But otherwise, programs with data races have defined semantics with a limited number of outcomes, making errant programs more reliable and easier to debug.”

变更 2：Atomic 操作正式获得顺序一致性语义

修订前: sync/atomic 没有正式的 memory ordering 保证
修订后: 所有 atomic 操作行为如同按某个全局顺序一致顺序执行
        如果 atomic 操作 A 的效果被 atomic 操作 B 观察到，则 A synchronized-before B

这等价于 C++ 的 memory_order_seq_cst 和 Java 的 volatile。

变更 3：编译器限制正式成文

五条编译器必须遵守的规则（见第 5.2 节），防止共享 LLVM/GCC 后端的编译器将 C/C++ 的优化规则错误应用于 Go。

变更 4：多字结构竞争风险警告

明确指出 interface、string、slice、map 等多字结构的 racy 访问可能导致内存腐败。

7.4 为什么 Go 只提供顺序一致性 atomic

C++ 提供三个级别的 atomic 语义：

Russ Cox 的决策理由：

1. ARMv8 的 LDAR/STLR 指令原生提供 seq_cst 语义，它们也是 ARM 推荐的 acquire/release 实现方式——所以在 ARMv8 上，seq_cst 和 acq/rel 的性能几乎没有差异
2. Go 标准库本身就依赖 seq_cst：sync.WaitGroup 用一对 atomic uint32 值通信，runtime 的信号量实现用独立的 atomic 字来交互——这些模式在 acquire/release 语义下会静默失败
3. 暴露 acq/rel 会创造出 race detector 无法检测的 bug 类别：一段在 x86 上工作正确的 acq/rel 代码可能在 ARM 上失败，而 race detector 不会报告（因为 atomic 操作本身不是 race）

7.5 对现有代码的影响

零影响。修订只是将已有的惯例和实现行为提升为规范保证。所有在修订前正确使用 atomic 的代码在修订后仍然正确——区别仅在于现在有了规范保障。

8. 常见模式与内存模型分析

8.1 Double-Checked Locking（正确实现）

错误版本（Go 内存模型明确列为反模式）：

var config *Config
var done bool

func getConfig() *Config {
    if !done {           // 普通 bool 读：没有 happens-before 保证
        mu.Lock()
        if !done {
            config = loadConfig()
            done = true
        }
        mu.Unlock()
    }
    return config        // 可能看到 done=true 但 config 尚未初始化
}

正确版本 1（推荐）：sync.Once

var (
    config *Config
    once   sync.Once
)

func getConfig() *Config {
    once.Do(func() {
        config = loadConfig()
    })
    return config  // once.Do 的 happens-before 保证 config 已初始化
}

正确版本 2：atomic + mutex

var (
    config atomic.Pointer[Config]
    mu     sync.Mutex
)

func getConfig() *Config {
    if c := config.Load(); c != nil {
        return c  // fast path: atomic Load 保证看到完整初始化的对象
    }
    mu.Lock()
    defer mu.Unlock()
    if c := config.Load(); c != nil {
        return c  // double-check under lock
    }
    c := loadConfig()
    config.Store(c)  // atomic Store happens-before 后续 atomic Load
    return c
}

8.2 Publication Pattern（安全发布）

将完全构造好的对象原子地发布给其他 goroutine：

type Server struct {
    addr    string
    handler http.Handler
    // ... 很多字段
}

var current atomic.Pointer[Server]

// 写方（低频）
func updateServer(addr string, h http.Handler) {
    s := &Server{
        addr:    addr,
        handler: h,
    }
    // Store 之前的所有字段赋值 sequenced-before Store
    // Store happens-before 后续的 Load
    // 因此 Load 保证看到完全初始化的 Server
    current.Store(s)
}

// 读方（高频）
func handleRequest(w http.ResponseWriter, r *http.Request) {
    s := current.Load()  // 保证看到完全初始化的 *Server 或 nil
    if s != nil {
        s.handler.ServeHTTP(w, r)
    }
}

8.3 Flag Signaling

// 方案 1：atomic.Bool（适用于"done"标志）
var done atomic.Bool

// producer
func produce() {
    doWork()
    done.Store(true)  // happens-before 后续 Load
}

// consumer
func consume() {
    for !done.Load() {
        runtime.Gosched()  // 让出 CPU，避免忙等
    }
    // 保证看到 doWork() 的所有副作用
}

// 方案 2：channel（更 Go-idiomatic）
func produce(done chan<- struct{}) {
    doWork()
    close(done)  // happens-before 接收零值
}

func consume(done <-chan struct{}) {
    <-done
    // 保证看到 doWork() 的所有副作用
}

channel 方案更惯用，也更安全（不需要忙等）。atomic.Bool 方案在极端低延迟场景有优势。

8.4 Copy-on-Write with atomic.Value

type RouteTable struct {
    routes map[string]Handler
}

var table atomic.Value  // 存储 *RouteTable

func init() {
    table.Store(&RouteTable{routes: make(map[string]Handler)})
}

// 读方（高频，无锁）
func lookup(path string) Handler {
    t := table.Load().(*RouteTable)
    return t.routes[path]  // 安全：map 本身不会被修改
}

// 写方（低频，需要锁防止并发写）
var writeMu sync.Mutex

func addRoute(path string, h Handler) {
    writeMu.Lock()
    defer writeMu.Unlock()

    old := table.Load().(*RouteTable)
    // 复制整个 map（copy-on-write）
    newRoutes := make(map[string]Handler, len(old.routes)+1)
    for k, v := range old.routes {
        newRoutes[k] = v
    }
    newRoutes[path] = h
    table.Store(&RouteTable{routes: newRoutes})  // 原子替换
}

注意：atomic.Value 要求所有 Store 的值必须是同一具体类型，否则 panic。

9. 跨语言内存模型对比

关键洞察：

• Go 和 Java/JS 在安全性上取了相似的立场（有限定义 racy 语义），但 Go 在多字结构上不如 Java 安全
• Rust 独树一帜：通过 Send/Sync trait 在编译期消除大部分 race，是唯一不依赖运行时检测的语言
• C++ 的 relaxed atomic 是已知的设计失误——C++14 不得不删除形式化规则，至今无人能给出 relaxed atomic 的完整语义（“out-of-thin-air” 问题未解决）

10. Pitfalls

Pitfall 1: 假设 goroutine 退出会同步

var result string

go func() {
    result = "done"
}()

time.Sleep(time.Second)  // "等它跑完"
fmt.Println(result)      // DATA RACE！goroutine 退出不创建 happens-before

Why：Go 内存模型明确规定 “The exit of a goroutine is not guaranteed to be synchronized before any event in the program.” time.Sleep 不是同步操作。

How to avoid：用 channel、WaitGroup 或 mutex 同步 goroutine 退出。

Pitfall 2: “我的机器上没问题”（x86 掩盖 ARM 上的 race）

var data int
var flag int32

// Goroutine 1
data = 42
atomic.StoreInt32(&flag, 1)

// Goroutine 2
if atomic.LoadInt32(&flag) == 1 {
    fmt.Println(data)  // x86 上总是 42，ARM 上可能是 0
}

上面的代码实际上在 Go 1.19+ 的内存模型下是正确的（atomic Store/Load 创建 happens-before），但如果将 atomic 操作替换为普通的变量读写：

var data int
var flag bool  // 普通 bool，不是 atomic！

// Goroutine 1
data = 42
flag = true    // 普通写，没有 happens-before 保证

// Goroutine 2
if flag {      // 普通读——这是 data race
    fmt.Println(data)  // x86 上碰巧能工作，ARM 上可能崩溃
}

Why：x86 的 TSO 模型禁止 Store-Store 重排，所以 data = 42 总是在 flag = true 之前对其他 CPU 可见。ARM 的弱内存模型不提供这个保证。

How to avoid：跨 goroutine 共享数据必须使用同步原语。不要依赖”在 x86 上碰巧能跑”。

Pitfall 3: 对多字值使用 atomic 思维

var config struct {
    Host string  // string 是两个字：(pointer, length)
    Port int
}

// Goroutine 1
config.Host = "localhost"
config.Port = 8080

// Goroutine 2
fmt.Printf("%s:%d", config.Host, config.Port)
// 可能看到 Host 的 pointer 来自新值，length 来自旧值 → 读到垃圾数据

Why：atomic 操作只对单机器字有效。string、slice、interface、map 等多字结构的 racy 访问可能看到不一致的内部状态，导致内存腐败。

How to avoid：使用 atomic.Pointer[Config] 原子替换整个结构体指针，或用 mutex 保护。

Pitfall 4: 误解 channel 方向与 happens-before 的关系

ch := make(chan int, 1)  // buffered!

// 错误推理："发送 happens-before 接收"，所以：
go func() {
    data = 42
    ch <- 1      // 发送
}()
<-ch             // 接收
print(data)      // 这里是安全的吗？

这个例子其实是安全的——因为对于所有 channel，ch <- v happens-before 对应的 <-ch 完成。

但反过来不对——对于 buffered channel，接收完成不一定 happens-before 发送完成（只有 unbuffered channel 有这条规则）。

ch := make(chan int, 1)  // buffered

go func() {
    <-ch         // 接收
    print(data)  // 安全吗？
}()
data = 42
ch <- 1          // 发送 → 保证 happens-before 对方的 <-ch 完成，所以安全

How to avoid：记住核心规则是”发送 happens-before 接收完成”——这对所有 channel 都成立。额外的”接收完成 happens-before 发送完成”只对 unbuffered channel 成立。

Pitfall 5: init() 顺序假设超出直接 import

// package a
func init() { /* ... */ }

// package b（import "a"）
func init() { /* ... */ }  // 保证在 a.init() 之后

// package c（import "a"）
func init() { /* ... */ }  // 保证在 a.init() 之后

// 但 b.init() 和 c.init() 之间没有顺序保证！
// 它们可能以任意顺序执行（取决于编译器的 import 遍历顺序）

Why：happens-before 只在直接 import 关系上建立。同级 package 之间没有保证。

How to avoid：不要依赖 init() 的相对顺序来通信。如果需要跨包初始化顺序，用 sync.Once 或显式初始化函数。

Pitfall 6: “良性竞争”谬误

var debug bool  // 普通 bool

// 配置热更新 goroutine
go func() {
    for range ticker.C {
        debug = loadDebugFlag()  // 普通写
    }
}()

// 业务 goroutine
if debug {  // 普通读——DATA RACE
    log.Println("debug info")
}

“只是个 bool，最多读到旧值，不会有问题” 是错误的推理。

实际风险：

1. 编译器可能将 debug 缓存到寄存器，永远不重新读取
2. 即使每次都读内存，也不保证看到最新的写入值
3. data race 是 UB，race detector 会报告，CI 会失败

How to avoid：使用 atomic.Bool。

Pitfall 7: 不在 CI 中启用 -race

“太慢了”不是借口。

• race detector 的开销（5-10x）是在测试时，不是生产环境
• 一个未检测到的 data race 在生产环境造成的损失远超 CI 多花的几分钟
• race bug 是最难复现和调试的 bug 类别——越早发现越好

# CI 配置示例
test:
  script:
    - go test -race -count=1 ./...
    # -count=1 禁用测试缓存，确保每次都执行

How to avoid：CI 中强制 -race。如果测试太慢，优化测试本身而不是关掉 race 检测。

Pitfall 8: atomic.Value 存储不同类型导致 panic

var v atomic.Value
v.Store("hello")  // 类型确定为 string
v.Store(42)        // panic: sync/atomic: store of inconsistently typed value

Why：atomic.Value 内部通过 efaceOf 检查类型一致性，第一次 Store 锁定具体类型。

How to avoid：优先使用 atomic.Pointer[T]（Go 1.19+），它在编译期保证类型安全。如果必须用 atomic.Value，确保所有 Store 的值类型一致，通常通过自定义 struct 包装来保证。

Pitfall 9: 忙等（busy-wait）不含同步操作

var ready uint32

// Goroutine 1
doSetup()
ready = 1  // 普通写

// Goroutine 2
for ready == 0 {}  // 普通读——编译器可以将其优化为无限循环
use()

Why：ready 的读写不是 atomic 操作，编译器有权假设单 goroutine 内值不会变化，将循环优化为 for { }。即使不优化，也是 data race。

How to avoid：atomic.LoadUint32 / atomic.StoreUint32，或更好地用 channel/sync.Cond。

11. 生产 Checklist

• 所有跨 goroutine 共享的变量都通过 channel、mutex 或 atomic 保护
• CI 中 go test -race ./... 强制开启
• 不存在普通 bool/int 作为跨 goroutine 信号标志（一律用 atomic.Bool / atomic.Int64 或 channel）
• 不存在对 interface/string/slice/map 的无保护并发读写
• goroutine 退出通过显式同步（channel close、WaitGroup.Done）而非 time.Sleep 等待
• atomic.Value 的所有 Store 调用使用同一具体类型
• sync.Once 用于一次性初始化，而非手写 double-checked locking
• 复杂状态转换用 Mutex（不要试图用多个 atomic 组合出”无锁”方案，除非你能形式化证明正确性）
• 了解目标部署平台的内存模型（x86 vs ARM）——ARM 上的 race 更容易暴露
• 对性能敏感路径的 atomic 使用有 benchmark 支撑，而非”atomic 比 Mutex 快”的直觉

References

• The Go Memory Model — 官方规范（Version of June 6, 2022）
• Russ Cox: Hardware Memory Models — 硬件内存模型系列 Part 1
• Russ Cox: Programming Language Memory Models — 编程语言内存模型系列 Part 2
• Russ Cox: Updating the Go Memory Model — Go 内存模型修订系列 Part 3
• Go Issue #50590 — Go Memory Model 修订 proposal
• Go Discussion #47141 — 社区讨论
• Adve & Hill, 1990 — “Weak Ordering — A New Definition”（DRF-SC 模型原始论文）
• Lamport, 1979 — Sequential Consistency 定义
• Boehm & Adve, 2008 — “Foundations of the C++ Concurrency Memory Model”
• runtime/internal/atomic/asm_arm64.s — Go runtime ARM64 atomic 指令实现
• sync/atomic/doc.go — sync/atomic 包文档与 happens-before 规范