不能直接替换。std::atomic仅保证单变量读写原子性，复合操作如counter++或条件更新需显式调用原子函数；未初始化、内存序误用、多字段逻辑一致性等场景仍会出错。
竞态条件出现时，std::atomic 能不能直接替换普通变量？
不能直接替换。把 int counter; 换成 std::atomic<int> counter;</int> 只是第一步，真正出问题的往往是复合操作——比如“读-改-写”（counter++）或条件判断后更新（if (flag) do_something(); flag = false;）。这些操作在 std::atomic 上不是原子的，除非你显式调用原子成员函数。
-
counter++看似简单，实际等价于counter.fetch_add(1, std::memory_order_seq_cst)，但如果你写的是counter = counter + 1，那就退化成非原子的读+计算+写三步，完全失效 - 布尔标志位别只依赖
load()和store()，该用exchange()或compare_exchange_weak()的地方硬上load()/store()会漏掉窗口期 -
std::atomic<bool></bool>默认构造是未初始化的，不等于false；必须显式初始化，比如std::atomic<bool> ready{false};</bool>
什么时候必须用 compare_exchange_weak 而不是 load+store？
当你需要“检查某个状态满足条件才更新”，且不能容忍检查和更新之间被其他线程插队时——典型场景是无锁栈 push/pop、引用计数递减、一次性初始化（double-checked locking 的安全替代）。
- 错误写法：
if (ptr.load() == nullptr) ptr.store(new_obj);—— 中间可能有别的线程也判空并 new，导致内存泄漏或重复初始化 - 正确写法：
T* expected = nullptr; while (!ptr.compare_exchange_weak(expected, new_obj)) { if (expected != nullptr) break; } -
compare_exchange_weak可能伪失败（spuriously fail），所以必须放在循环里；strong版本不循环也行，但 x86 上没区别，ARM 上性能略差 - 注意
expected是引用参数，失败时会被自动更新为当前真实值，别传临时量或字面量
std::memory_order 选错会导致什么具体现象？
不是崩得明显，而是偶发、难复现、换编译器/平台就变样——比如在 GCC + x86 上跑得好好的，一上 ARM 或 Clang 就卡死/数据错乱。
- 用
std::memory_order_relaxed做计数器累加？没问题；但若用来同步两个线程间的“准备就绪”信号（如生产者写完数据后设ready = true），消费者可能看到ready == true却读到未初始化的数据（编译器/CPU 重排） - 跨线程传递指针，发布端用
store(ptr, mo_release)，消费端用load(mo_acquire)—— 这对组合才能保证 release 前的所有写入对 acquire 后的读可见 -
mo_seq_cst最安全，默认选项，但某些高频场景（如无锁队列头尾指针）用它会拖慢 10%~20% 性能；别为了“省事”全用它，也别为了“快”全用relaxed
原子变量不能解决所有线程安全问题，哪些情况它压根不适用？
std::atomic 只保单个对象的读写原子性，管不了多字段逻辑一致性、资源生命周期、或需要阻塞等待的协作。
立即学习“C++免费学习笔记（深入）”；
- 结构体字段分散更新：比如
struct Config { int timeout; bool enabled; };，即使每个字段都是atomic，也无法保证“timeout 更新同时 enabled 也生效”这种业务语义 - 动态内存管理：原子指针可以安全交换，但 delete 谁来负责？多个线程都可能拿到旧指针并 delete，得配合引用计数（
std::shared_ptr）或 hazard pointer - 等待条件满足：想等
queue.size() > 0，别用原子 int 循环 load——CPU 白耗电，该用std::condition_variable配合 mutex - IO 或系统调用（如
read(),write()）本身不保证线程安全，原子变量插不上手
最常被忽略的一点：原子变量不能替代设计。一个函数内部用了一堆 fetch_add 和 compare_exchange，但逻辑分支交错、状态流转混乱，再原子也救不回可维护性。先理清状态机，再决定哪里需要原子操作。
