如果你正在从内存中的某个点(比如说，一个完全独立的进程/设备/任何东西)读取数据，则需要使用Volatile。

我曾经在纯c的多处理器系统中使用双端口ram。我们使用硬件管理的16位值作为信号量，以知道另一个家伙什么时候完成。基本上我们是这样做的:

void waitForSemaphore()
{
   volatile uint16_t* semPtr = WELL_KNOWN_SEM_ADDR;/*well known address to my semaphore*/
   while ((*semPtr) != IS_OK_FOR_ME_TO_PROCEED);
}

没有volatile，优化器认为循环是无用的(这家伙从不设置值!他疯了，删掉那代码吧!)，我的代码会在没有获得信号量的情况下继续运行，从而在以后造成问题。

In the early days of C, compilers would interpret all actions that read and write lvalues as memory operations, to be performed in the same sequence as the reads and writes appeared in the code. Efficiency could be greatly improved in many cases if compilers were given a certain amount of freedom to re-order and consolidate operations, but there was a problem with this. Even though operations were often specified in a certain order merely because it was necessary to specify them in some order, and thus the programmer picked one of many equally-good alternatives, that wasn't always the case. Sometimes it would be important that certain operations occur in a particular sequence.

Exactly which details of sequencing are important will vary depending upon the target platform and application field. Rather than provide particularly detailed control, the Standard opted for a simple model: if a sequence of accesses are done with lvalues that are not qualified volatile, a compiler may reorder and consolidate them as it sees fit. If an action is done with a volatile-qualified lvalue, a quality implementation should offer whatever additional ordering guarantees might be required by code targeting its intended platform and application field, without requiring that programmers use non-standard syntax.

不幸的是，许多编译器并没有确定程序员需要什么样的保证，而是选择提供标准规定的最低限度的保证。这使得volatile远没有它应有的用处。例如，在gcc或clang上，一个程序员需要实现一个基本的“移交互斥量”(一个已经获得并释放互斥量的任务直到另一个任务释放互斥量后才会再次释放互斥量)，他必须做以下四件事中的一件:

将互斥量的获取和释放放在编译器不能内联的函数中，并且不能应用整个程序优化。 将互斥锁保护的所有对象限定为volatile——如果所有访问都发生在获得互斥锁之后和释放互斥锁之前，那么就不应该这样做。 使用优化级别0来强制编译器生成代码，就像所有非限定寄存器的对象都是volatile一样。 使用特定于gcc的指令。

相比之下，当使用更适合系统编程的高质量编译器时，例如icc，人们将有另一种选择:

确保在每个需要获取或释放的地方执行volatile-qualified write。

获取一个基本的“传递互斥量”需要一个volatile读取(看看它是否准备好了)，并且不应该需要一个volatile写入(另一方在它被交还之前不会试图重新获取它)，但是必须执行一个毫无意义的volatile写入仍然比gcc或clang下可用的任何选项都要好。

除了按预期使用它，volatile还用于(模板)元编程。它可以用来防止意外重载，因为volatile属性(如const)参与了重载解析。

template <typename T> 
class Foo {
  std::enable_if_t<sizeof(T)==4, void> f(T& t) 
  { std::cout << 1 << t; }
  void f(T volatile& t) 
  { std::cout << 2 << const_cast<T&>(t); }

  void bar() { T t; f(t); }
};

这是合法的;这两个重载都可能是可调用的，并且执行几乎相同的操作。在volatile重载中的强制转换是合法的，因为我们知道bar无论如何都不会通过一个非volatile T。不过，volatile版本严格来说更糟糕，所以如果非volatile f可用，则永远不要在重载分辨率中选择。

注意，代码实际上从不依赖于volatile内存访问。

在开发嵌入式系统或设备驱动程序时，需要使用Volatile，因为在这些驱动程序中需要读写内存映射的硬件设备。特定设备寄存器的内容随时都可能改变，所以你需要volatile关键字来确保这样的访问不会被编译器优化。

volatile关键字的目的是防止编译器对可能以编译器无法确定的方式改变的对象应用任何优化。

声明为volatile的对象在优化中被省略，因为它们的值可以被当前代码范围之外的代码随时更改。系统总是从内存位置读取volatile对象的当前值，而不是在请求时将其值保存在临时寄存器中，即使之前的指令从同一对象中请求一个值。

考虑以下情况

1)由中断服务例程在作用域外修改的全局变量。

2)多线程应用程序中的全局变量。

如果不使用volatile限定符，可能会出现以下问题

1)当优化被打开时，代码可能不会像预期的那样工作。

2)当中断被启用和使用时，代码可能不会像预期的那样工作。

Volatile:程序员最好的朋友

https://en.wikipedia.org/wiki/Volatile_ (computer_programming)

一些处理器具有超过64位精度的浮点寄存器(例如。32位x86没有SSE，见Peter的评论)。这样，如果您对双精度数运行多次操作，实际上会得到比将每个中间结果截断为64位更高精度的答案。

这通常很好，但这意味着根据编译器如何分配寄存器和进行优化，对于完全相同的输入，完全相同的操作将得到不同的结果。如果您需要一致性，那么您可以使用volatile关键字强制每个操作返回内存。

它对于一些没有代数意义但减少浮点误差的算法也很有用，比如Kahan求和。代数上它是一个nop，所以它经常会被错误地优化除非一些中间变量是不稳定的。