std::atomic仅保证单变量单操作的硬件级原子性，是否无锁需用is_lock_free()运行时判断；它不解决多变量一致性，跨变量逻辑需acquire/release同步，非事务性。
std::atomic 本身不“保证无锁”，它只保证单次操作原子性；是否真正无锁，取决于 is_lock_free() 返回值和目标平台支持。
std::atomic 的原子性靠硬件指令实现，不是靠锁
std::atomic 对象的读、写或读-改-写（如 fetch_add）在底层映射为 CPU 提供的原子指令：x86 上是带 lock 前缀的指令（如 lock xadd），ARM 上是 ldxr/stxr 指令对。这些指令由硬件保障执行不可中断——不是靠互斥锁排队，而是靠缓存一致性协议（如 MESI）或总线锁定机制完成同步。
这意味着：
- 没有线程阻塞、没有上下文切换开销
- 没有死锁风险
- 但也不等于“所有场景都快”：高争用下自旋等待仍会消耗 CPU
判断是不是真无锁：必须查 is_lock_free()
某些类型（尤其是结构体或大整数）在特定平台上可能 fallback 到内部互斥锁实现——这时它仍是线程安全的，但已不是“无锁”。
立即学习“C++免费学习笔记（深入）”；
正确做法是运行时检查：
std::atomic<long long> x;
if (!x.is_lock_free()) {
// 可能用了内部 mutex，慎用于高频路径
}
常见可靠无锁类型包括：std::atomic<int>、std::atomic<void*>、std::atomic_flag（唯一保证 lock-free 的类型）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
memory_order 不影响原子性，但决定可见性边界
load()、store()、fetch_add() 等操作默认使用 std::memory_order_seq_cst，提供最强顺序保证，但性能开销最大。若只关心单变量计数，std::memory_order_relaxed 就够用：
counter.fetch_add(1, std::memory_order_relaxed);
但注意：
-
relaxed下，编译器和 CPU 都可能重排该操作前后的内存访问 - 跨变量逻辑（如“先更新 A 再设 flag 为 true”）必须搭配
acquire/release才能建立 happens-before 关系 - 误用宽松序不会导致数据损坏，但会导致其他线程看到不一致的业务状态
atomic 不解决多变量一致性问题
哪怕你把十个字段全换成 std::atomic<int>，它们之间也没有事务性保证。比如两个线程分别执行：
a.store(1); b.store(2); // 线程1 a.store(3); b.store(4); // 线程2
另一个线程可能观察到 a==1 且 b==4 这种混合状态——这完全合法，因为 atomic 只管自己那一个变量。
这类场景必须回归 std::mutex 或手动设计无锁结构（如用 CAS 包裹整个状态结构体），不能靠堆砌 atomic 蒙混过关。
最容易被忽略的一点：atomic 是工具，不是银弹；它的能力边界非常清晰——单变量、单操作、硬件级原子。越出这个范围，就得靠更高层的同步逻辑来兜底。
