如果要在 C++ 中评选一个"被误解最深"的关键字，`volatile` 大概率会高票当选。它的名字暗示着"易变的"，许多开发者因此直觉地认为它能在多线程环境中保证变量的"可见性"------就像 Java 中的 `volatile` 那样。这个直觉在 Java 中大致成立，但在 C++ 中，它会导致完全错误的代码和难以复现的未定义行为。
这篇文章试图做一件事：把 `volatile` 放回它原本的位置，说清楚它做什么、不做什么，以及为什么"不做什么"那部分才是理解它的关键。
一、volatile 到底保证了什么
`volatile` 是 C++ 中的一个 cv 限定符（与 `const` 并列）。它的核心语义可以用一句话概括：对被 `volatile` 限定对象的每一次访问，都是一次"可观察的副作用"，编译器不能将其优化掉，也不能在单线程执行顺序中随意移动它。
具体来说，标准要求：通过 `volatile` 左值进行的每一次读或写，在"as-if"规则下都被视为可见的副作用；在同一个线程内，`volatile` 访问不能被消除，也不能与在它之前或之后排序的其他可见副作用重新排列。
这意味着编译器不会做下面这些事：
cpp
volatile int flag;
// 编译器不会把循环内的 flag 读取提到循环外，
// 因为每次读取都是一次独立的可观察访问
while (!flag) {
// 等待外部修改 flag
}如果没有 `volatile`，一个激进的优化器完全可以把 `flag` 读入寄存器，然后变成一个死循环------因为在单线程视角下，循环体内没有任何代码修改 `flag`，重复读取"看起来"是多余的。`volatile` 阻止的正是这种"看起来多余"的优化。
但请注意上面反复出现的限定词："单线程执行顺序中"，"可观察的副作用"。`volatile` 的保证范围到此为止。越过这条线，就是误解的开始。
二、最大的误解：volatile 不是线程同步
这是 C++ `volatile` 与 Java `volatile` 最根本的分野。
Java 的 `volatile` 是一条语言级别的线程同步原语：它保证一个线程对 `volatile` 变量的写入对随后读取该变量的其他线程可见，并且禁止相关的指令重排序。换句话说，Java 的 `volatile` 在语言层面建立了 happens-before 关系。
C++ 的 `volatile` 不提供任何跨线程的同步保证。具体来说：
**不保证原子性。 对一个 `volatile int` 的 `++` 操作仍然是读-改-写三步，不是原子操作。两个线程同时执行 `volatile_int++` 依然构成数据竞争。
不建立 happens-before 关系。C++ 标准明确规定，`volatile` 访问适合与信号处理函数通信，但不适合与另一个线程通信。`volatile` 读并不与另一个线程的 `volatile` 写建立同步，因此也无法保证一个线程对普通变量的写入在另一个线程中可见。
不阻止硬件层面的重排序。`volatile` 本质上是对编译器的约束，而不是对 CPU的约束。现代多核处理器会在硬件层面重排加载和存储，`volatile` 不会生成任何内存屏障指令来阻止这一点。
自 C++11 起，内存模型被正式纳入标准。在 C++11 及之后的标准下，一个线程写入、另一个线程并发读取同一个非原子对象，无论它是否被声明为 `volatile`，都是数据竞争，程序行为未定义。`volatile` 不能把这种未定义行为变为已定义行为；`std::atomic` 才是标准提供的唯一符合规范的跨线程通信工具。
用一个类比来理解：`volatile` 像一个坚持每次都亲自去信箱取信的人，而不是依赖记忆中的上次内容。但如果两个人在不同的房间里同时写信并投递，`volatile` 并不能保证他们看到的是同一封信，也不能保证他们不会同时涂改同一张纸。它解决的是"不要凭记忆猜测"，而不是"如何协调多个写信人"。
三、volatile 的合法领地：与"程序之外的力量"通信
那么 `volatile` 到底该用在哪里？答案在于它最初被设计出来的场景：与编译器无法感知的外部力量进行交互。
场景一：内存映射 I/O
在嵌入式系统中，硬件寄存器被映射到特定的内存地址。读取一个状态寄存器可能会清除中断标志；写入一个数据寄存器会触发实际的硬件动作。这些"内存访问"的效果不来自 C++ 代码本身，而来自硬件。
cpp
// 模拟一个硬件状态寄存器
volatile uint32_t* const STATUS_REG =
reinterpret_cast<volatile uint32_t*>(0x40000000);
// 必须实际执行读取，不能因为"值没变"而被优化掉
while ((*STATUS_REG & READY_BIT) == 0) {
// 等待硬件就绪
}这里的 `volatile` 告诉编译器：每次 `*STATUS_REG` 的读取都可能返回不同的值，因为硬件可能随时改变它。没有 `volatile`，编译器可能认为循环条件不变，生成一个死循环或直接删除循环。
场景二：信号处理函数
C++ 标准特别指出，`volatile` 对象适合与信号处理函数通信。因为信号处理函数的调用是异步的，编译器无法从普通控制流中推断出变量会在何时被修改。标准的惯用法是使用 `volatile sig_atomic_t`：
cpp
#include <csignal>
volatile sig_atomic_t g_interrupted = 0;
extern "C" void handler(int) {
g_interrupted = 1; // 在信号处理函数中设置标志
}
int main() {
std::signal(SIGINT, handler);
while (!g_interrupted) {
// 主循环
}
}`sig_atomic_t` 保证了对该类型的读写是原子的（不会在读取中途被信号打断），而 `volatile` 保证编译器每次都会真正去检查 `g_interrupted` 的值，而不是把它缓存在寄存器中。
场景三：setjmp / longjmp
如果一个在 `setjmp` 和 `longjmp` 之间被修改的自动变量可能被 `longjmp` 恢复，它应当声明为 `volatile`，否则其值在 `longjmp` 之后是不确定的。这是 C 时代遗留下来的规则，在现代 C++ 中很少使用。
四、C++20 的变化：对"部分 volatile"的否定
C++20 采纳了提案 P1152R4，弃用了 `volatile` 的一批用法。被弃用的主要包括：
-
对 `volatile` 标量类型使用复合赋值运算符（如 `+=`、`-=`）；
-
对 `volatile` 标量类型使用 `++` 和 `--`；
-
`volatile` 赋值链式操作；
-
将 `volatile` 限定类型用作函数参数类型或返回类型；
-
在结构化绑定声明中使用 `volatile` 限定符。
这些弃用的共同逻辑是：它们把"读"和"写"捆绑在了一个表达式里，容易让人误以为这是一个原子操作，而实际上它是两次独立的 `volatile` 访问。对于硬件寄存器，`reg |= mask` 这样的写法在语义上尤其危险------它可能读到一个中间状态，或者写入一个并非预期的值。C++20 的选择是：与其让开发者写出看似简洁实则脆弱的多步 `volatile` 操作，不如在编译期就标记出来，促使代码显式地拆分成独立的读和写。
一个值得注意的后续是，标准委员会后来对弃用的范围有所回调，承认在嵌入式等场景中某些用法仍然必要。但核心信息没有改变：`volatile` 的复合操作语义是可疑的，应当谨慎对待。
五、与 Java volatile 的对照
把两者的差异集中列出，可以更清楚地看到 C++ `volatile` 的边界：
| 维度 | C++ volatile |
Java volatile |
|---|---|---|
| 主要目的 | 阻止编译器优化掉对"可能被外部修改"的内存的访问 | 提供线程间的可见性与有序性保证 |
| 原子性 | 不保证 | 对基本类型的读写保证原子性（long/double 除外，但 volatile 弥补了这一点） |
| happens-before | 不建立 | 建立 |
| 内存屏障 | 通常不生成 CPU 屏障 | 生成内存屏障（语义上） |
| 适用场景 | MMIO、信号处理、setjmp/longjmp |
线程间状态标志、安全发布 |
| 误用于多线程的后果 | 数据竞争，未定义行为 | 在使用正确的前提下可工作 |
一句话概括：Java 的 volatile 是并发工具；C++ 的 volatile 是编译器优化屏障。
如果你需要 Java `volatile` 那样的语义，在 C++ 中应当使用 `std::atomic`，通常配合默认的 `memory_order_seq_cst`，或者根据需要在 `acquire`/`release` 之间选择更弱但足够的顺序。
六、实践准则
基于以上讨论，可以提炼出几条清晰的准则：
准则一：不要用 `volatile` 做线程同步。线程间共享的可变状态应当使用 `std::atomic`、互斥锁或条件变量。这是 C++11 之后标准给出的明确方向，没有任何例外。
准则二：`volatile` 用于"程序控制之外会被修改"的内存。 典型场景只有 MMIO、信号处理函数中的 `sig_atomic_t` 标志，以及极少数需要强制实际内存访问的底层代码。如果你的代码不属于这些场景，`volatile` 大概率是不必要的。
准则三：区分"编译器屏障"和"硬件屏障"。 `volatile` 管的是编译器不要优化掉访问；它不管 CPU 是否会把存储重排到加载之后。如果你需要阻止硬件重排序，需要的是 `std::atomic` 的适当内存序或显式的屏障指令，而不是 `volatile`。
准则四：`const volatile` 是有意义的组合。它表示"程序不能修改这个对象，但外部力量可以修改，且每次读取都必须实际发生"。MMIO 的只读状态寄存器是典型例子：软件侧只读，但硬件随时可能改变其值。
`volatile` 的历史包袱很大程度上来自一个时代错位：它诞生于 C 语言，被用来表达一种非常底层的、与硬件和异步信号打交道的意图；后来 Java 借用了这个名字，却赋予了它一套完全不同的、面向线程同步的语义。当熟悉 Java 的开发者带着 `volatile` 的直觉进入 C++ 时，冲突就不可避免地发生了。
理解 C++ `volatile` 的关键，不在于记住它能做什么，而在于记住它不做什么。它不保证原子性，不建立 happens-before，不阻止硬件重排，不是线程同步工具。它只是一个严格的编译器提示：这一次访问是真实的，不要假装它不存在。把 `volatile` 留给硬件和信号，把线程同步交给 `std::atomic`，这是现代 C++ 给出的清晰分工。