本文主要讲解Java内存模型和并发的基础概念,目的是为下文“volatile实践”一文作铺垫。java
你们都知道,计算机在执行程序时,每条指令都是在CPU中执行的,而执行指令过程当中,势必涉及到数据的读取和写入。因为程序运行过程当中的临时数据是存放在主存(物理内存)当中的,这时就存在一个问题,因为CPU执行速度很快,而从内存读取数据和向内存写入数据的过程跟CPU执行指令的速度比起来要慢的多,所以若是任什么时候候对数据的操做都要经过和内存的交互来进行,会大大下降指令执行的速度。所以在CPU里面就有了高速缓存。
也就是,当程序在运行过程当中,会将运算须要的数据从主存复制一份到CPU的高速缓存当中,那么CPU进行计算时就能够直接从它的高速缓存读取数据和向其中写入数据,当运算结束以后,再将高速缓存中的数据刷新到主存当中。举个简单的例子,好比下面的这段代码:编程
i = i + 1;
复制代码
当线程执行这个语句时,会先从主存当中读取i的值,而后复制一份到高速缓存当中,而后CPU执行指令对i进行加1操做,而后将数据写入高速缓存,最后将高速缓存中i最新的值刷新到主存当中。
这个代码在单线程中运行是没有任何问题的,可是在多线程中运行就会有问题了。在多核CPU中,每条线程可能运行于不一样的CPU中,所以每一个线程运行时有本身的高速缓存(对单核CPU来讲,其实也会出现这种问题,只不过是以线程调度的形式来分别执行的)。本文咱们以多核CPU为例
好比同时有2个线程执行这段代码,假如初始时i的值为0,那么咱们但愿两个线程执行完以后i的值变为2。可是事实会是这样吗?
可能存在下面一种状况:初始时,两个线程分别读取i的值存入各自所在的CPU的高速缓存当中,而后线程1进行加1操做,而后把i的最新值1写入到内存。此时线程2的高速缓存当中i的值仍是0,进行加1操做以后,i的值为1,而后线程2把i的值写入内存。
最终结果i的值是1,而不是2。这就是著名的缓存一致性问题。一般称这种被多个线程访问的变量为共享变量。
也就是说,若是一个变量在多个CPU中都存在缓存(通常在多线程编程时才会出现),那么就可能存在缓存不一致的问题。
为了解决缓存不一致性问题,一般来讲有如下2种解决方法:
1)经过在总线加LOCK#锁的方式
2)经过缓存一致性协议
这2种方式都是硬件层面上提供的方式。
在早期的CPU当中,是经过在总线上加LOCK#锁的形式来解决缓存不一致的问题。由于CPU和其余部件进行通讯都是经过总线来进行的,若是对总线加LOCK#锁的话,也就是说阻塞了其余CPU对其余部件访问(如内存),从而使得只能有一个CPU能使用这个变量的内存。好比上面例子中 若是一个线程在执行 i = i +1,若是在执行这段代码的过程当中,在总线上发出了LCOK#锁的信号,那么只有等待这段代码彻底执行完毕以后,其余CPU才能从变量i所在的内存读取变量,而后进行相应的操做。这样就解决了缓存不一致的问题。
可是上面的方式会有一个问题,因为在锁住总线期间,其余CPU没法访问内存,致使效率低下。因此就出现了缓存一致性协议。最出名的就是Intel 的MESI协议,MESI协议保证了每一个缓存中使用的共享变量的副本是一致的。它核心的思想是:当CPU写数据时,若是发现操做的变量是共享变量,即在其余CPU中也存在该变量的副本,会发出信号通知其余CPU将该变量的缓存行置为无效状态,所以当其余CPU须要读取这个变量时,发现本身缓存中缓存该变量的缓存行是无效的,那么它就会从内存从新读取。 缓存
在并发编程中,咱们一般会遇到如下三个问题:原子性问题,可见性问题,有序性问题。咱们先看具体看一下这三个概念:bash
原子性:即一个操做或者多个操做 要么所有执行而且执行的过程不会被任何因素打断,要么就都不执行。
一个很经典的例子就是银行帐户转帐问题:
好比从帐户A向帐户B转1000元,那么必然包括2个操做:从帐户A减去1000元,往帐户B加上1000元。
试想一下,若是这2个操做不具有原子性,会形成什么样的后果。假如从帐户A减去1000元以后,操做忽然停止。而后又从B取出了500元,取出500元以后,再执行 往帐户B加上1000元 的操做。这样就会致使帐户A虽然减去了1000元,可是帐户B没有收到这个转过来的1000元。
因此这2个操做必需要具有原子性才能保证不出现一些意外的问题。
一样地反映到并发编程中会出现什么结果呢?
举个最简单的例子,你们想一下假如为一个32位的变量赋值过程不具有原子性的话,会发生什么后果?多线程
i = 9
复制代码
倘若一个线程执行到这个语句时,我暂且假设为一个32位的变量赋值包括两个过程:为低16位赋值,为高16位赋值。
那么就可能发生一种状况:当将低16位数值写入以后,忽然被中断,而此时又有一个线程去读取i的值,那么读取到的就是错误的数据。并发
可见性是指当多个线程访问同一个变量时,一个线程修改了这个变量的值,其余线程可以当即看获得修改的值。
举个简单的例子,看下面这段代码app
//线程1执行的代码
int i = 0;
i = 10;
//线程2执行的代码
j = i;
复制代码
倘若执行线程1的是CPU1,执行线程2的是CPU2。由上面的分析可知,当线程1执行 i =10这句时,会先把i的初始值加载到CPU1的高速缓存中,而后赋值为10,那么在CPU1的高速缓存当中i的值变为10了,却没有当即写入到主存当中。
此时线程2执行 j = i,它会先去主存读取i的值并加载到CPU2的缓存当中,注意此时内存当中i的值仍是0,那么就会使得j的值为0,而不是10.
这就是可见性问题,线程1对变量i修改了以后,线程2没有当即看到线程1修改的值。性能
有序性:即程序执行的顺序按照代码的前后顺序执行。举个简单的例子,看下面这段代码:优化
int i = 0;
boolean flag = false;
i = 1; //语句1
flag = true; //语句2
复制代码
上面代码定义了一个int型变量,定义了一个boolean类型变量,而后分别对两个变量进行赋值操做。从代码顺序上看,语句1是在语句2前面的,那么JVM在真正执行这段代码的时候会保证语句1必定会在语句2前面执行吗?不必定,为何呢?这里可能会发生指令重排序(Instruction Reorder)。
下面解释一下什么是指令重排序,通常来讲,处理器为了提升程序运行效率,可能会对输入代码进行优化,它不保证程序中各个语句的执行前后顺序同代码中的顺序一致,可是它会保证程序最终执行结果和代码顺序执行的结果是一致的。 好比上面的代码中,语句1和语句2谁先执行对最终的程序结果并无影响,那么就有可能在执行过程当中,语句2先执行而语句1后执行。
可是要注意,虽然处理器会对指令进行重排序,可是它会保证程序最终结果会和代码顺序执行结果相同,那么它靠什么保证的呢?再看下面一个例子:spa
int a = 10; //语句1
int r = 2; //语句2
a = a + 3; //语句3
r = a*a; //语句4
复制代码
这段代码有4个语句,那么可能的一个执行顺序是:
//线程1:
context = loadContext(); //语句1
inited = true; //语句2
//线程2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);
复制代码
上面代码中,因为语句1和语句2没有数据依赖性,所以可能会被重排序。假如发生了重排序,在线程1执行过程当中先执行语句2,而此是线程2会觉得初始化工做已经完成,那么就会跳出while循环,去执行doSomethingwithconfig(context)方法,而此时context并无被初始化,就会致使程序出错。
从上面能够看出,指令重排序不会影响单个线程的执行,可是会影响到线程并发执行的正确性。
也就是说,要想并发程序正确地执行,必需要保证原子性、可见性以及有序性。只要有一个没有被保证,就有可能会致使程序运行不正确。
在前面谈到了一些关于内存模型以及并发编程中可能会出现的一些问题。下面咱们来看一下Java内存模型,研究一下Java内存模型为咱们提供了哪些保证以及在java中提供了哪些方法和机制来让咱们在进行多线程编程时可以保证程序执行的正确性。
在Java虚拟机规范中试图定义一种Java内存模型(Java Memory Model,JMM)来屏蔽各个硬件平台和操做系统的内存访问差别,以实现让Java程序在各类平台下都能达到一致的内存访问效果。那么Java内存模型规定了哪些东西呢,它定义了程序中变量的访问规则,往大一点说是定义了程序执行的次序。注意,为了得到较好的执行性能,Java内存模型并无限制执行引擎使用处理器的寄存器或者高速缓存来提高指令执行速度,也没有限制编译器对指令进行重排序。也就是说,在java内存模型中,也会存在缓存一致性问题和指令重排序的问题。
Java内存模型规定全部的变量都是存在主存当中(相似于前面说的物理内存),每一个线程都有本身的工做内存(相似于前面的高速缓存)。线程对变量的全部操做都必须在工做内存中进行,而不能直接对主存进行操做。而且每一个线程不能访问其余线程的工做内存。
举个简单的例子:在java中,执行下面这个语句:
i = 10
复制代码
执行线程必须先在本身的工做线程中对变量i所在的缓存行进行赋值操做,而后再写入主存当中。而不是直接将数值10写入主存当中。
那么Java语言 自己对 原子性、可见性以及有序性提供了哪些保证呢?
在Java中,对基本数据类型的变量的读取和赋值操做是原子性操做,即这些操做是不可被中断的,要么执行,要么不执行。 上面一句话虽然看起来简单,可是理解起来并非那么容易。看下面一个例子i: 请分析如下哪些操做是原子性操做:
x = 10; //语句1
y = x; //语句2
x++; //语句3
x = x + 1; //语句4
复制代码
咋一看,有些朋友可能会说上面的4个语句中的操做都是原子性操做。其实只有语句1是原子性操做,其余三个语句都不是原子性操做。
语句1是直接将数值10赋值给x,也就是说线程执行这个语句的会直接将数值10写入到工做内存中。
语句2实际上包含2个操做,它先要去读取x的值,再将x的值写入工做内存,虽然读取x的值以及 将x的值写入工做内存 这2个操做都是原子性操做,可是合起来就不是原子性操做了。 一样的,x++和 x = x+1包括3个操做:读取x的值,进行加1操做,写入新的值。
因此上面4个语句只有语句1的操做具有原子性。
也就是说,只有简单的读取、赋值(并且必须是将数字赋值给某个变量,变量之间的相互赋值不是原子操做)才是原子操做。 不过这里有一点须要注意:在32位平台下,对64位数据的读取和赋值是须要经过两个操做来完成的,不能保证其原子性。可是好像在最新的JDK中,JVM已经保证对64位数据的读取和赋值也是原子性操做了。
从上面能够看出,Java内存模型只保证了基本读取和赋值是原子性操做,若是要实现更大范围操做的原子性,能够经过synchronized和Lock来实现。因为synchronized和Lock可以保证任一时刻只有一个线程执行该代码块,那么天然就不存在原子性问题了,从而保证了原子性。
对于可见性,Java提供了volatile关键字来保证可见性。
当一个共享变量被volatile修饰时,它会保证修改的值会当即被更新到主存,当有其余线程须要读取时,它会去内存中读取新值。
而普通的共享变量不能保证可见性,由于普通共享变量被修改以后,何时被写入主存是不肯定的,当其余线程去读取时,此时内存中可能仍是原来的旧值,所以没法保证可见性。
另外,经过synchronized和Lock也可以保证可见性,synchronized和Lock能保证同一时刻只有一个线程获取锁而后执行同步代码,而且在释放锁以前会将对变量的修改刷新到主存当中。所以能够保证可见性。
在Java内存模型中,容许编译器和处理器对指令进行重排序,可是重排序过程不会影响到单线程程序的执行,却会影响到多线程并发执行的正确性。
在Java里面,能够经过volatile关键字来保证必定的“有序性”(具体原理在下一节讲述)。另外能够经过synchronized和Lock来保证有序性,很显然,synchronized和Lock保证每一个时刻是有一个线程执行同步代码,至关因而让线程顺序执行同步代码,天然就保证了有序性。
另外,Java内存模型具有一些先天的“有序性”,即不须要经过任何手段就可以获得保证的有序性,这个一般也称为 happens-before 原则。若是两个操做的执行次序没法从happens-before原则推导出来,那么它们就不能保证它们的有序性,虚拟机能够随意地对它们进行重排序。
下面就来具体介绍下happens-before原则(先行发生原则):