volatile字面有“易挥发”的意思，引申开来就是有“不稳定”的意思。volatile 关键字用于修饰共享可变变量，即没有使用 final 关键字修饰的实例变量或静态变量，相应的变量就被称为 volatile 变量。

volatile关键字表示被修饰的变量的值容易变化（ 即被其他线程更改 ）。因而不稳定。

volatile变量的不稳定性意味着对这种变量的读和写操作都必须从高速缓存或者主内存。（也是通过高速缓存读取）中读取，以读取变量的相对新值。因此，volatile变量不会被编译器分配到寄存器进行存储，对 volatile 变量的读写操作都是内存访问（ 访问高速缓存相当于主内存 ）操作。

volatile关键字常被称为轻量级锁 ，其作用与锁的作用有相同的地方：保证可见性和有序性。所不同的是，在原子性方面它仅能保障写 volatile 变量操作的原子性，但没有锁的排他性；其次，volatile 关键字的使用不会引起上下文切换（ 这是 volatile 被冠以 “轻量级” 的原因 ）。因此，volatile 更像是一个轻量级简易（ 功能比锁有限 ）锁。

volatile的作用

volatile关键字的作用包括：保障可见性、保障有序性和保障 long/double 型变量读写 操作的原子性。volatile 关键宇能够保障对 long/double 型变量的写操作具有原子性。在 Java 语言中， 对 long 型和 double 型以外的任何类型的变量的写操作都是原子操作。考虑到某些 32 位 Java 虚拟机上对 long/double 型变量进行的写操作可能不具有原子性，Java 语言规范特别地规定对 long/double 型 volatile 变量的写操作和读操作也具有原子性。

但是，volatile仅仅保障对其修饰的变量的写操作（ 以及读操作 ）本身的原子性 ，而这并不表示对 volatile 变量的赋值操作一定具有原子性。例如，如下对volatile 变量 count1的赋值操作并不是原子操作：

count1 = count2  + 1;

如果变量count2也是一个共享变量，那么该赋值操作实际上是一个read-modify-write 操作。其执行过程中其他线程可能已经更新了 count2 的值，因此该操作不具备不可分割性，也就不是原子操作。如果变量count2 是一个局部变量，那么该赋值操作就是一个原子操作。

一般而言，对volatile变量的赋值操作，其右边表达式中只要涉及共享变量 （ 包括被赋值的 volatile 变量本身 ），那么这个赋值操作就不是原子操作。要保障这样操作的原子性， 我们仍然需要借助锁。

写线程对volatile变量的写操作会产生类似于释放锁的效果。读线程对 volatile 变量的读操作会产生类似于获得锁的效果。因此，volatile具有保障有序性和可见性的作用。

对于volatile变量的写操作，Java 虚拟机会在该操作之前插入一个释放屏障，并在该 操作之后插入一个存储屏障，如图所示。

其中，释放屏障禁止了volatile写操作与该操作之前的任何读、写操作进行重排序， 从而保证了 volatile 写操作之前的任何读、写操作会先于 volatile 写操作被提交，即其他线程看到写线程对 volatile 变量的更新时，写线程在更新 volatile 变量之前所执行的内存操作的结果对于读线程必然也是可见的。这就保障了读线程对写线程在更新 volatile 变量前对共享变量所执行的更新操作的感知顺序与相应的源代码顺序一致，即保障了有序性。

volatile虽然能够保障有序性，但是它不像锁那样具备排他性，所以并不能保障其他操作的原子性，而只能够保障对被修饰变量的写操作的原子性。因此，volatile 变量写操作之前的操作如果涉及共享可变变量，那么竞态仍可能产生。这是因为共享变量被赋值给 volatile 变量的时候其他线程可能已经更新了该共享变量的值。

存储屏障具有冲刷处理器缓存的作用，因此在volatile变量写操作之后插入的一个存储屏障就使得该存储屏障前所有操作的结果（ 包括 volatile 变量写操作及该操作之前的任何操作 ）对其他处理器来说是可同步的。

对于volatile变量读操作，Java虚拟机会在该操作之前插入一个加载屏障 （ Load Barrier ），并在该操作之后插入一个获取屏障（Acquire Barrier），如图所示。

其中，加载屏障通过刷新处理器缓存，使其执行线程（读线程）所在的处理器将其他处理器对共享变量（可能是多个变量）所做的更新同步到该处理器的高速缓存中。读线程执行的加载屏障和写线程执行的存储屏障配合在一起使得写线程对volatile变量的写操作以及在此之前所执行的其他内存操作的结果对读线程可见即保障了可见性。因此，volatile 不仅仅保障了 volatile 变量本身的可见性，还保障了写线程在更新 volatile  变量之前执行的所有操作的结果对读线程可见。这种可见性保障类似于锁对可见性的保障，与锁不同的是 volatile不具备排他性 ，因而它不能保障读线程读取到的这些共享变量的值是最新的，即读线程读取到这些共享变量的那一刻可能已经有其他写线程更新了这些共享变量的值。另外，获取屏障禁止了 volatile 读操作之后的任何读、写操作与 volatile 读操作进行重排序。 因此它保障了 volatile 读操作之后的任何操作开始执行之前，写线程对相关共享变量（包括 volatile 变量和普通变量）的更新已经对当前线程可见。

