咨询Go内存模型示例中g.msg无法保证可见性的详细原理

DevOps 小满

2026-8-27

Go内存模型示例可见性问题原理解答

问题涉及的示例代码如下：

type T struct {
    msg string
}

var g *T

func setup() {
    t := new(T)
    t.msg = "hello, world"
    g = t
}

func main() {
    go setup()
    for g == nil {
    }
    print(g.msg)
}

核心认知误区澄清
单机器字读写的原子性，和跨goroutine的写入可见性、操作顺序保证是完全独立的概念。主流架构下运行的官方Go实现确实能保证单机器字长度的指针读写不会出现撕裂——也就是读g时要么拿到nil，要么拿到一个合法的*T类型地址，不会读到半写入的非法地址值。但这个保证仅针对g这个指针本身的读写完整性，完全不涉及g指向的内存区域的写入顺序，也不保证一个goroutine对g的写入能立刻被其他goroutine观测到。
Go内存模型判断跨goroutine写入可见性的唯一标准是happens-before关系：只有当对变量的写操作在happens-before关系上先于对该变量的读操作，读操作才能保证观测到写操作的结果。这个示例中两个goroutine的内存操作之间没有任何显式同步建立的happens-before关系，可见性从规范层面就没有任何保证。
重排序是未定义行为的核心根源
Go内存模型明确允许两类重排，只要重排不改变当前goroutine内的可观测执行结果即可：
1. 编译器在编译阶段对指令顺序的调整
2. CPU在执行阶段对指令顺序的乱序调整
  从setup所在goroutine的单线程视角看，以下两种执行顺序的执行结果完全一致，没有任何区别：
3. 申请T类型内存→给t.msg赋值→将t地址写入全局变量g
4. 申请T类型内存→将t地址写入全局变量g→给t.msg赋值
  因为没有同步屏障阻断重排，第二种执行顺序是完全被规范允许的。这种场景下主goroutine完全可能在g变为非nil、但t.msg还未写入的时候就读到g的值，此时读取g.msg会拿到字符串类型的零值（空字符串）。
  除此之外编译器还可能做更激进的优化：主goroutine循环检查g == nil时，因为没有同步操作标记g会被其他goroutine修改，编译器可以直接把g的值缓存到寄存器中，永远不重新读取主存的g值，导致程序直接进入死循环。
多次测试得到预期结果的原因
这种现象属于未定义行为在特定运行环境下的偶然正确，不代表代码符合规范：
- x86/amd64桌面级CPU属于强内存模型，硬件层面会拦截大部分可能导致指针赋值先于结构体字段赋值对外可见的重排序
- 当前稳定版Go编译器对这类简单函数的编译优化还没有触发对应重排逻辑
- 当前Go运行时的实现没有把无同步操作的空循环直接优化为无限死循环，主goroutine最终还是能读到g的更新
  以上所有都是具体实现的偶然表现，不是Go内存模型承诺的保证。一旦编译器版本升级引入更激进的重排优化、或者代码运行在arm/riscv这类弱内存序架构上，就可能出现不符合预期的执行结果。
正确的实现方式
要保证g.msg的写入一定能被主goroutine观测到，必须引入显式同步建立happens-before关系：可以通过无缓冲channel传递指针、用sync.Mutex对g的读写加锁、或者用atomic包的原子操作配合正确的内存序约束。

内容的提问来源于stack exchange，提问作者linsan