在上一篇文章中咱们深刻理解了java关键字synchronized,咱们知道在java中还有一大神器就是关键volatile,能够说是和synchronized各领风骚,其中奥妙,咱们来共同探讨下。java
经过上一篇的文章咱们了解到synchronized是阻塞式同步,在线程竞争激烈的状况下会升级为重量级锁。而volatile就能够说是java虚拟机提供的最轻量级的同步机制。但它同时不容易被正确理解,也至于在并发编程中不少程序员遇到线程安全的问题就会使用synchronized。Java内存模型告诉咱们,各个线程会将共享变量从主内存中拷贝到工做内存,而后执行引擎会基于工做内存中的数据进行操做处理。线程在工做内存进行操做后什么时候会写到主内存中?这个时机对普通变量是没有规定的,而针对volatile修饰的变量给java虚拟机特殊的约定,线程对volatile变量的修改会马上被其余线程所感知,即不会出现数据脏读的现象,从而保证数据的“可见性”。程序员
如今咱们有了一个大概的印象就是:被volatile修饰的变量可以保证每一个线程可以获取该变量的最新值,从而避免出现数据脏读的现象。编程
volatile是怎样实现了?好比一个很简单的Java代码:缓存
instance = new Instancce() //instance是volatile变量安全
在生成汇编代码时会在volatile修饰的共享变量进行写操做的时候会多出Lock前缀的指令(具体的你们可使用一些工具去看一下,这里我就只把结果说出来)。咱们想这个Lock指令确定有神奇的地方,那么Lock前缀的指令在多核处理器下会发现什么事情了?主要有这两个方面的影响:性能优化
为了提升处理速度,处理器不直接和内存进行通讯,而是先将系统内存的数据读到内部缓存(L1,L2或其余)后再进行操做,但操做完不知道什么时候会写到内存。若是对声明了volatile的变量进行写操做,JVM就会向处理器发送一条Lock前缀的指令,将这个变量所在缓存行的数据写回到系统内存。可是,就算写回到内存,若是其余处理器缓存的值仍是旧的,再执行计算操做就会有问题。因此,在多处理器下,为了保证各个处理器的缓存是一致的,就会实现缓存一致性协议,每一个处理器经过嗅探在总线上传播的数据来检查本身缓存的值是否是过时了,当处理器发现本身缓存行对应的内存地址被修改,就会将当前处理器的缓存行设置成无效状态,当处理器对这个数据进行修改操做的时候,会从新从系统内存中把数据读处处理器缓存里。所以,通过分析咱们能够得出以下结论:并发
这样针对volatile变量经过这样的机制就使得每一个线程都能得到该变量的最新值。app
通过上面的分析,咱们已经知道了volatile变量能够经过缓存一致性协议保证每一个线程都能得到最新值,即知足数据的“可见性”。咱们继续延续上一篇分析问题的方式(我一直认为思考问题的方式是属于本身,也才是最重要的,也在不断培养这方面的能力),我一直将并发分析的切入点分为两个核心,三大性质。两大核心:JMM内存模型(主内存和工做内存)以及happens-before;三条性质:原子性,可见性,有序性(关于三大性质的总结在之后得文章会和你们共同探讨)。废话很少说,先来看两个核心之一:volatile的happens-before关系。ide
在六条happens-before规则中有一条是:**volatile变量规则:对一个volatile域的写,happens-before于任意后续对这个volatile域的读。**下面咱们结合具体的代码,咱们利用这条规则推导下:工具
public class VolatileExample {
private int a = 0;
private volatile boolean flag = false;
public void writer(){
a = 1; //1
flag = true; //2
}
public void reader(){
if(flag){ //3
int i = a; //4
}
}
}
复制代码
上面的实例代码对应的happens-before关系以下图所示:
加锁线程A先执行writer方法,而后线程B执行reader方法图中每个箭头两个节点就代码一个happens-before关系,黑色的表明根据程序顺序规则推导出来,红色的是根据volatile变量的写happens-before 于任意后续对volatile变量的读,而蓝色的就是根据传递性规则推导出来的。这里的2 happen-before 3,一样根据happens-before规则定义:若是A happens-before B,则A的执行结果对B可见,而且A的执行顺序先于B的执行顺序,咱们能够知道操做2执行结果对操做3来讲是可见的,也就是说当线程A将volatile变量 flag更改成true后线程B就可以迅速感知。
仍是按照两个核心的分析方式,分析完happens-before关系后咱们如今就来进一步分析volatile的内存语义(按照这种方式去学习,会不会让你们对知识可以把握的更深,而不至于不知所措,若是你们认同个人这种方式,不妨给个赞,小弟在此谢过,对我是个鼓励)。仍是以上面的代码为例,假设线程A先执行writer方法,线程B随后执行reader方法,初始时线程的本地内存中flag和a都是初始状态,下图是线程A执行volatile写后的状态图。
当volatile变量写后,线程中本地内存中共享变量就会置为失效的状态,所以线程B再须要读取从主内存中去读取该变量的最新值。下图就展现了线程B读取同一个volatile变量的内存变化示意图。
从横向来看,线程A和线程B之间进行了一次通讯,线程A在写volatile变量时,实际上就像是给B发送了一个消息告诉线程B你如今的值都是旧的了,而后线程B读这个volatile变量时就像是接收了线程A刚刚发送的消息。既然是旧的了,那线程B该怎么办了?天然而然就只能去主内存去取啦。
好的,咱们如今两个核心:happens-before以及内存语义如今已经都了解清楚了。是否是还不过瘾,忽然发现原来本身会这么爱学习(微笑脸),那咱们下面就再来一点干货----volatile内存语义的实现。
咱们都知道,为了性能优化,JMM在不改变正确语义的前提下,会容许编译器和处理器对指令序列进行重排序,那若是想阻止重排序要怎么办了?答案是能够添加内存屏障。
内存屏障
JMM内存屏障分为四类见下图,
java编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。为了实现volatile的内存语义,JMM会限制特定类型的编译器和处理器重排序,JMM会针对编译器制定volatile重排序规则表:
"NO"表示禁止重排序。为了实现volatile内存语义时,编译器在生成字节码时,会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来讲,发现一个最优布置来最小化插入屏障的总数几乎是不可能的,为此,JMM采起了保守策略:
须要注意的是:volatile写是在前面和后面分别插入内存屏障,而volatile读操做是在后面插入两个内存屏障
StoreStore屏障:禁止上面的普通写和下面的volatile写重排序;
StoreLoad屏障:防止上面的volatile写与下面可能有的volatile读/写重排序
LoadLoad屏障:禁止下面全部的普通读操做和上面的volatile读重排序
LoadStore屏障:禁止下面全部的普通写操做和上面的volatile读重排序
下面以两个示意图进行理解,图片摘自至关好的一本书《java并发编程的艺术》。
咱们如今已经理解volatile的精华了,文章开头的那个问题我想如今咱们都能给出答案了。更正后的代码为:
public class VolatileDemo {
private static volatile boolean isOver = false;
public static void main(String[] args) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
while (!isOver) ;
}
});
thread.start();
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
isOver = true;
}
}
复制代码
注意不一样点,如今已经将isOver设置成了volatile变量,这样在main线程中将isOver改成了true后,thread的工做内存该变量值就会失效,从而须要再次从主内存中读取该值,如今可以读出isOver最新值为true从而可以结束在thread里的死循环,从而可以顺利中止掉thread线程。如今问题也解决了,知识也学到了:)。(若是以为还不错,请点赞,是对个人一个鼓励。)
参考文献
《java并发编程的艺术》