极客教程

Appearance

共 1,980 字预计阅读约 7 分钟

Go 高手（01）：内存模型——happens-before、atomic 与 GC ​

更新时间：2026-08-25。本文是 languages/go/intermediate/ 高手层第 1 篇。回答：Go 里"内存可见性"如何保证？atomic 对应 C++ 的哪种内存序？为什么逃逸到堆会触发 GC？

一、什么是内存模型 ​

内存模型回答两个问题：

  1. 读：一个 goroutine 读变量，能否看到另一个 goroutine 的写入？
  2. 序：多核下，操作顺序在硬件上是否如代码所示？

这与本站 L4 内存重排与屏障 完全同源——Go 也要面对 CPU 缓存一致性、编译器重排、乱序执行。Go 通过定义 happens-before（先行发生）关系来约束哪些顺序是可见的。

二、happens-before 规则 ​

Go 规范用 happens-before 定义内存可见性。若 A happens-before B，则 A 的写入对 B 可见。

核心规则（sync/channel/atomic 提供的同步点）：

规则内容
程序顺序同一 goroutine 内，语句按书写顺序
channel 发送/接收向 channel 发送 happens-before 对应接收完成
channel 关闭close(ch) happens-before 从 ch 读到零值
无缓冲 channel 接收从无缓冲 channel 接收 happens-before 对应发送
MutexUnlock() happens-before 后续 Lock()
WaitGroup第 k 次 Done() happens-before Wait() 返回
OnceDo 内 f() happens-before 任何 Do 返回
atomicatomic 操作的读写按 atomic 内存序
go
var (
    data int
    done chan struct{} = make(chan struct{})
)

// goroutine A
data = 42
close(done)        // close happens-before ...

// main
<-done             // ... 接收完成
fmt.Println(data)  // 必然看到 42

直觉：channel / Mutex / WaitGroup 是"同步点"——跨越这些点，前一个 goroutine 写的东西对后一个可见。没有同步点的普通变量共享，就是 data race。

把"channel 发送如何建立 happens-before"画成图，同步点的可见性边界就清楚了：

channel 发送/接收建立的 happens-before（第 3 张）

图里 close(done) 到 <-done 之间那条虚线就是 happens-before 边：它把 goroutine A 在发送前的所有写入（包括 data = 42）"传递"给接收后的代码。没有这条边，data 的写入可能还留在 A 的写缓冲里、main 读到旧值——这就是 race。反过来，若两个 goroutine 只共享普通变量、中间没有任何同步边，编译器/CPU 的重排就能任意打乱可见性。

三、data race 与 -race 检测 ​

data race：两个 goroutine 无同步地访问同一变量，且至少一个是写。

go
// 这是 data race！count++ 无同步
var count int
for i := 0; i < 1000; i++ {
    go func() { count++ }()
}

count++ 是"读-改-写"三步，非原子。用 go test -race 或 go run -race 检测：

bash
go run -race main.go
# WARNING: DATA RACE ... write ... previous write ...

为什么一定要测 race：

  • data race 的后果是未定义——可能是旧值、撕裂值、甚至 panic。
  • 优化器在存在 race 时可能做破坏程序语义的重排。
  • 生产环境不可复现，必须开发期用 -race 抓住。

教训衔接：data race 的本质是"多核对同一地址的并发读写没有同步"，与本站讲缓存一致性（MESI）的可见性难题一脉相承，只是 Go 用同步点帮你避免，而 C/C++ 需要你显式加锁或 memory_order。

四、sync/atomic 与内存序 ​

Go 的 sync/atomic 提供原子读写，其内存语义是 sequentially consistent（顺序一致，SC），即最强的内存序——等价于 C++ 的 memory_order_seq_cst。

go
var counter atomic.Int64

counter.Add(1)              // 原子自增
v := counter.Load()         // 原子读
counter.Store(42)           // 原子写
ok := counter.CompareAndSwap(42, 100) // CAS

与 C++ 内存序对应 ​

GoC++语义
atomic.Xxx 全部操作memory_order_seq_cst全局顺序一致，最强
（Go 无显式 relaxed/acquire/release）memory_order_relaxed/acquire/release/acq_relGo 简化为统一 SC

取舍：Go 只暴露 SC 一种原子语义，写起来安全但可能比 C++ 的 relaxed 慢一点；C++ 的 release/acquire 是性能优化工具箱——详见本站 release/acquire 内存序。

Go 无锁：Go 支持无锁编程（atomic + CAS），但 GC 与逃逸让无锁队列的内存回收比 C++ 的 hazard pointer/epoch 简单——GC 本身在管理。衔接 无锁编程深入。

五、GC 与逃逸分析（影响性能的关键） ​

5.1 逃逸分析 ​

