atomic_int与普通int有何区别？临界区读写int是否线程安全？

临界区内仅读写int类型变量是否具备线程安全性？ #

结论很明确：只要临界区的同步机制是正确的，仅操作int完全是线程安全的。
这里的核心前提是你用的是真正生效的临界区：所有访问这个int变量的线程，必须持有同一把同步锁（互斥锁、写锁都算）才能进入操作该变量的代码段，锁机制本身会保证临界区代码同一时间只有一个线程执行，从根源上避免并发交错，这种场景下根本不需要额外用原子类型。
要是你说的“临界区”只是自己逻辑上圈的一段代码，根本没加正确的同步保护，那哪怕只是读写int，照样会出线程安全问题。 #

普通int的读写操作本身是否不具备原子性？ #

不能一概而论，要拆分场景看：

• 在目前所有主流商用CPU架构（x86/x86_64、ARMv7及以上、RISC-V等）上，按照编译器默认对齐规则分配的32位int，单次独立的读、单次独立的写操作本身是原子的——你不会读到“半新半旧”的撕裂值，不会出现高16位是新写入的值、低16位还是旧值的情况。
• 但这个原子性的边界非常窄：只要是读-改-写类的复合操作，比如i++、i = i + 2、先判断当前值再写入这类包含多步操作的逻辑，哪怕操作的是普通int，也完全不具备原子性，并发下必然会出现竞态。
• 哪怕单次读写是原子的，普通int也不提供任何内存可见性、指令顺序的保证：编译器和CPU都可能对普通int的读写指令做重排序，编译器甚至可能把变量优化到寄存器里，导致其他线程永远看不到某个线程对int的写入结果，这同样是严重的线程安全问题。
• 特殊边界场景下普通int的单次读写也会失去原子性：比如人为修改对齐规则让int跨缓存行/跨内存页边界，或者在32位系统上操作64位长度的整型，都可能出现读写撕裂，只是常规开发中很少碰到这类场景。

atomic_int和普通int的核心差异 #

两者单线程场景下的执行结果没有任何区别，核心差异全部集中在多线程语义层面：

• 操作原子性覆盖范围不同：atomic_int的所有操作，包括读-改-写类的复合操作（自增、自减、交换值、比较交换等）全都是原子的，不需要加锁就能保证多线程并发下不会出现操作交错；普通int只有对齐场景下的单次读/写是原子的，所有复合操作都没有原子保障。
• 内存序与可见性保证不同：atomic_int的操作支持指定不同强度的内存序，编译器和CPU会根据要求插入对应的内存屏障，禁止不符合规则的指令重排，保证写入的值能按约定的顺序被其他线程观测到；普通int的读写没有任何这类约束，完全可能出现写入后其他线程迟迟读不到新值、代码执行顺序和书写顺序不一致的问题。
• 编译优化约束不同：编译器不会对atomic_int的操作做违反多线程语义的优化，比如不会合并多次对atomic_int的读写、不会把atomic_int长期缓存到寄存器不刷回共享内存；普通int在开启编译优化时，编译器会默认按单线程场景做激进优化，完全不考虑多线程并发访问的可能。

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