关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制。
当一个变量定义为volatile之后，它具备两种特性，第一是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量不能做到这一点，普通变量的值在线程间传递均需要通过主内存来完成。
关于volatile变量可见性，经常有如下误解：“volatile变量对所有线程是立即可见的，对volatile变量所有写操作都能立刻反应到其他线程之中，换句话说，volatile变量在各个线程种是一致的，所以基于volatile变量的运算在并发下是安全的”。volatile变量在各个线程的工作内存中不存在一致性问题（在各个线程的工作内存中，volatile变量也存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况），但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的，比如下面的例子：
/**
* @author beidao
*
*/
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; i<THREADS_COUNT; i++ ){
threads[i] = new Thread(new Runnable() {
public void run() {
for(int i = 0; i<10000; i++){
increase();
}
}
});
threads[i].start();
}
// 等待所有累加线程都结束
while(Thread.activeCount() > 1){
Thread.yield();//https://www.cnblogs.com/java-spring/p/8309931.html
}
System.out.println(race);
}
}
这段代码发起了20个线程，每个线程对race变量进行10000次自增操作，如果这段代码能够正确并发的话，最后输出的结果应该是200000。但运行完这段代码之后，并不会获得期望的结果，而且会发现每次运行程序输出的结果都不一样，都是一个小于200000的数字。
问题就出现在自增运算“race++”之中，我们用Javap反编译这段代码后会得到如下代码清单，发现只有一行代码的increase()方法在Class文件中是由4条字节码指令构成的（return 指令不是由race++产生的，这条指令可以不计算），从字节码层面上很容易分析出并发失败的原因：当getstatic指令把race的值取到操作栈顶时，volatile关键字保证了race的值此时是正确的，但是在执行iconst_l、iadd这些指令时，其他线程可能已经把race的值加大了，而在操作栈顶的值变成了过期的数据，所以putstatic指令执行后就可能把较小的race值同步回主内存之中。
public static void increase();
Code:
Stack=2,Locals=0,Args_size=0
0: getstatic #13; //Field race:I
3: iconst_l
4: iadd
5: putstatic #13; //Field race:I
8: return
LineNumberTable:
line 14: 0
line 15： 8
由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁来保证原子性：
- 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
- 变量不需要与其他的状态变量共同参与不变约束。
使用volatile变量的第二个语义是禁止指令重排序优化，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，这也就是Java内存模型中描述的所谓的“线程内表现为串行的语义”。
上述可能不太容易理解，通过以下代码进一步阐释：
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关键字则可以避免此类情况的发生。
指令重排序是并发编程中最容易让开发人员产生疑惑的地方，除了上面伪代码的例子之外，笔者再举一个可以实际操作运行的例子来分析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')}
......
0x01a3de24:lock addl $0x0,(%esp) ;...f0830424 00
;*putstatic instance
;-
Singleton::getInstance@24
通过对比就会发现，关键变化在于有volatile修饰的变量，赋值后多执行了一个“lock addl 0x0,(%esp)”(把ESP寄存器的值加0)显然是一个空操作，关键在于lock前缀，它的作用是使得本CPU的Cache写入了内存，该写入动作也会引起别的CPU或者别的内核无效化其Cache，这种操作相当于Cache中的变量做了一次前面介绍Java内存模式中所说的“store和write”操作。所以通过这样一个空操作，可让前面volatile变量的修改对其他CPU立即可见。
那为何说它禁止指令重排序呢？从硬件架构上讲，指令重排序是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。但并不是说指令任意重排。CPU需要能正确处理指令依赖情况以保障程序能得出正确的执行结果。因此，lock addl $0x0,(%esp)指令把修改同步到内存时，意味着所有之前的操作都已经执行完成，这样便形成了“指令重排序无法越过内存屏幕”的效果。
synchronized与volatitle比较
- 关键字volatitle是线程同步的轻量级实现，所以volatitle性能肯定比synchronized要好，并且volatitle只能修饰变量，而synchronized可以修饰方法或代码块 。
- 多线程访问volatitle不会发生阻塞，而synchronized会出现阻塞。
- volatitle能保证数据的可见性，但不能保证原子性；而synchronized可以保证原子性，也可以间接保证可见性，因为它会将私有内存和公有内存中的数据做同步。
- 关键字volatitle解决的是变量在多个线程之间的可见性；而synchronized关键字解决的是多个线程之间访问资源的同步性。
网友评论