volatile不能解决多线程可见性问题，它仅禁止编译器重排和缓存优化，不提供原子性、内存序、CPU指令重排控制或cache coherency同步；C++11起volatile对多线程同步无效，应改用std::atomic。
为什么 volatile 不能解决多线程可见性问题
直接加 volatile 是常见误解。它只阻止编译器对单个变量的读写重排和缓存优化，但不提供原子性、不建立内存序、不阻止 CPU 指令重排，更不触发 cache coherency 协议同步。在 C++11 及以后，volatile 对多线程同步完全无效——标准明确将其排除在数据竞争定义之外。
该用 std::atomic 替换裸变量
所有在线程间共享、可能被并发读写的标量变量（如 int、bool、指针），必须声明为 std::atomic 类型：
std::atomic<bool> stop_requested{false};
std::atomic<int> counter{0};
std::atomic<MyStruct*> ptr{nullptr}; // 注意：仅当 MyStruct 是 trivially copyable 且 sizeof <= 寄存器宽度时才保证 lock-free
- 默认构造即初始化，无需额外
.store() - 读写操作自动带
memory_order_seq_cst语义（最严格，适合绝大多数场景） - 若需性能调优，可显式指定内存序，如
.load(std::memory_order_acquire)，但需理解其同步边界 - 避免对
std::atomic变量取地址后传给非原子函数（如&counter→memcpy），会绕过原子保障
检查编译器是否真的生成了原子指令
光写 std::atomic 不够，得确认底层没退化为锁实现（尤其对大对象或非对齐访问）：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
counter.is_lock_free()运行时判断（返回true表示无锁） - 查看汇编输出：
gcc -S -O2后搜lock xadd（x86）或ldaxr/stlxr（ARM）等原子指令 - Clang/GCC 对
std::atomic<int>默认生成无锁指令；但std::atomic<std::string>必然用锁，不可用于高频无锁场景
别漏掉隐式共享的变量和优化陷阱
容易被忽略的是：即使用了 std::atomic，若配套逻辑仍依赖未保护的普通变量，优化仍会出错：
立即学习“C++免费学习笔记（深入）”；
- 错误示例：
while (!stop_requested.load()) { do_work(); } int result = non_atomic_counter; // 编译器可能把这句提到 while 外！ - 正确做法：把所有跨线程依赖的读写都纳入原子操作或明确内存序约束，必要时用
std::atomic_thread_fence - 调试技巧：开启
-O2 -fsanitize=thread（TSan），它能捕获绝大多数因遗漏原子性导致的数据竞争
真正关键的不是“加什么关键字”，而是厘清哪些状态需要跨线程同步、它们之间的依赖关系，再选择匹配的原子操作和内存序。否则，volatile 或 std::atomic 都只是贴错了标签的创可贴。
