为何64位CPU上的64位操作非天然原子？机器字长内变量并发访问可直接编码吗？

先给核心结论 #

别信网上传的“字长以内的变量天然原子”的说法，绝大多数场景下，直接对这类变量做无同步并发读写，轻则出莫名其妙的bug，重则直接触发未定义行为搞崩整个程序——本质上是很多人把CPU手册的硬件规则、高级语言的内存模型规则混为一谈了。

第一层面：CPU给出的原子性保证到底是什么 #

主流x86、ARM等架构的手册中，仅对满足两个条件的内存访问提供硬件级原子性承诺：

1. 变量的地址是自然对齐的——也就是变量的起始地址，是自身字节长度的整数倍（比如8字节的64位变量，起始地址必须能被8整除）
2. 单次访问的宽度不超过对应的总线传输宽度、且不会横跨两个独立的缓存行
   只有满足这两个条件，CPU才会把这次读写操作作为不可分割的总线事务处理，不会拆成多次传输，单核心视角下的读写是原子的。
   举个实际的反例：64位CPU的缓存行一般是64字节，如果你把一个8字节的64位变量放在地址0x3C的位置，它的前4字节在0x38开头的第一个缓存行，后4字节在0x40开头的第二个缓存行——这时候哪怕变量本身只有8字节，远小于机器字长，CPU也会拆成两次总线操作完成读写，原子性直接失效。

第二层面：为什么拿到CPU的原子保证，也不能直接在高级语言里无同步写并发代码 #

这里存在三个跨层的规则断层，每一个都可能让你以为“安全”的代码直接出问题：

1. 编译器优化是第一大干扰项 #

你写在高级语言里的普通变量，从来不是CPU内存里那个固定的地址。编译器在优化时，可以随意调整指令顺序、把变量缓存到寄存器、甚至把对同一个变量的多次读写合并或拆分，根本不会默认帮你生成满足CPU原子访问要求的指令。
哪怕你写的是8字节对齐的变量，在开-O2这类高优化等级时，编译器完全可能把连续的两次8字节读，拆成两次4字节的32位访问，或者把变量的值长期存在寄存器里，永远不把写操作刷回内存——这时候哪怕硬件本身支持原子访问，软件层面生成的代码也根本不是原子的。

2. 高级语言的内存模型不认可“碰巧原子”的访问 #

绝大多数支持多线程的语言（C/C++、Rust、Go等），都有明确的内存模型规则：对非原子标注的普通变量的并发读写，属于标准定义的“数据竞争”，只要触发数据竞争，程序就进入未定义行为状态。
换句话说：哪怕你生成的汇编代码碰巧是对齐的、字长宽度的、硬件层面原子的访问，只要你没有把这个变量声明为原子类型，语言规则就不承认这种访问是合法的——编译器完全可以基于“没有数据竞争”的前提做极端优化，比如直接把所有读这个变量的代码删掉，因为它默认没有别的线程会修改这个变量。

3. 单次原子读写不代表能完成线程同步 #

就算你用了原子类型，拿到了硬件层面的单操作原子性，也不代表你不需要额外同步。因为原子操作本身是有不同内存序的：

• 最松弛的原子操作，只能保证单次读写不会被拆成半截，没法保证不同线程之间的内存可见性、没法保证跨操作的执行顺序
• 比如线程A先写了配置变量，再通过一个原子标记告诉线程B配置已经写完，没有对应的内存屏障的话，线程B可能读到标记已经置位了，但配置变量还是旧值——这就是典型的没有同步导致的逻辑错误，和操作本身是不是原子根本没关系。

常见的认知误区梳理 #

• 只要变量大小≤机器字长，就一定是原子操作。错，必须同时满足自然对齐、不跨缓存行、编译器不拆分三个前提，硬件原子性才成立。
• 硬件层面的原子性，等价于高级语言层面并发安全。错，只有语言明确认可的原子类型的访问，才允许无锁并发，普通变量哪怕碰巧满足硬件原子性，触发数据竞争依然是未定义行为。
• 有原子读写就不用锁/通道了。错，原子操作只是同步机制的基础，要实现跨线程的状态一致，要么配合对应的内存序屏障，要么用锁、通道这类更高层的同步原语，光靠单条原子load/store根本解决不了多步操作的原子性问题。

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