Go语言中指针访问为何触发数据竞争？是否真的不安全？

先直接给结论：这不是“最佳实践”层面的问题，而是确实违反了Go内存模型，存在实际运行风险，绝对不能忽略。

1. 会不会出现“损坏的指针地址”？ #

在大多数现代64位/32位CPU架构上，单个机器字的读写是原子操作，所以大概率不会出现“半新半旧”的指针地址。但这只是硬件特性，Go语言的内存模型不依赖也不保证普通变量的读写具备原子性和可见性：

• 编译器可能会对指令做重排优化，导致写操作的结果无法及时被读goroutine看到；
• CPU缓存的存在可能让读goroutine一直读取缓存里的旧值，永远看不到更新后的指针；
• 极端情况下，甚至可能出现Go规范未定义的行为，导致程序崩溃或逻辑异常。

2. 竞态检测器报警的原因 #

竞态检测器的核心逻辑是：当一个goroutine写某个变量，同时另一个goroutine在无同步原语的情况下读（或写）同一个变量，就判定为数据竞争。你的代码中values指针的写和读完全没有同步，完全符合这个触发条件，所以必然会报警。

3. 能不能不用同步特性？ #

哪怕99.9%是读操作，也不能省略同步。不过你担心的复杂度和性能问题其实很好解决：

• atomic.Pointer的开销极小：它的Store和Load操作本质就是CPU级的原子指令，几乎没有额外性能损耗，比Mutex轻量得多；
• 如果你的指针是一次性初始化后不再更新，可以用sync.Once来保证初始化的原子性，后续读取不需要同步，但你的代码是循环更新指针，这个方案不适用。

修正后的代码示例 #

用atomic.Pointer替换普通指针，完全消除数据竞争：

package main

import (
    "fmt"
    "sync/atomic"
    "time"
)

func main() {
    var values atomic.Pointer[map[string]string]

    go func() {
        for {
            newMap := make(map[string]string)
            newMap["foo"] = "bar"
            values.Store(&newMap)
            time.Sleep(time.Second)
        }
    }()

    go func() {
        for {
            savedMap := values.Load()
            if savedMap == nil {
                continue
            }
            fmt.Println("savedMap:", savedMap)
            time.Sleep(time.Second)
        }
    }()

    select {} // 阻止主goroutine提前退出
}

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