volatile不能用于多线程同步，因其仅禁止编译器优化，不提供原子性、内存屏障、cpu缓存一致性或标准内存模型保证；多线程场景应使用std::atomic、std::mutex等标准并发原语。
没用。在标准 C++ 多线程场景下，volatile 对线程同步、原子性、内存可见性或指令顺序控制都不提供保证。
为什么 volatile 不能用于多线程同步
volatile 只约束编译器：禁止寄存器缓存、禁止对它自身的读写做冗余消除或跨 volatile 指令重排。但它不生成任何 CPU 内存屏障，也不参与 C++ 标准内存模型（std::memory_order）。
- 多个线程同时执行
++shared_var（即使shared_var是volatile int），仍会因读-改-写非原子而丢失更新； - 一个线程写
volatile bool ready = true;，另一个线程读while (!ready)，可能永远看不到true——因为 CPU 缓存未刷新、StoreLoad 重排未被阻止； - MSVC 的
/volatile:ms扩展虽在 x86 上把volatile当作 acquire/release 使用，但这不是可移植行为，且在 ARM/Clang/GCC 下完全不生效。
什么情况下你会误以为 volatile “有用”
在单核、无优化、无 CPU 乱序、且恰好没触发竞态的简单测试里，volatile 可能“看起来”让变量变化被另一线程观察到。但这只是巧合，不是保证。
- 例如：x86 架构本身具有较强的内存顺序（如 StoreLoad 有隐式屏障），掩盖了
volatile的缺失； - 关闭编译器优化（
-O0）时，变量天然不进寄存器，volatile的效果被覆盖； - 用
std::this_thread::yield()或延时循环“帮”你刷缓存，让你误判是volatile起了作用。
该用什么替代 volatile 做线程通信
所有跨线程的共享状态，必须使用标准并发原语：
- 单个布尔标志或整数：用
std::atomic<bool></bool>或std::atomic<int></int>，默认memory_order_seq_cst安全； - 需要精细控制顺序：显式指定
std::memory_order_acquire/std::memory_order_release； - 涉及复杂状态或临界区：配合
std::mutex或std::shared_mutex； - 信号量、条件变量等高级同步：用
std::condition_variable或std::counting_semaphore（C++20）。
真正需要 volatile 的地方，只在编译器“看不见”的外部修改场景：硬件寄存器映射、setjmp/longjmp 跨越点、信号处理函数里修改的 sig_atomic_t 变量。多线程不是它的设计目标，强行混用只会埋下不可复现的 bug。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
