std::atomic仅支持平凡可复制且无用户定义构造/析构/赋值的类型，如int、指针、固定宽度整型；C++20起才正式支持浮点类型；必须显式初始化，自定义类型需满足trivially copyable且大小通常≤16字节。
atomic 的基本用法和类型限制
不能对任意类型使用 std::atomic，只有满足 trivially copyable 且不包含用户定义构造/析构/赋值的类型才可特化。常见可用类型包括 int、long long、bool、指针（如 int*），以及固定宽度整型（如 std::atomic）。
浮点类型（如 float、double）在 C++20 前不被标准保证支持，部分编译器（如 GCC）提供扩展支持，但行为不可移植；C++20 起才正式纳入 std::atomic 等。
-
std::atomic对象必须显式初始化，不能依赖默认构造（除非是 POD 类型且你接受零初始化） - 不要对
std::atomic<:string>或std::atomic<:vector>>这类类型做特化——编译会失败 - 若需原子操作自定义结构体，必须确保其内存布局平凡（
std::is_trivially_copyable_v为 true），且大小不超过平台最大原子操作宽度（通常 ≤ 16 字节，x86-64 下多数支持 ≤ 16B，但std::atomic<__m128>非标）
load/store 与 memory_order 的实际取舍
最常误用的是把所有操作都写成 memory_order_seq_cst（默认），它安全但可能拖慢性能；而过度使用 memory_order_relaxed 又容易引发重排 bug。关键看是否需要同步其他变量。
典型场景：
立即学习“C++免费学习笔记（深入）”；
- 计数器累加（无依赖其他状态）→
fetch_add(1, std::memory_order_relaxed)足够 - 标志位通知（如
ready_flag.store(true, std::memory_order_release)配合另一线程ready_flag.load(std::memory_order_acquire)）→ 构成 acquire-release 同步，保证此前所有写操作对另一线程可见 - 实现自旋锁或引用计数时，
compare_exchange_weak必须配合循环，且首次调用建议用memory_order_acquire（读），失败重试用memory_order_relaxed
std::atomicready{false}; // 线程 A data = 42; // 非原子写 ready.store(true, std::memory_order_release); // release：确保 data 写入不被重排到这之后 // 线程 B while (!ready.load(std::memory_order_acquire)) { / 自旋 / } // acquire：确保后续读 data 不被重排到这之前 std::cout << data << "\n"; // 此时能安全看到 42
compare_exchange_weak 和 compare_exchange_strong 的区别在哪
两者都尝试原子地比较并交换：若当前值等于期望值，则设为新值并返回 true；否则将当前值写回期望变量并返回 false。区别在于：weak 允许「伪失败」（spurious failure）——即使值匹配，也可能因底层 CAS 指令限制（如 x86 上 LOCK CMPXCHG8B 在某些旧 CPU 上的限制）而返回 false。
因此，weak 必须用在循环中；strong 无伪失败，但可能更慢（尤其在非 x86 平台）。绝大多数无锁数据结构（栈、队列节点插入）都用 weak + 循环。
- 单次尝试就足够？用
strong（例如初始化一次性的 flag） - 在循环里重试？优先选
weak，x86 下二者生成代码几乎一样，ARM 上weak更轻量 - 注意：期望值必须是左值（可被修改），因为失败时会写回当前值 —— 别传字面量或临时对象
std::atomiccounter{0}; int expected = 0; while (!counter.compare_exchange_weak(expected, 1, std::memory_order_acquire)) { // 若失败，expected 已被更新为当前值；继续循环即可 }
无锁编程中最容易被忽略的内存泄漏和 ABA 问题
无锁结构（如链表栈）删除节点时，不能直接 delete node —— 其他线程可能正处在 compare_exchange_weak 中间，还持有该节点指针。这就是经典的内存回收难题，需配合 Hazard Pointer 或 RCU 或 epoch-based reclamation。
ABA 问题更隐蔽：线程 A 读到指针 p == 0x1000，被抢占；线程 B 把该节点弹出、释放、又新建一个新节点恰好复用了 0x1000 地址；A 恢复后执行 CAS 成功，却误以为还是原来那个节点。
- 简单规避：用
std::atomic<:pair int>>包装指针+版本号（tagged pointer），每次修改指针时递增 tag（x86-64 下低 3 位通常未用，可作 tag） - 不要依赖
std::shared_ptr自动管理——其控制块本身不是无锁的，且load()不是原子的 -
标准库没提供通用无锁内存回收机制，
boost::lockfree内部用了 epoch-based，但生产环境仍建议优先评估是否真需要无锁，还是用std::mutex+ 细粒度锁更稳妥
真正难的从来不是写对一个 fetch_add，而是确认整个状态转换图在所有线程交错下仍保持不变量，以及——谁来安全回收那块内存。
