Volatile告诉编译器不要优化与Volatile变量有关的任何东西。

至少有三个常见的原因使用它，所有的情况下，变量的值可以改变，而不需要从可见代码的操作:

当您与改变值本身的硬件进行交互时 当另一个线程运行时也使用了该变量 当有一个可能改变变量值的信号处理程序时。

假设你有一小块硬件被映射到RAM的某个地方，它有两个地址:一个命令端口和一个数据端口:

typedef struct
{
  int command;
  int data;
  int isBusy;
} MyHardwareGadget;

现在你想要发送一些命令:

void SendCommand (MyHardwareGadget * gadget, int command, int data)
{
  // wait while the gadget is busy:
  while (gadget->isbusy)
  {
    // do nothing here.
  }
  // set data first:
  gadget->data    = data;
  // writing the command starts the action:
  gadget->command = command;
}

看起来很简单，但可能会失败，因为编译器可以随意更改数据和命令的写入顺序。这将导致我们的小工具使用之前的数据值发出命令。还可以看看busy循环中的wait。这个会被优化掉。编译器会尽量聪明，只读取一次isBusy的值，然后进入一个无限循环。这不是你想要的。

解决这个问题的方法是将指针gadget声明为volatile。这样编译器就会被强制执行你所写的内容。它不能删除内存赋值，不能在寄存器中缓存变量，也不能改变赋值的顺序

这是正确的版本:

void SendCommand (volatile MyHardwareGadget * gadget, int command, int data)
{
  // wait while the gadget is busy:
  while (gadget->isBusy)
  {
    // do nothing here.
  }
  // set data first:
  gadget->data    = data;
  // writing the command starts the action:
  gadget->command = command;
}

我会提到另一个挥发物很重要的场景。

假设您为更快的I/O对文件进行内存映射，并且该文件可以在幕后更改(例如，该文件不在您的本地硬盘驱动器上，而是通过网络由另一台计算机提供)。

如果您通过指向非易失性对象的指针(在源代码级别)访问内存映射文件的数据，那么编译器生成的代码可以多次获取相同的数据，而您却不知道它。

如果该数据碰巧发生了变化，您的程序可能会使用两个或多个不同版本的数据，并进入不一致的状态。如果程序处理不受信任的文件或来自不受信任位置的文件，这不仅会导致程序的逻辑不正确行为，而且还会导致可利用的安全漏洞。

如果您关心安全性，这是一个需要考虑的重要场景。

正如这里许多人正确地建议的那样，volatile关键字的流行用途是跳过volatile变量的优化。

在阅读了volatile之后，我想到的最好的优点是——在longjmp的情况下防止回滚变量。非本地跳转。

这是什么意思?

它只是意味着在你进行堆栈展开后，最后一个值将被保留，以返回到前一个堆栈帧;通常是在一些错误的情况下。

因为它超出了这个问题的范围，所以我不打算在这里详细讨论setjmp/longjmp，但是值得一读;以及如何使用波动特征来保留最后的价值。

Volatile告诉编译器你的变量可以通过其他方式被改变，而不是通过访问它的代码。例如，它可能是一个I/ o映射的内存位置。如果在这种情况下没有指定这一点，一些变量访问可以被优化，例如，它的内容可以保存在寄存器中，并且内存位置不会再次读入。

参见Andrei Alexandrescu的文章，“volatile——多线程程序员最好的朋友”

The volatile keyword was devised to prevent compiler optimizations that might render code incorrect in the presence of certain asynchronous events. For example, if you declare a primitive variable as volatile, the compiler is not permitted to cache it in a register -- a common optimization that would be disastrous if that variable were shared among multiple threads. So the general rule is, if you have variables of primitive type that must be shared among multiple threads, declare those variables volatile. But you can actually do a lot more with this keyword: you can use it to catch code that is not thread safe, and you can do so at compile time. This article shows how it is done; the solution involves a simple smart pointer that also makes it easy to serialize critical sections of code.

本文适用于C和c++。

参见Scott Meyers和Andrei Alexandrescu的文章“c++和双重检查锁定的危险”:

So when dealing with some memory locations (e.g. memory mapped ports or memory referenced by ISRs [ Interrupt Service Routines ] ), some optimizations must be suspended. volatile exists for specifying special treatment for such locations, specifically: (1) the content of a volatile variable is "unstable" (can change by means unknown to the compiler), (2) all writes to volatile data are "observable" so they must be executed religiously, and (3) all operations on volatile data are executed in the sequence in which they appear in the source code. The first two rules ensure proper reading and writing. The last one allows implementation of I/O protocols that mix input and output. This is informally what C and C++'s volatile guarantees.

维基上有关于volatile的所有信息:

Volatile(计算机编程)

Linux内核的文档也对volatile做了一个很好的标记:

为什么不应该使用“volatile”类型类