volatile 告诉编译器变量值可能被程序外因素改变，禁止对其读写优化；主要用于内存映射I/O、信号处理全局变量、裸机多线程轮询三类场景，不保证原子性与内存序，不可替代 std::atomic。
volatile 告诉编译器：这个变量的值可能在**程序控制之外被改变**，别擅自优化对它的读写操作。
它主要解决三类底层问题
不是用来同步线程（那是 std::atomic 的事），而是应对以下真实硬件或系统级场景：
- 内存映射 I/O 寄存器：比如嵌入式中，向某个地址写 1 表示“启动电机”，写 0 表示“停止”。如果编译器把连续两次写 0 优化成一次，设备就收不到第二次指令，行为出错。
- 信号处理函数修改的全局变量：例如 SIGALRM 信号处理函数里给 flag = 1，主循环靠轮询这个 flag 退出。若编译器发现主循环里没改 flag，可能直接把它缓存在寄存器、永不重新从内存读——结果永远等不到信号。
- 多线程中非原子、无同步的共享变量（不推荐，仅作理解）：虽然 C++11 后应优先用 std::atomic，但早期代码或某些受限环境（如裸机）会用 volatile 防止编译器把 while(!done) 优化为空循环。
volatile 怎么影响编译器行为
它强制每次访问都走真实内存路径：
- 读操作：禁止缓存到寄存器，每次必须从内存（或对应地址）重新加载；
- 写操作：禁止合并、删除、重排（在单线程内），每次赋值都生成实际的 store 指令；
- 不保证 CPU 指令重排（这是 memory barrier / atomic 的职责），也不提供原子性（比如 volatile int i; i++ 仍不是原子操作）。
常见误区
- volatile ≠ 线程安全：两个线程同时读写 volatile 变量，仍可能因缺少原子性和内存序导致数据竞争（UB）；
- volatile 不阻止 CPU 硬件重排：它只约束编译器，CPU 仍可能乱序执行访存指令；
-
不要用它替代 atomic：C++11 起，跨线程通信请用 std::atomic
，它既禁编译器优化，也带内存序语义和原子操作。
一个典型例子（信号 + volatile）
下面代码中，sig_received 必须是 volatile，否则优化后可能永远不检查内存中的新值：
立即学习“C++免费学习笔记（深入）”；
volatile sig_atomic_t sig_received = 0;void signal_handler(int) { sig_received = 1; }
int main() { signal(SIGINT, signal_handler); while (!sig_received) { / 等待 Ctrl+C / } printf("Got signal!\n"); }
这里用 sig_atomic_t（本身已隐含 volatile 语义）更标准，但原理一致：让编译器不敢跳过每次判断。