另外，volatile关键字也可以被看作给 JIT 编译器的一个提示，它相当于告诉 JIT 编译器相应变量的值可能被其他处理器更改，从而使JIT编译器不会对相应代码做出一些优化而导致可见性问题。volatile 在有序性保障方面也可以从禁止重排序的角度理解，即volatile 禁止了如下重排序 ：写 volatile 变量操作与该操作之前的任何读 、写操作不会被重排序； 读 volatile 变量操作与该操作之后的任何读、写操作不会被重排序。

综上所述，我们知道volatile关键字的作用体现在对其所修饰的变量的读 、写操作上。

如果被修饰的变量是个数组，那么volatile关键字只能够对数组引用本身的操作（ 读取数组引用和更新数组引用 ）起作用，而无法对数组元素的操作（ 读取 、更新数组元素 ）起作用。

对数组的操作可分为读取数组元素、写数组元素和读取数组引用这几种类型：

在上述操作中，类型①操作可以分解为两个子步骤：先读取数组引用 anArray ， 接着读取数组中的第 0 个元素。这里，第1个子步骤实际上是读取一个引用（ 相当于相应数组的内存地址，或者干脆理解为 C 语言中的指针），该子步骤是个 volatile  变量读取操作，它保障了当前线程能够读取到数组引用本身的相对新值；而第 2 个子步骤则是在指定的数组引用 （ 内存地址 ） 基础上计算偏移量来读取数组元素，它与 volatile关键字没有关系。 因此，它不能保障其读取到的值是相对新值。也就是说，在类型①操作中，volatile关键字起到的作用是保障当前线程能够读取到的数组引用的相对新值，这个值仅仅代表相应数组的内存地址而己，而该操作所读取到的数组元素值是否是相对新值则无法通过 volatile 关键字保障。类似地，在类型②操作中，volatile关键字起到的作用只是保障读取到的数组引用是一个相对新值，而对相应数组元素的写操作则没有可见性保障。类型③的操作是将一个数组的引用写入另外一个数组 ，这相当于更新另外一个数组的引用 （ 内存地址 ）， 这里的赋值操作是能够触发volatile关键字的所有作用的。

如果要使对数组元素的读、写操作也能够触发volatile关键字的作用，那么我们可以使用类 AtomiclntegerArray 、AtomicLongArray 和 AtomicReferenceArray。

类似地，对于引用型volatile变量，volatile 关键字只是保证读线程能够读取到一个指向对象的相对新的内存地址（引用），而这个内存地址指向的对象的实例／静态变量值是否是相对新的则没有保障。

volatile变量的开销

volatile变量的开销包括读变量和写变量两个方面。volatile 变量的读 、写操作都不会导致上下文切换。因此 volatile 的开销比锁要小。写一个 volatile 变量会使该操作以及该操作之前的任何写操作的结果对其他处理器是可同步的，因此 volatile 变量写操作的成本介于普通变量的写操作和在临界区内进行的写操作之间。读取 volatile 变量的成本也比在临界区中读取变量要低（没有锁的申请与释放以及上下文切快的开销）。但是其成本可能比读取普通变量要高一些。这是因为 volatile 变量的值每次都需要从高速缓存或者主内存中读取，而无法被暂存在寄存器中，从而元法发挥访问的高效性。

volatile的典型应用场景与实战案例

volatile除了用于保障 long/double 型变量的读、写操作的原子性，其典型使用场景还包括以下几个方面。

·场景一 使用  volatile 变量作为状态标志。在该场景中，应用程序的某个状态由一个线程设置，其他线程会读取该状态并以该状态作为其计算的依据（ 或者仅仅读取并输出这个状态值。此时使用 volatile变量作为同步机制的好处是一个线程能够 “通知” 另外一个线程某种事件（ 例如，网络连接断连之后重新连上）的发生，而这些线程又无须因此而使用锁，从而避免了锁的开销以及相关问题。

·场景二  使用 volatile  保障可见性。在该场景中，多个线程共享一个可变状态变量 ，其中一个线程更新了该变量之后。其他线程在元须加锁的情况下也能够看到该更新。

·场景三 使用 volatile变量替代锁。volatile 关键字并非锁的替代品，但是在一定的条件下它比锁更合适 （ 性能开销小 、代码简单 ）。多个线程共享一组可变状态变量的时候，通常我们需要使用锁来保障对这些变量的更新操作的原子性，以避免产生数据不一致问题。利用 volatile 变量写操作具有的原子性 ，我们可以把这一组可变状态变量封装成一个对象，那么对这些状态变量的更新操作就可以通过创建一个新的对象并将该对象引用赋值给相应的引用型变量来实现。在这个过程中， volatile 保障了原子性和可见性。从而避免了锁的使用。