Go 内存模型
Go 内存模型描述并发执行中不同 goroutine 对内存读写何时可见,是理解同步原语和竞态问题的底层语义基础。
#type / concept
#status / growing
#tech / dev
#resource / go
[!info] related notes
- 所属 MOC: Go 高级运行时与抽象 MOC
- 前置概念: Go sync 包, Go race detector
- 并列概念: Go goroutine
Go 内存模型
一句话定义
Go 内存模型描述的是:在并发执行下,一个 goroutine 对内存所做的写入,何时能被另一个 goroutine 可靠看见。
核心机制 / 工作原理
并发程序里真正棘手的问题,不只是“有没有两个 goroutine”,而是:
- 写入是否已经发生
- 读取是否一定能看到那次写入
- 哪些同步动作建立了可靠的先后关系
Go 内存模型关心的核心就是这些“可见性”和“顺序性”边界。
因此,锁、channel、WaitGroup、原子操作的意义,不只是“防止同时写”,还包括建立足够明确的 happens-before 关系。
最小例子 / 最小场景
如果一个 goroutine 更新共享变量,另一个 goroutine 在没有任何同步手段的情况下直接读取,那么即使“看起来很简单”,结果也可能不可靠。
为什么这部分重要
当你开始写 worker pool、pipeline 或高并发服务时,只靠“代码顺序直觉”已经不够。内存模型决定了你对并发正确性的底层判断方式。
边界与易混淆点
- 代码写在前面,不等于另一个 goroutine 就一定按这个顺序看到
- “偶尔跑对了”不代表并发语义正确
- 内存模型不是日常 CRUD 必背内容,但一旦进入并发深水区,它就是底层地图