Go 内存模型

Mon, 20 Apr 2026 14:25:00 +0800

前面的文章我们讲了 Mutex、Channel、atomic 等各种并发工具，但有一个更底层的问题我们还没回答——一个 goroutine 写入的值，另一个 goroutine 什么时候能看到？ 这就是 Go 内存模型（The Go Memory Model）要回答的问题。

注意：这里的"内存模型"不是内存分配/回收，而是 并发环境下变量的可见性规则。

一、为什么需要内存模型？

直觉上，代码应该按你写的顺序执行。但现实中有两个因素会打破这种直觉：

┌──────────────────────────────────────────────────────────────┐
│ 打破执行顺序的两个因素 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 1. 编译器重排 │
│ 编译器为了优化性能，可能调整指令执行顺序 │
│ 只要在单 goroutine 内语义不变，就允许重排 │
│ │
│ 2. CPU 多级缓存 │
│ 每个 CPU 核有自己的 L1/L2 缓存 │
│ 一个核写入的值不一定立即对其他核可见 │
│ │
└──────────────────────────────────────────────────────────────┘

看一个例子：

内存模型 on Chen Shungen

Go 内存模型

一、为什么需要内存模型？