非原子bool标志位在多线程中必然导致可见性与顺序问题，因其无原子性、不保证缓存一致性、缺乏内存序约束；必须使用std::atomic并显式指定匹配的memory_order（如release/acquire）才能正确同步。
非原子标志位在多线程中无法保证可见性与顺序，**几乎必然导致逻辑错乱或无限等待**——这不是“可能出问题”，而是只要编译器优化或 CPU 缓存介入，bug 就会稳定复现。
为什么 bool flag = false 不能当线程间开关用
看似简单的布尔变量，在多线程下读写完全不可靠。编译器可能把它缓存在寄存器里，CPU 可能把它留在本地缓存中，另一个线程的写入永远不会被看到。
- 主线程设
flag = true，工作线程仍在循环读while (!flag)，永远不退出 - 即使加了
volatile，它只禁用编译器重排，**不解决 CPU 缓存一致性，也不提供内存序约束** - 该变量没有原子性：读和写本身虽小，但“写完立刻对其他线程可见”这件事，
bool根本不承诺
std::atomic<bool></bool> 必须显式指定内存序
直接声明 std::atomic<bool> flag{false}</bool> 并不够——默认构造使用 memory_order_seq_cst，性能高开销，且容易掩盖逻辑缺陷。你得按语义选。
- 仅作“通知完成”用途（如启动后置标志）：
flag.store(true, std::memory_order_release)+flag.load(std::memory_order_acquire) - 纯轮询状态（无同步依赖）：
flag.load(std::memory_order_relaxed)可接受，但必须确认后续逻辑不依赖该读取的顺序 - 避免混用：
store(relaxed)和load(acquire)不构成同步关系，不会建立 synchronizes-with
典型错误模式：用 load() 但没配对 store(release)
这是最隐蔽的坑：代码能跑通、结果偶尔正确，但一上多核 ARM 或开启 LTO 编译就崩。因为 load() 默认是 seq_cst，而 store() 若没显式指定，也是 seq_cst ——表面安全，实则浪费性能；若你悄悄改成 store(relaxed)，同步就断了。
- 错误写法：
flag.store(true);（隐式seq_cst） +while (!flag.load()) { ... }（隐式seq_cst）→ 过度同步 - 更错写法：
flag.store(true, std::memory_order_relaxed);+while (!flag.load()) { ... }→ 同步失效，工作线程可能永远看不到 true - 正确写法（推荐）：
flag.store(true, std::memory_order_release);+while (!flag.load(std::memory_order_acquire)) { ... }
真正难调试的不是“程序崩溃”，而是“逻辑跳过”或“条件永远不满足”——这种 bug 往往只在特定负载、特定 CPU 架构、特定编译器版本下暴露，且无法用常规断点复现。务必把所有跨线程通信的变量，从声明开始就定死内存序语义。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
