std::atomic不能直接替代锁，因其仅保证单个操作原子性，无法确保多操作组合（如读-改-写、条件判断+赋值）的整体原子性；需用CAS循环、mutex或事务设计来保障逻辑一致性。
std::atomic 为什么不能直接替代锁
因为 std::atomic 只保证单个操作的原子性，不保证多个原子操作之间的整体原子性。比如「读-改-写」序列（如自增）看似简单，但若中间被其他线程插入修改，结果就错。
常见错误现象：i++ 对 std::atomic<int></int> 是安全的，但 if (a.load() == 1) b.store(2); 这种判断+赋值组合不是原子的，可能引发竞态。
- 用
compare_exchange_weak或compare_exchange_strong手动实现 CAS 循环，才能真正完成条件更新 - 涉及多个变量、或需保持逻辑一致性（如“账户A扣款且账户B加款”）时，必须用
std::mutex或事务式设计 -
std::atomic_flag是唯一无锁且保证 lock-free 的类型；其他std::atomic<t></t>在某些平台/类型上可能回退为内部加锁（可用is_lock_free()检查）
memory_order 参数选错会导致什么
选错 memory_order 不会编译报错，但可能让程序在优化后行为突变——尤其在弱序架构（ARM、PowerPC）上，x86 因强序掩盖很多问题，容易误判正确性。
使用场景：高频计数器可接受 memory_order_relaxed；引用计数释放需 memory_order_acquire/memory_order_release 配对；同步临界区入口通常用 memory_order_acquire，出口用 memory_order_release。
立即学习“C++免费学习笔记（深入）”；
-
memory_order_seq_cst最安全也最重，是默认选项，但可能阻止编译器和 CPU 的合理重排，影响性能 -
memory_order_acquire不保证之前所有内存操作都已完成，只约束其后的读操作不被提前 - 用
memory_order_consume极其危险：目前主流编译器（GCC/Clang）基本不提供可靠数据依赖跟踪，实际等价于acquire，不建议使用
volatile 能不能防止编译器乱序或保证线程同步
不能。volatile 只告诉编译器“这个变量可能被外部改变”，禁止对该变量的读写被优化掉或合并，但完全不参与 C++ 内存模型，不生成任何内存屏障，也不影响其他变量的访问顺序。
常见错误现象：用 volatile bool ready 做线程间通知，主线程写 ready = true，子线程 while(!ready); —— 这在 C++ 标准下是未定义行为，编译器可能把 ready 优化进寄存器，导致死循环。
- 跨线程通信必须用
std::atomic（哪怕只是std::atomic<bool></bool>） -
volatile仅适用于内存映射 I/O、信号处理中的全局标志等极少数场景 - 即使加上
volatile，也不影响std::atomic的 memory_order 语义，二者混用无意义
std::memory_order_acquire 和 std::memory_order_release 怎么配对生效
它们本身不“配对”，生效依赖于同一个 std::atomic 对象上的操作：一个线程用 release 写，另一个线程用 acquire 读该变量，才能建立 synchronizes-with 关系，从而让 release 前的所有写对 acquire 后的读可见。
示例中常被忽略的关键点：两个线程必须操作同一个原子变量；不能用不同变量模拟（如 A 线程写 flag + data，B 线程读 flag 就认为 data 已就绪——这只有在 flag 用 release、data 访问受其约束时才成立）。
- 如果 B 线程用
relaxed读flag，则无法获得任何同步保证 - 多个 release 写之间没有顺序约束，多个 acquire 读之间也不构成传递同步
- store-release 和 load-acquire 的组合是最轻量的同步原语，适合做“发布-订阅”模式（如初始化完成通知）
