Go协程是否存在内存重排？为何并发自增变量x输出为0？

示例代码 #

package main

import (
    "fmt"
    "runtime"
    "time"
)

func main() {
    var x int
    threads := runtime.GOMAXPROCS(0) // get max cpus,
    for i := 0; i < threads; i++ {
        go func() {
            for {
                x++
            }
        }()
    }
    time.Sleep(time.Millisecond * 100)
    fmt.Printf("threads = %v, x = %v\n", threads, x)
}

运行结果 #

threads = 8, x = 0

技术问题 #

1. 为何变量x的输出值为0？这是否属于CPU缓存中的内存重排现象？
2. 编译器、Linux系统或CPU对该程序执行了何种优化操作？

问题解答 #

问题1：变量x输出为0的原因及是否属于内存重排 #

x输出为0主要不是CPU缓存重排导致，核心原因是Go编译器的优化行为：

• 在main函数的执行流中，变量x被初始化为0后，main本身没有对x的写操作；而goroutine对x的修改没有通过任何同步原语（如互斥锁、原子操作）来保证可见性。
• Go编译器会认为，对于main函数来说，x的值从未被修改过，因此直接将fmt.Printf中读取x的操作替换成初始值0，完全跳过了对内存中x的实际读取。

内存重排是CPU或内存模型层面的指令顺序调整，但这里的本质是编译器的优化让main根本没去读实际的内存值，所以不属于内存重排现象。

问题2：相关优化操作 #

主要是Go编译器的优化，具体包括：

1. 可见性分析优化：编译器分析代码后，判定goroutine对x的修改无法被main函数观测到（因为缺少同步机制，不符合Go内存模型中"happens-before"的规则），因此在main中直接使用x的初始值0，而非读取内存中的实际值。
2. 栈变量优化：x是栈上分配的变量，编译器没有将其标记为需要逃逸到堆上，goroutine对x的修改仅在各自的CPU缓存中进行，但这不是导致输出0的核心——核心还是main根本没去读缓存或主存里的x。

Linux系统和CPU层面的缓存机制在此场景下不是主导因素，关键是编译器的静态代码优化。

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