volatile变量可以从编译代码的外部进行更改(例如，程序可以将volatile变量映射到内存映射寄存器)。编译器不会对处理易失性变量的代码应用某些优化——例如，它不会在不将其写入内存的情况下将其加载到寄存器。这在处理硬件寄存器时很重要。

volatile变量可以从编译代码的外部进行更改(例如，程序可以将volatile变量映射到内存映射寄存器)。编译器不会对处理易失性变量的代码应用某些优化——例如，它不会在不将其写入内存的情况下将其加载到寄存器。这在处理硬件寄存器时很重要。

Volatile也很有用，当你想强制编译器不优化特定的代码序列时(例如编写一个微基准测试)。

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;
}

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

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

这是什么意思?

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

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

在Dennis Ritchie设计的语言中，除了地址未被获取的自动对象外，对任何对象的每次访问都表现为计算对象的地址，然后在该地址上读写存储。这使得该语言非常强大，但严重限制了优化机会。

While it might have been possible to add a qualifier that would invite a compiler to assume that a particular object wouldn't be changed in weird ways, such an assumption would be appropriate for the vast majority of objects in C programs, and it would have been impractical to add a qualifier to all the objects for which such assumption would be appropriate. On the other hand, some programs need to use some objects for which such an assumption would not hold. To resolve this issue, the Standard says that compilers may assume that objects which are not declared volatile will not have their value observed or changed in ways that are outside the compiler's control, or would be outside a reasonable compiler's understanding.

Because various platforms may have different ways in which objects could be observed or modified outside a compiler's control, it is appropriate that quality compilers for those platforms should differ in their exact handling of volatile semantics. Unfortunately, because the Standard failed to suggest that quality compilers intended for low-level programming on a platform should handle volatile in a way that will recognize any and all relevant effects of a particular read/write operation on that platform, many compilers fall short of doing so in ways that make it harder to process things like background I/O in a way which is efficient but can't be broken by compiler "optimizations".