Java并发编程(五)------volatile关键字和happen-before详解
1.volatile是什么？
Java采用共享内存的方式实现消息传递，而共享内存需要依托于同步，Java提供了synchronized、volatile关键字实现同步，而volatile可以说是Java虚拟机提供的最轻量级的同步机制，此外volatile关键字还拥有一些额外的功能。
当一个变量定义为volatile之后，它将具备两种特性：
- 第一是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。 而普通变量不能做到这一点，普通变量的值在线程间传递均需要通过主内存来完成，例如，线程A修改一个普通变量的值，然后向主内存进行回写，另外一条线程B在线程A回写完成了之后再从主内存进行读取操作，新变量值才会对线程B可见
- 第二是禁止指令重排序优化，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。
1.1volatile变量的可见性
关于volatile变量的可见性，经常会被开发人员误解，认为以下描述成立：“volatile变量对所有线程是立即可见的，对volatile变量所有的写操作都能立刻反应到其他线程之中，换句话说，volatile变量在各个线程中是一致的，所以基于volatile变量的运算在并发下是安全的”。 这句话的论据部分并没有错，但是其论据并不能得出“基于volatile变量的运算在并发下是安全的”这个结论。 volatile变量在各个线程的工作内存中不存在一致性问题（在各个线程的工作内存中，volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题），但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的，我们可以通过一段简单的演示来说明原因：
/**
*volatile变量自增运算测试
*/
public class VolatileTest{
public static volatile int race=0;
public static void increase(){
race++;
}
private static final int THREADS_COUNT=20;
public static void main(String[]args){
Thread[] threads = new Thread[THREADS_COUNT];
for(int i=0;i1)
Thread.yield();
System.out.println(race);
}
} 这段代码发起了20个线程，每个线程对race变量进行10000次自增操作，如果这段代码能够正确并发的话，最后输出的结果应该是200000。 读者运行完这段代码之后，并不会获得期望的结果，而且会发现每次运行程序，输出的结果都不一样，都是一个小于200000的数字，这是为什么呢？
问题就出现在自增运算“race++”之中，我们用Javap反编译这段代码后会得到如下代码清单，发现只有一行代码的increase（）方法在Class文件中是由4条字节码指令构成的（return指令不是由race++产生的，这条指令可以不计算），从字节码层面上很容易就分析出并发失败的原因了：当getstatic指令把race的值取到操作栈顶时，volatile关键字保证了race的值在此时是正确的，但是在执行iconst_1、 iadd这些指令的时候，其他线程可能已经把race的值加大了，而在操作栈顶的值就变成了过期的数据，所以putstatic指令执行后就可能把较小的race值同步回主内存之中。
public static void increase();
Code：
Stack=2，Locals=0，Args_size=0
0：getstatic#13;//Field race：I
3：iconst_1
4：iadd
5：putstatic#13;//Field race：I
8：return
LineNumberTable：
line 14：0
line 15：8在此使用字节码来分析并发问题，仍然是不严谨的，因为即使编译出来只有一条字节码指令，也并不意味执行这条指令就是一个原子操作。 一条字节码指令在解释执行时，解释器将要运行许多行代码才能实现它的语义，如果是编译执行，一条字节码指令也可能转化成若干条本地机器码指令，使用-XX：+PrintAssembly参数输出反汇编来分析会更加严谨一些。
由于volatile变量只能保证可见性并不能保证原子性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁（使用synchronized或java.util.concurrent中的原子类）来保证原子性。
什么时候使用volatile？
- 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
- 变量不需要与其他的状态变量共同参与不变约束。
像如下的代码清单所示的这类场景就很适合使用volatile变量来控制并发，当shutdown()方法被调用时，能保证所有线程中执行的doWork()方法都立即停下来。
volatile boolean shutdownRequested;
public void shutdown(){
shutdownRequested=true;
}
public void doWork(){
while(!shutdownRequested){
//do something
}
}1.2 禁止指令重排序
volatile变量禁止指令重排序优化，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。 因为在一个线程的方法执行过程中无法感知到这点，这也就是Java内存模型中描述的所谓的“线程内表现为串行的语义”（Within-Thread As-If-Serial Semantics）。
通过一个例子来看看为何指令重排序会干扰程序的并发执行，演示程序如下：
Map configOptions;
char[]configText;
//此变量必须定义为volatile
volatile boolean initialized=false;
//假设以下代码在线程A中执行
//模拟读取配置信息，当读取完成后将initialized设置为true以通知其他线程配置可用
configOptions=new HashMap();
configText=readConfigFile(fileName);
processConfigOptions(configText,configOptions);
initialized=true:
//假设以下代码在线程B中执行
//等待initialized为true,代表线程A已经把配置信息初始化完成
while(!initialized){
sleep();
}
//使用线程A中初始化好的配置信息
doSomethingWithConfig();描述的场景十分常见，只是我们在处理配置文件时一般不会出现并发而已。 如果定义initialized变量时没有使用volatile修饰，就可能会由于指令重排序的优化，导致位于线程A中最后一句的代码“initialized=true”被提前执行（这里虽然使用Java作为伪代码，但所指的重排序优化是机器级的优化操作，提前执行是指这句话对应的汇编代码被提前执行），这样在线程B中使用配置信息的代码就可能出现错误，而volatile关键字则可以避免此类情况的发生。
1.3 具体实例
一个可以实际操作运行的例子来分析volatile关键字是如何禁止指令重排序优化的。 代码清单是一段标准的DCL单例代码，可以观察加入volatile和未加入volatile关键字时所生成汇编代码的差别。
public class Singleton{
private volatile static Singleton instance;
public static Singleton getInstance(){
if(instance==null){
synchronized(Singleton.class){
if(instance==null){
instance=new Singleton();
}
}
}
return instance；
}
public static void main(String[]args){
Singleton.getInstance();
}
}编译后，这段代码对instance变量赋值部分如下代码
0x01a3de0f：mov$0x3375cdb0，%esi;……beb0cd75 33
;{oop('Singleton')}
0x01a3de14：mov%eax，0x150(%esi);……89865001 0000
0x01a3de1a：shr$0x9,%esi;……c1ee09
0x01a3de1d：movb$0x0,0x1104800(%esi);……c6860048 100100
0x01a3de24：lock addl$0x0,(%esp);……f0830424 00
;*putstatic instance
;-
Singleton：getInstance@24通过对比就会发现，关键变化在于有volatile修饰的变量，赋值后(前面mov%eax,0x150(%esi)这句便是赋值操作)多执行了一个"lock addl ＄0x0,(%esp)"操作，这个操作相当于一个内存屏障(Memory Barrier或Memory Fence，指重排序时不能把后面的指令重排序到内存屏障之前的位置)，只有一个CPU访问内存时，并不需要内存屏障；但如果有两个或更多CPU访问同一块内存，且其中有一个在观测另一个，就需要内存屏障来保证一致性了。 这句指令中的"addl ＄0x0,(%esp)"（把ESP寄存器的值加0）显然是一个空操作（采用这个空操作而不是空操作指令nop是因为IA32手册规定lock前缀不允许配合nop指令使用），关键在于lock前缀，查询IA32手册，它的作用是使得本CPU的Cache写入了内存，该写入动作也会引起别的CPU或者别的内核无效化（Invalidate）其Cache，这种操作相当于对Cache中的变量做了一次前面介绍Java内存模式中所说的“store和write”操作[2]。 所以通过这样一个空操作，可让前面volatile变量的修改对其他CPU立即可见。
为何说它禁止指令重排序呢？
从硬件架构上讲，指令重排序是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。 但并不是说指令任意重排，CPU需要能正确处理指令依赖情况以保障程序能得出正确的执行结果。 譬如指令1把地址A中的值加10，指令2把地址A中的值乘以2，指令3把地址B中的值减去3，这时指令1和指令2是有依赖的，它们之间的顺序不能重排——（A+10）*2与A*2+10显然不相等，但指令3可以重排到指令1、 2之前或者中间，只要保证CPU执行后面依赖到A、 B值的操作时能获取到正确的A和B值即可。 所以在本内CPU中，重排序看起来依然是有序的。 因此，lock addl＄0x0，（%esp）指令把修改同步到内存时，意味着所有之前的操作都已经执行完成，这样便形成了“指令重排序无法越过内存屏障”的效果。
解决了volatile的语义问题，再来看看在众多保障并发安全的工具中选用volatile的意义——它能让我们的代码比使用其他的同步工具更快吗？在某些情况下，volatile的同步机制的性能确实要优于锁（使用synchronized关键字或java.util.concurrent包里面的锁），但是由于虚拟机对锁实行的许多消除和优化，使得我们很难量化地认为volatile就会比synchronized快多少。 如果让volatile自己与自己比较，那可以确定一个原则：volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。 不过即便如此，大多数场景下volatile的总开销仍然要比锁低，我们在volatile与锁之中选择的唯一依据仅仅是volatile的语义能否满足使用场景的需求。
2. happens-before
happens-before是JMM最核心的概念，理解happens-before是理解JMM的关键。
2.1 JMM的设计
从JMM设计者的角度，在设计JMM时需要考虑两个关键因素。
- 程序员对内存模型的使用。程序员希望内存模型易于理解、易于编程。程序员希望基于一个强内存模型来编写代码。
- 编译器和处理器对内存模型的实现。编译器和处理器希望内存模型对它们的束缚越少越好，这样它们就可以做尽可能多的优化来提高性能。编译器和处理器希望实现一个弱内存模型。
由于这两个因素互相矛盾，在设计JMM时的核心目标就是找到一个好的平衡点：
- 一方面要为程序员提供足够强的内存可见性保证；
- 一方面对编译器和处理器的限制要尽可能地放松。
下面来看是如何实现这一目标的：
double pi = 3.14; // A
double r = 1.0; // B
double area = pi * r * r; // C计算圆的面积的代码存在3个happens-before关系：
- A happens-before B
- B happens-before C
- A happens-before C
在3个happens-before关系中，2和3是必需的，但1是不必要的。因此JMM把happens-before要求禁止的重排序分为了下面两类：
- 会改变程序执行结果的重排序
- 不会改变程序执行结果的重排序
然后JMM对这两种不同性质的重排序，采取了不同的策略：
- 对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序
- 对于不会改变程序执行结果的重排序，JMM对编译器和处理器不做要求（JMM允许这种重排序）
JMM的设计示意图如下：
2.2 happens-before的定义
happens-before来指定两个操作之间的执行顺序。
这两个操作可以在一个线程之内，也可以是在不同线程之间。因此JMM可以通过happens-before关系向程序员提供跨线程的内存可见性保证（如果A线程的写操作a与B线程的读操作b之间存在happensbefore关系，尽管a操作和b操作在不同的线程中执行，但JMM向程序员保证a操作将对b操作可见）。
JSR-133对happens-before关系的定义如下：
- 如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
- 两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果与按happens-before关系来执行的结果一致，那么这种重排序并不非法（JMM允许这种重排序）。
可以理解为：
- 1是JMM对程序员的承诺。从程序员的角度来说如果A happens-before B，那么Java内存模型将向程序员保证——A操作的结果将对B可见，且A的执行顺序排在B之前。
- 2是JMM对编译器和处理器重排序的约束原则。JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。因此，happens-before关系本质上和as-if-serial语义是一回事。as-if-serial语义保证单线程内程序的执行结果不被改变，happens-before关系保证正确同步的多线程程序的执行结果不被改变。
2.3 happens-before规则
JSR-133定义了如下happens-before规则：
- 程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作
- 监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁
- volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读
- 传递性：如果A happens-before B，且B happens-before C，那么A happens-before C
- start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作
- join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回
下面用几个具体例子来说明这些规则：
（1）下图是volatile写-读建立的happens-before关系图：
- 1 happens-before 2和3 happens-before 4由程序顺序规则产生。由于编译器和处理器都要遵守as-if-serial语义，也就是说，as-if-serial语义保证了程序顺序规则。因此，可以把程序顺序规则看成是对as-if-serial语义的“封装”。
- 2 happens-before 3是由volatile规则产生。前面提到过，对一个volatile变量的读，总是能看到（任意线程）之前对这个volatile变量最后的写入。因此volatile的这个特性可以保证实现volatile规则。
- 1 happens-before 4是由传递性规则产生的。这里的传递性是由volatile的内存屏障插入策略和volatile的编译器重排序规则共同来保证的。
（2）假设线程A在执行的过程中，通过执行ThreadB.start()来启动线程B；同时，假设线程A在执行ThreadB.start()之前修改了一些共享变量，线程B在开始执行后会读这些共享变量。下图是该程序对应的happens-before关系图：
- 1 happens-before 2由程序顺序规则产生
- 2 happens-before 4由start()规则产生
- 根据传递性，将有1 happens-before 4
这意味着，线程A在执行ThreadB.start()之前对共享变量所做的修改，接下来在线程B开始执行后都将确保对线程B可见。
（3）假设线程A在执行的过程中，通过执行ThreadB.join()来等待线程B终止；同时，假设线程B在终止之前修改了一些共享变量，线程A从ThreadB.join()返回后会读这些共享变量。下图是该程序对应的happens-before关系图：
- 2 happens-before 4由join()规则产生
- 4 happens-before 5由程序顺序规则产生
- 根据传递性规则，将有2 happens-before 5
这意味着，线程A执行操作ThreadB.join()并成功返回后，线程B中的任意操作都将对线程A可见。