Go编译器是否会重排指定代码？此类写法是否存在并发安全问题？

首先，我们先对齐Go内存模型的核心规则：

编译器和处理器可以重排单个goroutine内的读写操作，只要重排后该goroutine自身的执行结果符合Go语言规范的预期。

回到你的writem函数——站在单个goroutine的视角看，把m = tmpm提前到for循环之前，对writem自身的行为没有任何影响：因为这个函数里后续根本不会读取m的值，填充tmpm的过程也和m无关。所以编译器完全有权限做这个重排优化（尤其是开启编译优化时）。

一旦发生这种重排，问题就来了：

• 当第一个writem把m = tmpm提前后，readm goroutine启动时，m已经指向了那个还在被循环填充的tmpm
• Go的map本身不支持并发读写，这种情况下就会触发未定义行为——可能是遍历到不完整的数据，可能是程序直接崩溃，甚至可能出现更诡异的内存问题

哪怕现在你的程序运行正常，也只是运气好没触发重排或者并发冲突而已，这属于“侥幸正确”的代码，绝对不能依赖。

怎么修复才安全？ #

你需要通过同步原语来保证m的读写互斥，同时避免编译器重排带来的内存可见性问题，这里给两种常见方案：

方案1：用互斥锁sync.Mutex保护

import "sync"

var m map[int]int
var mu sync.Mutex

func writem() {
    tmpm := make(map[int]int)
    for i := 0; i < 4000000; i++ {
        tmpm[i] = i + 10
    }
    // 写m时加锁，确保读操作不会看到未完成的赋值
    mu.Lock()
    m = tmpm
    mu.Unlock()
}

func readm() {
    // 读m时先加锁，拷贝到临时变量再释放锁，减少锁持有时间
    mu.Lock()
    tmpm := m
    mu.Unlock()
    for k, v := range tmpm {
        _, _ = k, v
    }
}

func main() {
    writem()
    go readm()
    writem()
}

方案2：用sync.Map（适合频繁读写的场景）

sync.Map是Go标准库提供的并发安全map，专门优化了频繁读、少写的场景，直接替换普通map即可：

import "sync"

var m sync.Map

func writem() {
    tmpm := make(map[int]int)
    for i := 0; i < 4000000; i++ {
        tmpm[i] = i + 10
    }
    // 清空旧数据，写入新的批量数据
    m.Range(func(key, value interface{}) bool {
        m.Delete(key)
        return true
    })
    for k, v := range tmpm {
        m.Store(k, v)
    }
}

func readm() {
    m.Range(func(key, value interface{}) bool {
        k, v := key.(int), value.(int)
        _, _ = k, v
        return true
    })
}

func main() {
    writem()
    go readm()
    writem()
}

最后再强调下 #

你的担忧非常准确，Go的重排规则确实会给这类“看似没问题”的代码埋下隐患。编写并发Go代码时，一定要严格遵循内存模型，用同步原语保证数据的安全性和可见性，不要依赖编译器的“仁慈”。

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