std::atomic x = 42;非法，因explicit构造函数禁止隐式转换；正确写法为std::atomic x{42};或std::atomic x = std::atomic{42};，且必须显式指定内存序、循环检查compare_exchange_weak返回值，指针原子操作不保生命周期安全。
atomic 的构造和初始化为什么不能随便赋值
直接 std::atomic<int> x = 42;</int> 看似合理，但会触发隐式转换——它调用的是 std::atomic<t>::atomic(T)</t> 构造函数，而这个构造函数是 explicit 的。编译器不接受隐式转换，所以这行代码在 C++17 及以后标准下会报错：error: conversion from 'int' to 'std::atomic<int>' is ambiguous</int>。
正确写法只有两种：
-
std::atomic<int> x{42};</int>（推荐，统一初始化，明确且安全） -
std::atomic<int> x = std::atomic<int>{42};</int></int>（冗余，不必要）
别用 = 直接赋字面量，这不是语法糖缺失，而是标准刻意阻止你忽略原子对象的“不可复制”本质——std::atomic 禁止拷贝构造和拷贝赋值，所有初始化必须显式、一次性完成。
load() 和 store() 的内存序参数不是可选装饰，而是行为开关
写 x.load() 看起来简洁，但它等价于 x.load(std::memory_order_seq_cst)，即最强一致性模型。多数场景不需要这么重——比如一个标志位只用于通知线程启动，用 std::memory_order_acquire 就够了；一个计数器只被单个写线程更新，读端用 std::memory_order_relaxed 完全没问题。
错误做法是全程无脑用默认序，后果是：
- 在 ARM/AArch64 上生成多余内存屏障指令，拖慢性能
- 在 x86 上虽影响小（因为其默认强序），但掩盖了真实同步意图，后续迁移到弱序架构时容易出错
- 调试时难以区分“数据依赖”和“顺序依赖”，增加竞态复现难度
实操建议：
- 读标志位（如
running）：用load(std::memory_order_acquire) - 写标志位：对应用
store(std::memory_order_release) - 纯数值累加（无依赖读写）：两端都可用
std::memory_order_relaxed
compare_exchange_weak() 循环里忘检查返回值，等于没写原子操作
这是无锁编程里最隐蔽的坑：compare_exchange_weak() 失败时不抛异常，也不改目标值，只返回 false。如果你写成：
int expected = x.load(); x.compare_exchange_weak(expected, desired); // ❌ 忘了判断返回值
那这行根本不会更新成功——失败后 expected 被自动更新为当前值，但你没重试，逻辑就卡死了。
正确模式永远是循环 + 显式检查：
int expected = x.load();
while (!x.compare_exchange_weak(expected, desired)) {
// expected 已被更新为当前值，继续尝试
}
注意点：
- 用
weak版本是因为它在某些平台上（如 x86）可能比strong版本快，但允许“伪失败”（spurious failure），所以必须循环 - 如果业务逻辑不允许重试（比如一次性的状态跃迁），且你确定不会伪失败，才考虑
compare_exchange_strong()，但代价是可能更重的指令 - 循环体内不要做耗时操作，否则会显著拉高 CAS 冲突率
atomic 搞不定指针重排，shared_ptr 和 unique_ptr 需要额外防护
std::atomic<:shared_ptr>></:shared_ptr> 是合法的，但它的 load() / store() 只保证指针本身的原子性，不保证所指向对象的生命周期安全。常见错误是：
- 线程 A 执行
ptr.store(nullptr)后，线程 B 的ptr.load()得到非空指针，但该指针指向的对象已被析构（引用计数归零发生在 store 之后） - 多个线程同时对同一
std::shared_ptr原子变量调用load()和store()，但没同步其内部控制块的访问
根本原因：原子操作只保护“指针值”，不保护“对象语义”。C++ 标准库为此提供了 std::atomic_shared_ptr（C++20 引入），但它仍需配合 std::make_shared 和正确 use_count 管理。
更稳妥的做法：
- 避免用
std::atomic<:shared_ptr>></:shared_ptr>做跨线程所有权转移，改用消息队列或std::queue+ 互斥锁 - 若坚持无锁，优先用裸指针 +
std::atomic<t></t>，并确保对象生命周期由外部严格管理（如对象静态存在、或由专用内存池托管） -
std::unique_ptr不可复制，因此std::atomic<:unique_ptr>></:unique_ptr>非法，别试
无锁不是把所有东西套上 atomic 就完事。真正难的从来不是怎么写，而是怎么证明它在所有路径下都线程安全——尤其是内存释放时机、对象可见性和重排序边界这三处，漏掉任意一个，崩溃就藏在下次发布之后。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
