写这篇文章的起因，是我最近在review一个无锁队列的实现时，被同事问了一个问题：std::atomic<std::string>这种代码，编译器为什么不给过？当时我下意识地回了一句“因为原子变量要做成lock-free，string做不到”。但真往深了想，std::atomic<T>的底层约束远不止“做不到lock-free”这么简单，它背后藏着的是CPU原子指令的能力边界。
我在多线程编程上踩过的坑不算少，从volatile救不了并发，到无锁队列在自己机器上跑得好好的、一上ARM就废，到最后发现整条链路都卡在“CPU到底支持哪些原子指令”上。这篇文章就把我总结出来的std::atomic<T>的4大铁律讲清楚：为什么有这些限制、这些限制从哪来、实际编码时该怎么绕。适合正在学C++多线程、准备写无锁数据结构、或者被面试官问过“atomic为什么不能放自定义类型”的读者。
1. 铁律一：lock-free不是默认属性，CPU原子指令只覆盖特定长度
1.1 标准里唯一保证lock-free的，只有std::atomic_flag
很多新手（包括当年的我）会把std::atomic<T>和“无锁”画等号，这个误解非常危险。C++标准里真正无条件保证lock-free的只有std::atomic_flag这一个类型，它专门用来实现自旋锁之类的底层同步原语，只有test_and_set、clear两个操作，连load和store都不提供。
至于std::atomic<T>，标准用的是枚举值memory_order来表示操作性质，而“无锁”这件事，标准的态度是：对每个类型，平台可以选择提供lock-free实现，也可以选择用内部锁兜底，还可以做成一个类型在某些CPU上是lock-free、在另一些CPU上不是。标准只承诺在某个特定头文件宏ATOMIC_*_LOCK_FREE里告诉你是哪种情况。
1.2 is_always_lock_free与is_lock_free：编译期和运行期的两个视角
C++17引入了is_always_lock_free这个编译期常量，它是std::atomic<T>的一个静态成员，用来表示“这个类型在当前平台上是不是总是lock-free”。而成员函数is_lock_free()是运行期查询，这两个的区别在x86平台上有一个非常经典的例子：16字节类型。
当你在x86-64上用std::atomic<__int128>或者std::atomic<一个16字节的结构体>时，is_lock_free()返回什么取决于运行时的CPU是否支持CMPXCHG16B指令。Intel早期的x86-64处理器不支持这条指令，但后来基本都支持了。所以同一份二进制，在支持CMPXCHG16B的CPU上is_lock_free()返回true，在不支持的CPU上返回false。而is_always_lock_free这个编译期常量，在编译时就要对所有目标CPU给出统一答案，所以它极有可能是false。
实操的时候，我的建议是：如果需要依赖某类型一定lock-free，就用static_assert(std::atomic<T>::is_always_lock_free)把它钉死在编译期。如果只在运行期判断，那就要写分支，处理“不是lock-free”的降级路径，或者干脆直接拒绝使用。
#include <atomic> #include <iostream> struct alignas(16) MyStruct { unsigned long long a; unsigned long long b; }; int main() { std::atomic<MyStruct> obj; std::atomic<uint64_t> i64; std::atomic_flag flag; std::cout << std::boolalpha; std::cout << "atomic_flag is_always_lock_free: " << decltype(flag)::is_always_lock_free << "\n"; std::cout << "atomic<uint64_t> is_always_lock_free: " << decltype(i64)::is_always_lock_free << "\n"; std::cout << "atomic<MyStruct> is_always_lock_free: " << decltype(obj)::is_always_lock_free << "\n"; std::cout << "atomic<MyStruct> is_lock_free(): " << obj.is_lock_free() << "\n"; }1.3 为什么CPU原子指令有长度上限——从LOCK前缀到CMPXCHG16B
要理解为什么不是所有类型都能lock-free，得先看清楚CPU原子指令长什么样。以x86为例，所谓原子指令，本质是“在指令执行期间锁住内存总线或缓存行”，让其他核心无法插入中间状态。最典型的几条：
| 指令 | 作用 | 典型C++操作 |
|---|---|---|
LOCK XADD | 原子加并返回旧值 | fetch_add |
LOCK XCHG | 原子交换 | exchange |
LOCK CMPXCHG | 原子比较并交换 | compare_exchange_* |
LOCK INC/DEC | 原子自增/自减 | fetch_add(1) |
这几条指令的操作数长度是有硬件上限的。x86-64下，标量整数原子指令通常能覆盖1/2/4/8字节；16字节需要CMPXCHG16B配合LOCK前缀；再大的类型，x86就没有原生指令可用了。ARM那边走的则是LDREX/STREX这套LL/SC（Load-Linked/Store-Conditional）机制，同样只支持有限长度的数据访问。
这就是std::atomic<T>不能随心所欲放任何类型的最底层原因：如果T的大小超出了CPU原子指令能覆盖的范围，编译器唯一的选择就是在库内部塞一把锁，把原子操作的语义用临界区模拟出来。
1.4 别在bool和自定义类型上踩lock-free的坑
有一种类型特别容易让人放松警惕：超过一个机器字长的小结构体。比如：
struct Point { int x; int y; };它只有8字节。在很多64位平台上，std::atomic<Point>确实能通过CMPXCHG16B之类的指令做到lock-free，但注意是“在64位平台上”。如果这套代码被编译到32位平台，8字节对象的原子操作可能就会退化为锁实现。你写的时候觉得“这struct挺小的，肯定没问题”，实际上完全取决于目标架构。
所以我的经验是：除非你明确知道目标平台和CPU指令集，并且用is_always_lock_free验证过，否则不要把lock-free当成std::atomic<T>的默认属性。它是CPU给的礼物，不是C++标准给的承诺。
2. 铁律二：trivially copyable是门槛，复制语义决定CPU指令能级
2.1 标准要求与编译报错实例
std::atomic<T>的应用条件，标准里写得很清楚：T必须是trivially copyable。违反了这个条件，编译期直接报错。下面这段代码就是典型的错误示范：
#include <atomic> #include <string> struct BadType { std::string name; int value; }; int main() { std::atomic<BadType> atomicBad; // 编译错误 return 0; }报错信息大致是“static assertion failed: std::atomic requires a trivially copyable type”。很多人第一次看到这个错误是懵的：我这么小的结构体，怎么就不trivially copyable了？因为里面有std::string，而std::string内部有堆内存指针和引用计数（取决于实现），不是trivially copyable的。
2.2 CPU原子指令的本质是内存总线上的单一读改写
为什么标准要做这个限制？还是得回到CPU原子指令的机制。LOCK XCHG这类指令，对硬件的意义是：一个指令周期内，对某块内存完成“读出旧值、修改、写回新值”，全程不允许其他核心看到中间状态。硬件层面没有所谓“构造函数”“拷贝赋值”的概念，它就是物理地读写内存里的字节。
如果T有自己的拷贝构造逻辑，比如引用计数shared_ptr那种——拷贝时要把旧对象的计数值减一、新对象的计数值加一——那么CPU原子指令对这个对象直接做内存覆盖写，这些逻辑根本没机会执行，对象的内部不变量瞬间被破坏。而且这种破坏是无声无息的，调试器都很难抓到现场。
2.3 为什么有用户定义拷贝构造不行？——从实现角度剖析
可以理解为：std::atomic<T>希望T能退化成一堆裸字节。对trivially copyable的类型，memcpy和memmove直接拷贝字节序列就能保持语义，原始对象和目标对象“值相等”。而一旦用户定义了拷贝构造，类型就携带了“自定义行为”，不再是纯字节序列。std::atomic<T>的底层实现如果要操作用户自定义的拷贝逻辑，要么在每个原子操作里调用拷贝构造（那就必然引入锁，不可能是lock-free），要么干脆不让编译——C++标准的抉择是后者，拒绝编译。
提示：这里的“trivially copyable”可以在编译期用
std::is_trivially_copyable_v<T>检查。编码时把这个检查写进static_assert，报错信息比编译器默认的静态断言更友好：static_assert(std::is_trivially_copyable_v<T>, "MyAtomicWrapper requires trivially copyable T");
还有一点经常被忽略：trivially copyable只保证复制是字节级拷贝，不保证类型没有padding（填充位）。这意味着std::atomic<T>内部比较两个值是否相等时，可能因为padding字节的随机内容而出现“值看起来没变、但compare_exchange失败”的问题。C++20的std::atomic_ref对这个场景有专门讨论，但对std::atomic<T>来说，这条很难查的bug我建议你直接用“别让结构体带padding”来规避，比如给字段排好序或显式补齐大小。
3. 铁律三：内存序的代价藏在CPU指令里，不只是编译器屏障
3.1 从x86强内存序到ARM弱内存序
理解std::atomic<T>的内存序参数之前，得先建立一个认知：C++内存模型是抽象层，CPU指令集是物理层，两者之间隔着编译器优化和硬件重排。x86是TSO（Total Store Order）强内存序架构，普通mov指令就有比较好的顺序保证，读操作天然带acquire语义、写操作天然带release语义。ARM则完全不同，是弱内存序架构，普通ldr/str之间几乎没有任何顺序保证，CPU和编译器都可能自由重排。
这带来了一个非常反直觉的事实：在x86上，你用memory_order_relaxed和用memory_order_seq_cst，最终生成的CPU指令可能一模一样，都是普通的mov。但是在ARM上，两者生成的机器码天差地别——seq_cst可能要插入昂贵的dmb ish全屏障指令。
3.2 memory_order各等级在两大架构上的实际代价
我整理了一张实操对照表，这张表我贴在工位旁边很久了：
| memory_order | x86-64实际指令 | ARM64实际指令 | 典型延迟感受 |
|---|---|---|---|
relaxed | 普通mov | 普通ldr/str | 几乎零额外开销 |
acquire | 普通mov（编译器限制） | LDAR | 略高 |
release | 普通mov（编译器限制） | STLR | 略高 |
seq_cst | store可能变xchg或mov+mfence | 需要dmb ish | 可能高一个数量级 |
注意，x86-64上seq_cst的store并非完全无代价。由于TSO模型下store不会立刻被其他核心看到，而C++要求的seq_cst全局顺序又不允许store被延迟暴露，所以编译器有时会把seq_cst的store替换成XCHG指令，或者store之后加一条MFENCE。实测下来，在高频store场景里，这个差距是能明显感知的。
3.3 跨平台性能陷阱：seq_cst默认值在弱内存序架构上的代价
C++缺省的内存序是memory_order_seq_cst，而它恰好是最贵的。如果你在ARM上跑一个高频读写的计数器，fetch_add(1, std::memory_order_relaxed)和fetch_add(1, std::memory_order_seq_cst)的性能差距可能超过一个数量级。我有一次在ARM开发板上压测无锁队列，随手写了默认内存序，结果吞吐比预期慢了三倍多；把内存序改成acquire/release配对之后，立刻恢复正常。问题不在于默认值错，而在于默认值是为“绝对正确”设计的，不是为“性能最优”设计的。
那怎么选内存序？我的判断依据很简单：先问自己，这个原子操作到底需要什么顺序保证？
- 只是统计一个次数，不关心其他变量顺序，用
memory_order_relaxed。 - 需要“读到别人写的数据”，也就是要建立happens-before关系，用
acquire（读）和release（写）配对。 - 需要“所有线程看到的操作顺序完全一致”，比如实现无锁队列的head/tail指针管理，才用
memory_order_seq_cst。
3.4 一个实测内存序选择的小例子
我写过一个小工具，统计不同内存序下fetch_add的耗时，在x86上跑差不多，在ARM上差距非常直观。代码逻辑很简单：
#include <atomic> #include <chrono> #include <iostream> constexpr int N = 10000000; template <memory_order order> void bench(const char* name) { std::atomic<uint64_t> counter{0}; auto start = std::chrono::steady_clock::now(); for (int i = 0; i < N; ++i) { counter.fetch_add(1, order); } auto end = std::chrono::steady_clock::now(); double ms = std::chrono::duration<double, std::milli>(end - start).count(); std::cout << name << ": " << ms << " ms\n"; } int main() { bench<memory_order_relaxed>("relaxed"); bench<memory_order_seq_cst>("seq_cst"); return 0; }在x86上跑，两个结果几乎一样；在ARM上跑，差距肉眼可见。用这个工具跟团队讲解“内存序不是玄学，是实打实的CPU指令代价”，比贴标准文档好使多了。
4. 铁律四：atomic的大小和对齐不保证与T一致，CAS不是万能
4.1 size与alignof被向上取整——padding的真相
std::atomic<T>内部不是简单包一个T完事。为了满足原子操作的硬件对齐要求，编译器经常会把std::atomic<T>的大小和对齐向上取整。最典型的例子是，一个只有3个字节的小结构体：
struct ThreeByte { char a; char b; char c; };sizeof(ThreeByte)是3，但sizeof(std::atomic<ThreeByte>)很可能变成4、8甚至更大。因为CPU原子指令通常要求操作数按自身大小对齐，3字节对齐在很多平台上没法直接对应到某条原子指令，编译器只能补齐或者干脆用锁。
更隐蔽的问题是缓存行伪共享（false sharing）。当你用std::atomic<T>作为队列中的槽位时，如果两个原子变量恰好落在同一个缓存行里，两个核心各自修改它们，会导致缓存行在核心之间反复横跳，性能断崖式下跌。这时候不管你内存序选得多好，硬件层面已经打成一片了。解决办法也简单：把高频写入的原子变量按缓存行大小（通常64字节）对齐分隔，或者用alignas(64)把它们分散到不同缓存行。
4.2 CAS循环的代价：compare_exchange_weak的LL/SC与ABA
compare_exchange是std::atomic<T>提供的最强操作，但也是性能最容易被高估的操作。先看compare_exchange_weak和compare_exchange_strong的区别：
在x86（CAS指令）上，两者差距不大；在ARM（LL/SC机制）上，weak版本允许“伪失败”——也就是没有任何其他线程修改，硬件也可能因为中断、异常等原因导致SC失败。所以weak版本必须放在循环里配合重试，而这么做正是LL/SC语义的要求。如果你在ARM上用strong版本实现一个需要反复CAS的循环，性能会明显劣化，因为它内部会自动帮你重试，而每次重试都包含完整的内存屏障开销。
拿无锁栈做例子，一个典型的CAS循环长这样：
template <typename T> class LockFreeStack { struct Node { T value; Node* next; }; std::atomic<Node*> head; public: void push(T val) { Node* node = new Node{std::move(val), nullptr}; Node* expected = head.load(std::memory_order_relaxed); do { node->next = expected; } while (!head.compare_exchange_weak(expected, node, std::memory_order_release, std::memory_order_relaxed)); } };这个循环在低竞争下没问题，一旦竞争激烈，失败的线程会反复循环重试，CPU占用率飙升。更痛苦的是ABA问题：线程A读到头指针是X；线程B弹出X、释放X、又压入一个地址恰好相同的X；线程A的CAS成功——但此时X对应的节点内容已经变了，栈结构被破坏。这就是所谓的ABA问题，无锁数据结构里必须用带标记的指针或者hazard pointer之类机制解决，而std::atomic<T>本身不会替你处理。
4.3 什么时候别用atomic而要用锁——其实锁也未必差
很多人一听说“无锁”，就默认它比互斥锁快。这个直觉在低竞争场景是对的，在竞争激烈时则往往相反。CAS循环在竞争激烈时的行为类似于自旋锁：每个失败者都在拼命重试，缓存行在多个核心之间反复失效，总吞吐可能远低于一个简单的std::mutex。
std::mutex在无竞争时的开销大概就是几十纳秒级别（futex快速路径），已经非常轻量。我的经验法则是：先写简单正确的锁版本，压测之后用profiler确认瓶颈确实在锁竞争上，再考虑换无锁。除非是高频交易、游戏引擎核心循环这种对确定性要求极高的场景，否则无锁的收益很容易被复杂度吃掉。
4.4 这四条铁律在实际工程中的应对策略
总结下来，我组内现在写原子相关代码会强制走这么一套检查流程：
- 先确认这个类型的大小：1/2/4/8字节优先，16字节谨慎，超过16字节直接放弃lock-free。
- 用
static_assert(std::is_trivially_copyable_v<T>)和static_assert(std::atomic<T>::is_always_lock_free)把不满足条件的组合拦在编译期。 - 明确每个原子操作需要的内存序：能不
seq_cst就不seq_cst，能relaxed就relaxed。 - 结构体字段注意对齐和padding，高频访问的原子变量手动按缓存行对齐。
- 涉及CAS循环的无锁结构，先画清楚ABA问题的处理方案，写不出方案就回去用锁。
这套流程帮我们省掉过至少三次线上级别的崩溃排查。有一次一个同事把std::atomic<uint64_t>放在两个线程各写一个相邻字段的同一个结构体里，结果就是缓存行颠簸，服务端延迟涨了10倍。他把代码给我看的时候，我已经能闻到伪共享的味道了——alignas(64)加上去，延迟立刻恢复。
5. 一个完整排查案例：atomic<结构体>在ARM上的神秘退化
5.1 现场：同样的代码，x86 20ns，ARM 2us
有一次我在ARM开发板上移植一个自研的无锁MPSC队列，x86上每个操作稳定在20ns左右，ARM上直接飙到2us，差了100倍。一开始以为是ARM本身慢，但一个简单的std::atomic<uint64_t>fetch_add明明只要几十ns，问题肯定不在硬件。
5.2 排查：拆到最小复现，发现是is_lock_free()在作怪
我一点点拆分代码，最后发现队列的Node里存的是一个16字节的payload结构体。在x86-64的开发机上，CMPXCHG16B让std::atomic<Payload>保持了lock-free；但ARM64平台上，虽然理论上LDXP/STXP可以处理16字节，但C++标准库实现可能因为对齐策略或指令集选择，直接对这个类型使用了内部锁——is_lock_free()返回false。
也就是说，我天真地以为自己在写无锁队列，实际在ARM上每个操作都要抢一把内部libatomic的全局锁，大量线程在那里排队。2us的延迟，不是原子指令的延迟，而是锁的延迟。
5.3 修复：用8字节指针替代16字节载荷
修复方式并不复杂：把Node里直接存放的16字节数据改成8字节指针，指向真正存数据的内存块。这样原子对象变成std::atomic<Node*>，8字节，在所有主流64位平台上都是lock-free，ARM上的性能立刻回到几十纳秒级别。
这个案例是四条铁律的活教材：不只是“能不能lock-free”，还要在目标平台上实测is_lock_free()；不只是“类型大小在x86上没问题”，还要考虑ARM等不同指令集架构的差异化支持。
5.4 引申：std::atomic_ref与无锁世界的边界
C++20引入了std::atomic_ref，允许对非原子对象执行原子操作。它在实际工程里可以避免拷贝，比如直接原子操作一个大数组的某个元素，或者把两个线程共享的普通int临时当作原子变量访问。但注意，std::atomic_ref同样要遵守上面所有限制：类型必须trivially copyable、大小必须在硬件可原子访问范围内、并且对象生命周期内不能有其他线程同时对它做非原子访问。
我也踩过一个std::atomic_ref的坑：对一个普通结构体的字段做原子操作，但另一个线程直接普通赋值。这算是数据竞争，属于未定义行为，但在x86上跑得很“正常”，换到ARM上就出现了怪异的偶发崩溃。无锁世界的边界很多时候就是这样：硬件没那么可靠，标准模型才是准绳。
写在最后的一些体会
玩C++多线程这么多年，我对std::atomic<T>的态度从最初的“什么都能原子化”变成现在非常谨慎的“先查指令集，再写代码”。它本质上是一个跨平台的抽象层，但抽象层不意味着magic——CPU原生不支持的大小、自定拷贝语义、弱内存序屏障成本、对齐与padding问题，这些都是藏在“现代C++很安全”表象下的暗礁。
如果让我给一个结论，那就是：能用std::atomic的场景，优先用最简单基础类型的std::atomic；需要无锁自定义结构体时，先验证is_always_lock_free再动手；任何CAS循环先想清楚ABA问题；内存序别默认seq_cst写到底。这些习惯看起来很怂，但正是它们帮我在线上躲过了一颗又一颗的雷。最后再分享一个小技巧：写原子类型相关代码前，先编一个只输出宏的小程序看一眼ATOMIC_*_LOCK_FREE宏的值，再决定要不要继续。这个小动作花不了两分钟，省下来的查bug时间是按天算的。
