轻量级的同步机制——volatile语义详解(可见性保证+禁止指令重排)

目录

• 1.关于volatile
• 2.语义一:内存可见性 2.1 一个例子
• 2.2 java的内存模型(JMM)
• 2.3 happens-before规则
• 2.4 volatile解决内存可见性问题的原理

1.关于volatile

volatile是java语言中的关键字,用来修饰会被多线程访问的共享变量,是JVM提供的轻量级的同步机制,相比同步代码块或者重入锁有更好的性能。它主要有两重语义，一是保证多个线程对共享变量访问的可见性，二防止指令重排序。

2.语义一:内存可见性

2.1 一个例子

public class TestVolatile {

public static void main(String[] args) throws InterruptedException {

ThreadDemo threadDemo = new ThreadDemo();
new Thread(threadDemo).start();
threadDemo.flag = false;
System.out.println("已将flag置为" + threadDemo.flag);

}

static class ThreadDemo implements Runnable {

boolean flag = true;

@Override
public void run() {
System.out.println("Flag=" + flag);
}

}
}

当你多次执行代码时,有一定几率会出现这种结果

在主线程将子线程实例的flag置为false后,子线程中的flag竟然还是true。这是怎么回事？这就是多线程的内存可见性问题。对于一个没有volatile修饰的的共享变量,当一个线程对其进行了修改，另一线程并不一定能马上看见这个被修改后的值。为什么会出现这种情况呢？这就要从java的内存模型谈起。

2.2 java的内存模型(JMM)

java的内存模型定义了线程和主内存之间的抽象关系,它的内容主要包括：

• 主要由多线程共享的主内存和各线程私有的工作内存组成(工作内存是个抽象概念，并不真实存在，是对缓冲区，cpu寄存器等的抽象)
• 变量都存储于主内存中，但是线程的工作内存中保存着要使用的变量在主内存中的副本。
• 线程对变量的操作必须在工作内存中进行，不同的线程无法直接访问对方的工作内存，相互通信必须经过主内存。

线程,主内存，工作内存三者的交互关系如图所示

看看JMM模型会给我们在多线程环境下的读写带来什么样的问题。

• 当一个线程(线程1)对共享变量进行修改时,修改的并不是主内存中的变量，而是该线程对应的工作内存中该变量的一个副本。
• 当主内存中的变量值已经被修改,另一个线程(线程2)读取的却还是自己工作内存中的旧值。

这时就出现了共享变量在多线程环境下的可见性问题。如果把线程的工作内存当作主内存的缓存，这个问题的本质就在于如何解决缓存失效问题。那么JMM中是如何解决可见性问题的?这就不得不提到happens-before规则。

2.3 happens-before规则

happens-before规则又叫先行发生规则。它定义了java内存模型中两项操作的偏序关系,更确切的说，它定义了操作可见性之间的偏序关系。比如A操作 happens-before B操作，并不意味这A操作一定在B操作之前,而是A操作的影响能被操作B观察到，这个影响包括改变了内存中共享变量的值，发送消息等。那么JMM定义了哪些happens-before规则？

• 1.程序顺序规则:一个线程中的每个操作，happens-before于该线程中的任意后续操作。
• 2.监视器锁规则：对于一个锁的解锁，happens-before于随后对这个锁的加锁。
• 3.volatile变量规则：对于一个volatile 变量的写，happens-before于任意后续对这个volatile变量的读。
  这里对于我们而言重要的是第三点。即对于一个volatile变量，写操作happens-before于读操作，也就是说，一个线程对volatile变量做了修改，另一个线程能马上读到这个被修改后的值。
  这样就能解决共享变量在多线程环境下的可见性问题了。结合JMM模型，我们可以继续探讨下volatile是如何做到这点的。

2.4 volatile解决内存可见性问题的原理

当一个变量被修饰为volatile后，对其的读写就会显得比较特别

• 1.写一个volatile变量时，JMM首先修改工作内存中的变量值,并刷新到主内存中
  如图所示
  

• 2.读一个变量时，JMM会把该线程对应的本地内存置为无效，并从主内存中读取共享变量。
  如图所示
  

对volatile变量的读写,可以说都是直接对主内存进行的操作，这样虽然会牺牲一些性能，但是解决了“缓存一致性问题”，使得变量在多线程间的可见性得到了很好的保证。

3. 语义二：禁止指令重排

3.1 为什么会有指令重排

为了优化程序性能,编译器和处理器会对java编译后的字节码和机器指令进行重排序，通俗的说代码的执行顺序和我们在程序中定义的顺序会有些不同,只要不改变单线程环境下的执行结果就行。但是在多线程环境下，这么做却可能出现并发问题。比如下面的例子。

3.2 线程不安全的双重检查单例模式

运行这段代码我们可能会得到一个匪夷所思的结果:我们获得的单例对象是未初始化的。为什么会出现这种情况？因为指令重排。首先要明确一点，同步代码块中的代码也是能够被指令重排的。然后来看问题的关键

INSTANCE = new Singleton();

虽然在代码中只有一行,编译出的字节码指令可以用如下三行表示

• 1.为对象分配内存空间
• 2.初始化对象
• 3.将INSTANCE变量指向刚分配的内存地址
  由于步骤2,3交换不会改变单线程环境下的执行结果，故而这种重排序是被允许的。也就是我们在初始化对象之前就把INSTANCE变量指向了该对象。而如果这时另一个线程刚好执行到代码所示的2处

if (INSTANCE == null)

那么这时候有意思的事情就发生了:虽然INSTANCE指向了一个未被初始化的对象,但是它确实不为null了,所以这个判断会返回false,之后它将return一个未被初始化的单例对象！整个过程的执行流程如下图所示

由于重排序是编译器和CPU自动进行的，那么有什么办法能禁止这种重排序操作吗？很简单,给
INSTANCE变量加个volatile关键字就行,这样编译器就会根据一定的规则禁止对volatile变量的读写操作重排序了。而编译出的字节码，也会在合适的地方插入内存屏障,比如volatile写操作之前和之后会分别插入一个StoreStore屏障和StoreLoad屏障，禁止CPU对指令的重排序越过这些屏障。

4. volatile的其他特性

对volatile变量的读写具有原子性，但是其他操作并不一定具有原子性，一个简单的例子就是i++。由于该操作并不具有原子性，故而即使该变量被volatile修饰，多线程环境下也不能保证线程安全。

5.总结

volatile是jvm提供的轻量级同步工具。被volatile修饰的共享变量在多线程环境下可以获得可见行保证。其次它还能禁止指令重排。由于对volatile的写-读与锁的释放-获取具有相同的内存语义，故某些时候可以代替锁来获得更好的性能。但是和锁不一样，它不能保证任何时候都是线程安全的。