理解Go内存模型：C并发无锁指针更新技巧为何错误？

这个问题刚好切中了并发编程里最容易踩的「内存可见性」和「指令重排」两个大坑，咱们结合Go内存模型的核心规则来拆解清楚：

先回忆下那个有问题的无锁方案 #

全局变量ptr指向mystruct结构体，更新逻辑是：先分配新的mystruct并填充数据，再将ptr指向新对象，试图对外暴露变更。

错误本质拆解 #

1. 指令重排打破了代码的预期顺序

你写的代码是「先填新结构体数据 → 再更新ptr指针」，但编译器和CPU为了提升性能，会在不破坏单线程语义的前提下，对内存操作进行重排。也就是说，实际执行顺序可能变成「先更新ptr指针 → 再填新结构体数据」。

这时候其他线程如果读取ptr，会看到它已经指向了新对象，但新对象的数据还没填充完，读出来的就是不完整的脏数据。

结合Go内存模型的规则：单个goroutine内的操作会按代码顺序执行，但不同goroutine之间没有这种默认的顺序保证。也就是说，你在一个goroutine里写的操作顺序，在其他goroutine眼里完全可能是乱的，除非你用同步原语建立顺序关系。

2. 内存可见性没有保障

就算没有指令重排，新结构体的数据写入操作，对其他线程来说也不一定是立刻可见的。现代CPU都有多级缓存，线程（goroutine）写入的数据可能先存在自己的CPU缓存里，还没同步到主存。而更新ptr的操作可能先同步到主存了，这时候其他线程读到ptr指向新对象，但去读新对象的数据时，读到的还是旧缓存里的脏数据。

Go内存模型的核心是**happens-before（先发生于）**规则：只有当操作A happens before 操作B时，A的结果对B才是可见的。在这个错误方案里，「填充新结构体数据」和「更新ptr」之间没有任何同步机制建立happens-before关系，所以其他线程看到ptr更新时，完全无法保证新结构体的数据已经完成并可见。

那Go里怎么写才对？ #

要解决这个问题，核心就是要在「新结构体数据写入」和「ptr更新」之间建立可靠的happens-before关系：

• 用sync/atomic包的原子操作：比如atomic.StorePointer来更新ptr，Go的原子操作会保证，在执行StorePointer之前的所有写操作，对后续读取这个指针的goroutine都是可见的；
• 用互斥锁sync.Mutex：加锁后的写操作，和解锁后的读操作之间自动建立happens-before关系，确保数据一致性；
• 用channel同步：把更新好的结构体通过channel发送出去，接收方拿到的一定是完整的数据，因为channel的发送操作happens before对应的接收操作完成。

总结一下：这个看似巧妙的无锁方案，本质上是忽略了并发环境下的指令重排和内存可见性问题，没有通过同步原语建立必要的happens-before关系，导致其他线程可能读到不一致的错误状态。

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