std::atomic 不保证无锁，需运行时调用 is_lock_free() 验证；内存序仅约束重排而非执行顺序；aba 问题与内存回收是无锁编程核心难点；x86 强序易掩盖错误，arm 等弱序平台必须显式使用 acquire/release 并核对汇编。
std::atomic 本身不保证无锁，先查 is_lock_free()
很多人以为 std::atomic 天然无锁，其实它只是“可能无锁”。是否真正无锁，取决于类型大小、平台 ABI 和编译器实现。比如 std::atomic<int></int> 在 x86-64 上通常是无锁的，但 std::atomic<:shared_ptr>></:shared_ptr> 很可能退化为内部加锁。
必须运行时验证：
std::atomic<long long> x;
if (x.is_lock_free()) {
// 可安全用于无锁数据结构
} else {
// 可能触发 mutex，高并发下性能骤降
}
常见陷阱：在 ARM 或某些嵌入式平台，std::atomic<int64_t></int64_t> 可能不是 lock-free（尤其未开启 -march=armv8.1-a+lse 时），导致意外阻塞。
内存序不是“同步开关”，而是对重排的约束声明
std::memory_order 不控制 CPU 是否执行某条指令，只告诉编译器和 CPU：“这条原子操作前/后的普通访存，允许怎么重排”。错误理解会导致 data race 或逻辑失效。
立即学习“C++免费学习笔记（深入）”；
-
std::memory_order_relaxed：仅保证原子性，不约束重排。适合计数器、句柄生成等无需同步语义的场景 -
std::memory_order_acquire：该读操作之后的**所有**普通读写不能被重排到它前面（防止“读后乱序”） -
std::memory_order_release：该写操作之前的**所有**普通读写不能被重排到它后面（防止“写前乱序”） -
std::memory_order_acq_rel：同时具备 acquire + release，适用于 read-modify-write（如fetch_add）
典型误用：store(x, relaxed) + load(y, acquire) 无法建立 happens-before —— acquire 的同步对象必须是同一个原子变量的 release store。
无锁编程真正的难点不在原子操作，而在 ABA 与内存回收
即使所有操作都用 compare_exchange_weak + acq_rel，仍可能因 ABA 问题崩溃。例如：线程 A 读到指针 p，被抢占；线程 B 将 *p 释放、再分配同一地址给新对象；线程 A 恢复并成功 CAS，却误认为状态未变。
解决 ABA 不能靠加锁，而需版本号或 hazard pointer 等机制：
struct Node {
int data;
std::atomic<uintptr_t> next_with_tag; // 低 2 位存 tag，防 ABA
};
更隐蔽的问题是内存回收：无锁结构中节点被“逻辑删除”后，不能立即 delete，否则其他线程可能正 dereference 它。需要 epoch-based reclamation 或 RCU 等延迟回收方案 —— 这部分完全不在 std::atomic 职责范围内。
x86 和 ARM 的内存序差异会直接暴露逻辑漏洞
x86 的强内存模型掩盖了很多错误：即使全用 relaxed，多数无锁代码也能“碰巧”跑通。但换到 ARM/AArch64，store 和 load 可能跨多个 cycle 乱序，relaxed 就极易出错。
关键点：
- x86 隐含
lfence/sfence效果，acquire/release常编译为空指令 - ARM 需显式
ldar/stlr指令，relaxed可能生成无 barrier 的ldr/str - Clang/GCC 在不同 target 下对同一内存序生成的指令完全不同，必须用
objdump -d实际核对
跨平台无锁代码必须显式使用 acquire/release（而非依赖 x86 强序），且在 ARM 上务必检查汇编输出 —— 光靠测试通过没用，硬件行为才是最终裁判。