编译器判断一个变量是分配在栈还是堆。逃逸到堆的代价：堆分配 → GC 管理 → 可能触发垃圾回收停顿。

go
// 返回局部变量指针 → 逃逸到堆
func newMetric() *Metric {
    m := Metric{Name: "cpu"} // 逃逸，分配在堆
    return &m
}

// 值传递 → 不逃逸，分配在栈
func useValue(m Metric) {
    fmt.Println(m.Name)
}
bash
go build -gcflags="-m"  # 查看逃逸分析结果

5.2 三色标记 GC ​

Go 的 GC 是并发标记-清除，用三色标记法 + 混合写屏障：

颜色含义
白色可能被回收（待清除）
灰色可达但子对象未标记完
黑色已标记且子对象已处理

性能影响：

  • GC 停顿（STW）：虽然大部分与程序并发，但仍有短暂 STW，是延迟尖峰的来源之一。
  • 减少堆分配 → 减少 GC 压力 → 更稳定的延迟。这是 Go 性能优化的核心手段之一。
  • runtime.ReadMemStats() / pprof heap profile 可量化分配。

六、与本站主线衔接（最紧密的一篇） ​

  • 内存模型与 L4：Go 的 happens-before、SC atomic 正是本站 内存重排 与 原子操作 的"语言层实现"。读懂了 CPU 的 store buffer / 失效队列，就懂了为什么 Go 需要这些同步点。
  • 缓存一致性：data race 的可见性问题，根源是 MESI 缓存一致性——多核 L1 各有一份副本，无同步时互相看不到对方写入。
  • GC 调优：堆分配热点用 pprof 的 heap profile 定位，类比 C++ 用 valgrind 找泄漏。
  • 无锁与内存回收：Go 用 GC 简化无锁队列回收，对比 C++ 的 内存回收四方案。

实战：用 -race 抓一个真实 data race ​

内存模型不是纯理论，Go 自带竞态检测器能直接抓。下面这个程序有两个 goroutine 同时写同一个变量，没有同步：

go
package main

import "time"

func main() {
    var x int
    go func() { x++ }()   // goroutine A
    go func() { x++ }()   // goroutine B
    time.Sleep(time.Millisecond)
    println(x)
}
bash
go run -race main.go
text
WARNING: DATA RACE
Write at 0x00c0000xxxx by goroutine 6:
  main.main.func1()
      ./main.go:7 +0x3c
Previous write by goroutine 7:
  main.main.func2()
      ./main.go:8 +0x3c

-race 给出两个写操作的 goroutine 与代码行，明确指出"没有 happens-before 关系"。修复方式就是让它们同步——要么用 atomic.AddInt，要么用 sync.Mutex，要么用 channel 传递结果。竞态检测器只能在运行时命中实际跑到的竞态，所以压力测试 + -race 是发布前的必做项。

atomic 的内存序：和 C++ 怎么对应 ​

Go 的 sync/atomic 语义相对 C++ 更简单——它默认提供**顺序一致（sequentially consistent）**保证，没有 C++ 那套 memory_order_relaxed/acquire/release/seq_cst 的细粒度选择。这意味着 Go 的 atomic 更易用、但极端情况下少了一点优化空间。

你的意图GoC++ 对应
简单计数/标志atomic.AddInt64 / atomic.StoreInt64memory_order_relaxed 通常够，但 C++ 需显式写
发布指针（发布-获取）atomic.StorePointer + LoadPointermemory_order_release / acquire
最强保证默认即 seq_cstmemory_order_seq_cst

C++ 的 原子操作入门 把六种内存序讲得很细，Go 这边你基本不用担心选错序——默认就是最强的，调优空间留给真需要时再用更细的原语。本站 L4 内存序与屏障 从硬件层解释为什么这些序存在，值得对照看。

和 GC / 逃逸的关系：为什么内存模型里要提 GC ​

前面 GC 与逃逸分析 说"引用逃出函数就到堆"。堆上的对象被多个 goroutine 共享时，GC 的并发标记本身也是读这些对象——这时 visibility（内存可见性）不仅是你的业务 goroutine 之间的事，也是你和 GC 之间的事。Go 的内存模型保证：只要通过同步原语（channel 关闭、mutex 解锁、atomic）传递对象，GC 看到的一定是一致快照，不会半途回收还在用的对象。所以"内存模型"和"GC"在 Go 里是一体两面：前者管可见性顺序，后者管生命周期，两者靠同一套 happens-before 规则衔接。

一句话总结 ​

Go 内存模型用 happens-before 和 SC 级 atomic 提供了"安全省心"的并发内存语义——代价是比 C++ 的精确 memory_order 多一点点开销；写对靠同步点 + -race，写快靠减少堆分配、降低 GC 压力。

深入：并发模型 goroutine 与 channel → pprof 性能剖析与工程组织 → Go 实战入门总纲。