Volatile关键字详解
volatile的定义
这个引用JSR中的定义:
The Java programming language allows threads to access shared variables (§17.1). As a rule, to ensure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive use of such variables by obtaining a lock that, conventionally, enforces mutual exclusion for those shared variables.
The Java programming language provides a second mechanism, volatile fields, that is more convenient than locking for some purposes.
A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable (§17.4).
简单的翻译一下:
Java编程语言中允许线程访问共享变量。为了确保共享变量能被一致地和可靠的更新,线程必须确保它是排他性的使用此共享变量,通常都是获得对这些共享变量强制排他性的同步锁。
Java编程语言提供了另一种机制,volatile域变量,对于某些场景的使用这要更加的方便。
可以把变量声明为volatile,以让Java内存模型来保证所有线程都能看到这个变量的同一个值。
volatile的作用
保证变量的可见性
volatile关键字的作用就是保证共享变量的可见性。什么是可见性呢,就是一个线程读变量,总是能读到它在内存中的最新的值,也就是说不同的线程看到的一个变量的值是相同的。CPU都是有行缓存的,volatile能让行缓存无效,因此能读到内存中最新的值。
保证赋值操作的原子性
原子性就是不能被线程调度打断的操作,是线程安全的操作,对于原子性操作,即使在多线程环境下,也不用担心线程安全问题或者数据不一致的问题。有些变量的赋值本身就是原子性的,比如对boolean,对int的赋值,但是像对于long或者double则不一定,如果是32位的处理器,对于64位的变量的操作可能会被分解成为二个步骤:高32位和低32位,由此可能会发生线程切换,从而导致线程不安全。如果变量声明为volatile,那么虚拟机会保证赋值是原子的,是不可被打断的。
禁止指令重排
正常情况下,虚拟机会对指令进行重排,当然是在不影响程序结果的正确性的前提下。volatile能够在一定程度上禁止虚拟机进行指令重排。还有就是对于volatile变量的写操作,保证是在读操作之前完成,假设线程A来读变量,刚好线程B正在写变量,那么虚拟机会保证写在读之前完成。 比如:
private volatile boolean flag;
public void setFlag(boolean flag) {
this.flag = flag;
}
public void getFlag() {
return flag;
}
假设线程A来调用setFlag(true),线程B同时来调用getFlag,对于一般的变量,是无法保证B能读到A设置的值的,因为它们执行的顺序是未知的。但是像上面,加上volatile修饰以后,虚拟机会保证,线程A的写操作在线程B的读操作之前完成,换句话,B能读到最新的值。当然了,用锁机制也能达到同样的效果,比如在方法前面都加上synchronized关键字,但是性能会远不如使用volatile。
volatile的典型使用场景
多线程情况下的标志位
基于它的作用,不难找到使用它的理想场景:
● 读操作,多于写操作
● 写操作,不依赖于变量的当前值,也就是说要是纯赋值操作
● 只需要读取的值,不需要等待某一特定的值
比如,有一个检查新版本的按扭,点击时会发起去检查新版本,因为检查新版本涉及网络请求,可能会比较耗时,所以需要放在单独的线程中去做。为了避免多次同时触发检查请求,做一个限制:上一个请求没有完成时,再次点击无效。这时就可以用volatile来做个标志位,伪代码如下:
private volatile boolean checkUpdateFinished = true;
public void onCheckUpdate(View view) {
if (!checkUpdateFinished) {
return;
}
checkUpdate();
}
private void checkUpdate() {
checkUpdateFinished = false;
new Thread(new Runnable() {
@Override
public void run() {
doCheckUpdate();
checkUpdateFinished = true;
}
}).start();
}
CAS无锁同步的变量声明
CAS(Compare And Swap)是一种无锁同步的算法,它涉及变量的3个值,当前值,旧的期望值以及新的期望值,它的原理是当且仅当当前值与旧的期望值一致时,才把新值赋给变量,否则什么都不做:
private volatile int a;
do {
old = 3;
expected = 5;
} while (compareAndSwap(a, 3, 5);
boolean compareAndSwap(int a, int old, int expected) {
if (a == old) {
a = expected;
return true;
}
return false;
}
当然,具体的compare and swap不是这么实现的,实际是要直接使用处理的指令CMPXCHG(Compare and Exchange)来做具体的CAS。 为了保证可见性,CAS中的变量必须都用volatile来修饰。
volatile的内存原理
知道了volatile有什么用,怎么用以后,可以了解的更深一点,以加深理解。但要搞懂,就必须先要搞懂它的背景以及背景的背景:
并发的基本概念
原子性
一个或者多个操作(赋值也好,运算也好)不能被线程调度打断,要么一次性执行完,要么就不执行。
可见性
现代处理器是多核心的,或者多CPU的,但是主存(通常意义上的操作系统内存,或者物理内存)却是在CPU之间共享的。多核心处理的优势在于,从机器级别支持多线程并发,而且为了弥补主存与CPU核心之间的速度差异,便有了CPU核心缓存,因此,每个CPU核心(或者说每个线程)是有独立的内存的。这样就带来了可见性的问题,同一个变量c,A线程操作的是c在A线程的缓存中的值,B操作的是c在B的缓存中值,也就是说最新的变量的值对于其他线程是不可见的,这就有了可见性的问题。
有序性
对于单线程来说,程序的执行顺序就是按照代码的书写顺序,从上到下,从左到右(分号分隔写在同一行时)。但是多线程情况就不一定了,线程调度器随时可能打断某一程,执行其他线程。这就导致了,程序并不是按照预期的顺序执行的,导致结果跟预期不一致。 注意:这里的顺序,并不是严格的指令执行的顺序,而且从结果正确性的角度来看的,比如:
int a = 10;
int b = a + 1;
这段代码的有序性的意思是:
- 当执行到第二条语句,只要a的值是10就可以了,至于a = 10它究竟是否是在下面语句前执行,并不关心。
- 但是,除了a = 10语句外,没有其他的方式能让a变成10,所以,肯定是执行了语句了才能把a变成10。说起来比较绕,这个例子也过于简单。
- 可以这么简单的理解为:单线程情况下,程序是按书写的顺序来执行的,更准确的说法是程序员预期的顺序来执行的。但多线程会打破这种有序性。
注意:这里我们不考虑ABA问题。
对内存模型的理解
什么是内存模型呢?就是程序运行起来时,内存里面的样子。
- 程序包括变量,对象,数据,指令等,程序动起来后又包括变量如何赋值,数据如何读取,指令按什么顺序执行等。
- 其实,程序运行时,内存是什么样子,通常取决于操作系统,也就是说是由操作系统决定的。
- Java是跨平台的语言,其靠着“Compile once, run anywhere"的大旗,拮杆而起,打下一片天下,如今稳坐头把交椅。那么,想要跨平台,它就要屏蔽各个操作系统平台和硬件平台的差异,因此它有虚拟机,
- 虚拟机实质是一对操作系统的一个抽象,把差异进行屏蔽,从而对语言本身来说,所有操作系统就都是一样的了。
内存模型,也就是虚拟机对运行时的一些约定,或者叫做强制规定,比如变量的操作,数据的读取,指令执行顺序等。都做了哪些规定呢?我们分别来说:
线程模型
因为Java天生支持多线程,所以,虚拟机也必须要有线程模型,否则就无法屏蔽操作系统的差异。虚拟机规定,所有的变量都存储在主存中,也就是通常所指的内存,每个线程可以有自己的独立的工作内存,可以理解为每个CPU核心的缓存,线程对变量的操作都只能在自己的工作内存中,不能直接对主存操作,也不能访问其他线程的工作内存。
原子性操作
虚拟机保证对基本的基本数据类型的赋值是原子的,比如int,boolean和float。但是像long和double不一定,这取决于CPU的字长,32位下,long和double的赋值不是原子的,因为需要二个指令;而64位CPU则一个指令搞定。
如何保证原子性呢?方式一是上面提过的用volatile,另外就是用同步锁机制。
可见性
前面说到每个CPU可以有自己的工作内存,因此,当一个线程对某一变量操作后,其他线程是没有办法直接拿到最新变化的。
如何保证可见性呢?方法一就是把变量用volatile修饰,另外就是用同步锁机制。
指令重排与happens-before原则
指令重排与happens-before原因,是不同的,也是不冲突的。正常情况下,也就是说单线程情况下,指令的执行顺序是按书写顺序从上到下,但不是严格的,虚拟机会在不影响程序结果正确性的前提下对指令进行重排,比如:
int a = 1;
int b = 2;
int c = 3;
这三个指令,哪个先执行,是不会影响程序结果的,这时指令可能重排;而再如:
int a = 1;
int b = a + 1;
int c = a + b;
这种情况下,是无法重排,不可能把第3句放到前面,那样会得不到正确的结果。
而happens-before是指在多线程情况下,虚拟机来保证某些操作的先后性,或者说前面的操作结果,对后面是可见的。比如上面的第二个例子,在多线程情况下,c = a + b是有可能在a, b赋值前执行的,这也恰 恰是我们需要小心解决的由多线程机制带来的问题。
虚拟机的默认支持的happens-before(先行发生)原则:
- 程序次序规则:一个线程内,按照代码顺序,书写在前面的操作先行发生于书写在后面的操作
- 锁定规则:一个unLock操作先行发生于后面对同一个锁额lock操作
- volatile变量规则:对一个变量的写操作先行发生于后面对这个变量的读操作
- 传递规则:如果操作A先行发生于操作B,而操作B又先行发生于操作C,则可以得出操作A先行发生于操作C
- 线程启动规则:Thread对象的start()方法先行发生于此线程的每个一个动作
- 线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
- 线程终结规则:线程中所有的操作都先行发生于线程的终止检测,我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行
- 对象终结规则:一个对象的初始化完成先行发生于他的finalize()方法的开始
- 锁定规则:一个unLock操作先行发生于后面对同一个锁额lock操作
很多规则显而易见的,或者想一下还是很容易想通的,重点解析一下第2, 3, 4条:
这里的意思是,同一个锁(lock),如果处于锁定状态,那么只能先释放锁,然后才能被再次锁定。这么一说就明白了,这是显而易见的,要不然锁不就失去它本身的作用了么。
注意:这里有必要进一步说明一下,对于可重入锁,这里应该指的就是其他线程再次获得锁之前,锁必须被释放。因为对于可重入锁,锁的持有线程,是可以在不释放的前提下,继续获得锁的。
volatile变量规则
对一个变量的写操作先行发生于后面对这个变量的读操作
这里其实有二层,一个是前面提过的,读volatile总是能读到最新的值,即使是写线程和读线程同时进行。因为,写操作会被更新到主存,读线程的工作内存会被置为无效,需要重新到主存去读,而读主存的地址,是要等待该地址更新后才能成功读取。
另外,一个就是对于volatile上下文的变量的读写的影响,也就是说它为什么能禁止指令重排:volatile的准确可见性作用是,当一个线程写一个volatile变量时,写完成后会刷新工作内存到主存,这会把目前这个线程所做过修改的所有变量都刷新到主存。举个例子来说明:
int a;
int b;
volatile boolean flag;
void write() {
a = 3;
b = 4;
flag = true;
}
void read() {
print(a);
print(b);
print(flag);
}
如果线程A调用write(),线程B调用read(),那么B能读到a, b和flag的最新值(A所写的值)。
由此,可以引申出一个volatile的高级应用,可以当作同步锁:
private Object object = null;
private volatile hasNewObject = false;
public void put(Object newObject) {
while (hasNewObject) {
//wait - do not overwrite existing new object
}
object = newObject;
hasNewObject = true; //volatile write
}
public Object take() {
while (!hasNewObject) { //volatile read
//wait - don't take old object (or null)
}
Object obj = object;
hasNewObject = false; //volatile write
return obj;
}
因为写hasNewObject时会把object也刷新了,所以取对象的线程,可以在只要hasNewObject为true时就可以读到正确的值。
传递规则
如果操作A先行发生于操作B,而操作B又先行发生于操作C,则可以得出操作A先行发生
这个就像某些运行符的传递性一样,具体传递性,从而使整个happens-before规则产生实际作用。
volatile的实现机制
计算机科学里面,为了解决复杂性,都会分层。正如一个名人所说:“计算机的任何问题都可以通过增加一个虚拟层来解决”(“All problems in computer science can be solved by another level of indirection”)。volatile虚拟机层引入的,解决语言层面的问题,那么它的实现,必然是靠下一层的支持,也就是需要汇编或者说处理器指令的支持来实现,volatile是靠内存屏障和MESI(缓存一致性协议)来达成的它的作用的。
内存屏障(Memory Barriers)
内存屏障(Memory Barriers)是处理器提供的一组内存操作指令,它的作用是限制内存操作的顺序,也就是说内存屏障像一个栅栏一样,它前面的指令要在它后面的指令之前完成;还能强制把缓存写入到主存;再有的就是触发缓存一致性,就是当有写变量时,会把其他CPU核心的缓存变为无效。
深入剖析volatile关键字
在前面讲述了很多东西,其实都是为讲述volatile关键字作铺垫,那么接下来我们就进入主题。
volatile关键字的两层语义
一旦一个共享变量(类的成员变量、类的静态成员变量)被volatile修饰之后,那么就具备了两层语义:
- 保证了不同线程对这个变量进行操作时的可见性,即一个线程修改了某个变量的值,这新值对其他线程来说是立即可见的。
- 禁止进行指令重排序。
先看一段代码,假如线程1先执行,线程2后执行:
//线程1
boolean stop = false;
while(!stop){
doSomething();
}
//线程2
stop = true;
这段代码是很典型的一段代码,很多人在中断线程时可能都会采用这种标记办法。但是事实上,这段代码会完全运行正确么?即一定会将线程中断么?不一定,也许在大多数时候,这个代码能够把线程中断,但是也有可能会导致无法中断线程(虽然这个可能性很小,但是只要一旦发生这种情况就会造成死循环了)。
下面解释一下这段代码为何有可能导致无法中断线程。
- 在前面已经解释过,每个线程在运行过程中都有自己的工作内存,那么线程1在运行的时候,会将stop变量的值拷贝一份放在自己的工作内存当中。
- 那么当线程2更改了stop变量的值之后,但是还没来得及写入主存当中,线程2转去做其他事情了,那么线程1由于不知道线程2对stop变量的更改,因此还会一直循环下去。
但是用volatile修饰
之后就变得不一样了:
- 使用volatile关键字会强制将修改的值立即写入主存;
- 使用volatile关键字的话,当线程2进行修改时,会导致线程1的工作内存中缓存变量stop的缓存行无效(反映到硬件层的话,就是CPU的L1或者L2缓存中对应的缓存行无效);
- 由于线程1的工作内存中缓存变量stop的缓存行无效,所以线程1再次读取变量stop的值时会去主存读取。
那么在线程2修改stop值时(当然这里包括2个操作,修改线程2工作内存中的值,然后将修改后的值写入内存),会使得线程1的工作内存中缓存变量stop的缓存行无效,然后线程1读取时,发现自己的缓存行无效,它会等待缓存行对应的主存地址被更新之后,然后去对应的主存读取最新的值。
那么线程1读取到的就是最新的正确的值。
volatile保证原子性吗?
从上面知道volatile关键字保证了操作的可见性,但是volatile能保证对变量的操作是原子性吗?
下面看一个例子:
public class Test {
public volatile int inc = 0;
public void increase() {
inc++;
}
public static void main(String[] args) {
final Test test = new Test();
for(int i=0;i<10;i++){
new Thread(){
public void run() {
for(int j=0;j<1000;j++)
test.increase();
};
}.start();
}
while(Thread.activeCount()>1) //保证前面的线程都执行完
Thread.yield();
System.out.println(test.inc);
}
}
大家想一下这段程序的输出结果是多少?也许有些朋友认为是10000。但是事实上运行它会发现每次运行结果都不一致,都是一个小于10000的数字。
可能有的朋友就会有疑问,不对啊,上面是对变量inc进行自增操作,由于volatile保证了可见性,那么在每个线程中对inc自增完之后,在其他线程中都能看到修改后的值啊,所以有10个线程分别进行了1000次操作,那么最终inc的值应该是1000*10=10000。
这里面就有一个误区了,volatile关键字能保证可见性没有错,但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值,但是volatile没办法保证对变量的操作的原子性。
在前面已经提到过,自增操作是不具备原子性的,它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行,就有可能导致下面这种情况出现:
假如某个时刻变量inc的值为10,步骤如下
- 线程1对变量进行自增操作,线程1先读取了变量inc的原始值,然后线程1被阻塞了;
- 然后线程2对变量进行自增操作,线程2也去读取变量inc的原始值,由于线程1只是对变量inc进行读取操作,而没有对变量进行修改操作,所以不会导致线程2的工作内存中缓存变量inc的缓存行无效,所以线程2会直接去主存读取inc的值,发现inc的值时10,然后进行加1操作,并把11写入工作内存,最后写入主存。
- 然后线程1接着进行加1操作,由于已经读取了inc的值,注意此时在线程1的工作内存中inc的值仍然为10,所以线程1对inc进行加1操作后inc的值为11,然后将11写入工作内存,最后写入主存。
- 那么两个线程分别进行了一次自增操作后,inc只增加了1。
解释到这里,可能有朋友会有疑问,不对啊,前面不是保证一个变量在修改volatile变量时,会让缓存行无效吗?然后其他线程去读就会读到新的值,对,这个没错。这个就是上面的happens-before规则中的volatile变量规则,但是要注意,线程1对变量进行读取操作之后,被阻塞了的话,并没有对inc值进行修改。然后虽然volatile能保证线程2对变量inc的值读取是从内存中读取的,但是线程1没有进行修改,所以线程2根本就不会看到修改的值。
根源就在这里,自增操作不是原子性操作,而且volatile也无法保证对变量的任何操作都是原子性的。
把上面的代码改成以下任何一种都可以达到效果:
采用synchronized
public class Test {
public int inc = 0;
public synchronized void increase() {
inc++;
}
public static void main(String[] args) {
final Test test = new Test();
for(int i=0;i<10;i++){
new Thread(){
public void run() {
for(int j=0;j<1000;j++)
test.increase();
};
}.start();
}
while(Thread.activeCount()>1) //保证前面的线程都执行完
Thread.yield();
System.out.println(test.inc);
}
}
采用Lock
public class Test {
public int inc = 0;
Lock lock = new ReentrantLock();
public void increase() {
lock.lock();
try {
inc++;
} finally{
lock.unlock();
}
}
public static void main(String[] args) {
final Test test = new Test();
for(int i=0;i<10;i++){
new Thread(){
public void run() {
for(int j=0;j<1000;j++)
test.increase();
};
}.start();
}
while(Thread.activeCount()>1) //保证前面的线程都执行完
Thread.yield();
System.out.println(test.inc);
}
}
采用AtomicInteger
public class Test {
public AtomicInteger inc = new AtomicInteger();
public void increase() {
inc.getAndIncrement();
}
public static void main(String[] args) {
final Test test = new Test();
for(int i=0;i<10;i++){
new Thread(){
public void run() {
for(int j=0;j<1000;j++)
test.increase();
};
}.start();
}
while(Thread.activeCount()>1) //保证前面的线程都执行完
Thread.yield();
System.out.println(test.inc);
}
}
在java 1.5的java.util.concurrent.atomic包下提供了一些原子操作类,即对基本数据类型的 自增(加1操作),自减(减1操作)、以及加法操作(加一个数),减法操作(减一个数)进行了封装,保证这些操作是原子性操作。atomic是利用CAS来实现原子性操作的(Compare And Swap),CAS实际上是利用处理器提供的CMPXCHG指令实现的,而处理器执行CMPXCHG指令是一个原子性操作。
volatile能保证有序性吗?
在前面提到volatile关键字能禁止指令重排序,所以volatile能在一定程度上保证有序性。
volatile关键字禁止指令重排序有两层意思:
- 当程序执行到volatile变量的读操作或者写操作时,在其前面的操作的更改肯定全部已经进行,且结果已经对后面的操作可见;在其后面的操作肯定还没有进行;
- 在进行指令优化时,不能将在对volatile变量访问的语句放在其后面执行,也不能把volatile变量后面的语句放到其前面执行。
可能上面说的比较绕,举个简单的例子:
//x、y为非volatile变量
//flag为volatile变量
x = 2; //语句1
y = 0; //语句2
flag = true; //语句3
x = 4; //语句4
y = -1; //语句5
由于flag变量为volatile变量,那么在进行指令重排序的过程的时候,不会将语句3放到语句1、语句2前面,也不会讲语句3放到语句4、语句5后面。但是要注意语句1和语句2的顺序、语句4和语句5的顺序是不作任何保证的。
并且volatile关键字能保证,执行到语句3时,语句1和语句2必定是执行完毕了的,且语句1和语句2的执行结果对语句3、语句4、语句5是可见的。
那么我们回到前面举的一个例子:
/线程1:
context = loadContext(); //语句1
inited = true; //语句2
//线程2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);
前面举这个例子的时候,提到有可能语句2会在语句1之前执行,那么久可能导致context还没被初始化,而线程2中就使用未初始化的context去进行操作,导致程序出错。
这里如果用volatile关键字对inited变量进行修饰,就不会出现这种问题了,因为当执行到语句2时,必定能保证context已经初始化完毕。
volatile的原理和实现机制
前面讲述了源于volatile关键字的一些使用,下面我们来探讨一下volatile到底如何保证可见性和禁止指令重排序的。
下面这段话摘自《深入理解Java虚拟机》:
“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现,加入volatile关键字时,会多出一个lock前缀指令”
lock前缀指令实际上相当于一个内存屏障(也成内存栅栏),内存屏障会提供3个功能:
- 它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置,也不会把前面的指令排到内存屏障的后面;即在执行到内存屏障这句指令时,在它前面的操作已经全部完成;
- 它会强制将对缓存的修改操作立即写入主存;
- 如果是写操作,它会导致其他CPU中对应的缓存行无效。
总结
volatile是一个比较复杂的修饰符,想要使用它,就要完全理解它的作用,它能用来做什么,以及不能干什么。如果,不是很确定,要么弄懂,要么就不要使用。事实上,大多数情况下,标志变量,还是非常适合volatile的。
java.util.concurrent.*里面的高级线程安全数据结构像ConcurrentHashMap以及java.util.concurrent.atomic.*等的实现都用到了volatile。
关注林哥,持续更新哦!!!★,°:.☆( ̄▽ ̄)/$:.°★ 。