共计 3000 个字符，预计需要花费 8 分钟才能阅读完成。
一、前言
我们知道在多线程的场景下，线程安全是必须要着重考虑的。Java 语言包含两种内在的同步机制：同步块（synchronize 关键字）和 volatile 变量。但是其中 Volatile 变量虽然使用简单，有时候开销也比较低，但是同时它的同步性较差，而且其使用也更容易出错。下面我们先使用一个例子来展示下 volatile 有可能出现线程不安全的情况：
public class ShareDataVolatile {
// 同时创建十个线程，每个线程自增 100 次
// 主程序等待 3 秒让所有线程全部运行完毕后输出最后的 count 值
// 使用 volatile 修饰计数变量 count
public volatile static int count=0;
public static void main(String[] args){
final ShareDataVolatile data = new ShareDataVolatile();
for(int i=0;i<10;i++){
new Thread(
new Runnable(){
public void run(){
try{
Thread.sleep(1);
}catch(InterruptedException e){
e.printStackTrace();
}
for(int j=0;j<100;j++){
data.addCount();
}
System.out.print(count+” “);
}
}
).start();
}
try{
Thread.sleep(3000);
}catch(InterruptedException e){
e.printStackTrace();
}
System.out.println();
System.out.print(“count=”+count);
}
public void addCount(){
count++;
}
}
运行结果：
200 200 416 585 755 742 513 513 501 855
count=855 多次运行结果最后的 count 都不是预计的 1000，这说明使用 volatile 变量并不能保证线程安全。
二、原因分析
锁提供了两种主要特性：互斥（mutual exclusion）和可见性（visibility）。互斥即一次只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如“start <=end”）。所以例子中虽然增量操作（count++）看上去类似一个单独操作，实际上它是一个由读取-修改-写入操作序列组成的组合操作，必须以原子方式执行，而 volatile 不能对组合操作提供必须的原子特性。实现正确的操作需要使 count 的值在操作期间保持不变，而 volatile 变量无法实现这点。
三、JVM 内存操作模型
在 java 垃圾回收整理一文中，描述了 jvm 运行时刻内存的分配。其中有一个内存区域是 jvm 虚拟机栈，每一个线程运行时都有一个线程栈，线程栈保存了线程运行时候变量值信息。当线程访问某一个对象时候值的时候，首先通过对象的引用找到对应在堆内存的变量的值，然后把堆内存变量的具体值 load 到线程本地内存中，建立一个变量副本，之后线程就不再和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，在修改完之后的某一个时刻（线程退出之前），自动把线程变量副本的值回写到对象在堆中变量。这样在堆中的对象的值就产生变化了。下面一幅图描述这写交互:
read and load 从主存复制变量到当前工作内存 use and assign 执行代码，改变共享变量值 store and write 用工作内存数据刷新主存相关内容其中 use and assign 可以多次出现, 但是这一些操作并不是原子性，也就是 在 read load 之后，如果主内存 count 变量发生修改之后，线程工作内存中的值由于已经加载，不会产生对应的变化，所以计算出来的结果会和预期不一样对于 volatile 修饰的变量，jvm 虚拟机只是保证从主内存加载到线程工作内存的值是最新的, 例如:
假如线程 1，线程 2 在进行 ead,load 操作中，发现主内存中 count 的值都是 5，那么都会加载这个最新的值 在线程 1 堆 count 进行修改之后，会 write 到主内存中，主内存中的 count 变量就会变为 6 线程 2 由于已经进行 read,load 操作，在进行运算之后，也会更新主内存 count 的变量值为 6 导致两个线程及时用 volatile 关键字修改之后，还是会存在并发的情况。
四、Volatile 的优势与使用条件
看了上面的，大家可能已经对 volatile 表示十分失望，不打算使用它了，然后 volatile 的存在肯定有它存在的意义：
1. 简易性：在某些情形下，使用 volatile 变量要比使用相应的锁简单得多。2. 性能：某些情况下，volatile 变量同步机制的性能要优于锁。对 JVM 内在的操作而言，我们难以抽象地比较 volatile 和 synchronized 的开销。但是大部分情况下，在目前大多数的处理器架构上，volatile 读操作开销非常低 —— 几乎和非 volatile 读操作一样。而 volatile 写操作的开销要比非 volatile 写操作多很多，因为要保证可见性需要实现内存界定（Memory Fence），即便如此，volatile 的总开销仍然要比锁获取低。volatile 操作不会像锁一样造成阻塞，因此，在能够安全使用 volatile 的情况下，volatile 可以提供一些优于锁的可伸缩特性。如果读操作的次数要远远超过写操作，与锁相比，volatile 变量通常能够减少同步的性能开销。
所以我们需要明确可以使用 volatile 的条件有两点：
1. 对变量的写操作不依赖于当前值。2. 该变量没有包含在具有其他变量的不变式中。
五、结束语
与锁相比，Volatile 变量是一种非常简单但同时又非常脆弱的同步机制，它在某些情况下将提供优于锁的性能和伸缩性。如果严格遵循 volatile 的使用条件 —— 即变量真正独立于其他变量和自己以前的值 —— 在某些情况下可以使用 volatile 代替 synchronized 来简化代码。然而，使用 volatile 的代码往往比使用锁的代码更加容易出错。另外如果不是很在意性能方面，并且希望实现简洁明了的技术器功能，可以参考我博客内的另一篇介绍 AtomicInteger 类的文章，该类可以实现原子性操作，从而保证线程安全：http://blog.csdn.net/roy_70/a…
参考文章：Java 理论与实践: 正确使用 Volatile 变量：https://www.ibm.com/developer…
