java基础(第二篇)java内存模型与线程安全问题
转载请联系作者获得授权并注明出处:
原文链接:http://www.jianshu.com/p/b9cabcc976b3
原文作者:wyn_lin
本文讲述java中并发编程的几个概念:java内存模型,原子性,重排序,可见性,以及探讨重排序导致的线程安全问题。
原子性是什么?
即使在多个线程一起执行的时候亦不可中断、不可分割的操作称为原子操作,一个操作如果是原子操作,我们就称它具有原子性。
那么,什么样的操作才是原子操作呢?
代码中的一条语句并不一定是原子操作,比如:i++语句不是原子操作,因为i++其实在计算机CPU中是拆分成多个如下操作:
- 读取内存中变量i
- 对i进行+1操作
- 将i+1后的结果存回内存
java字节码class在运行的时候会被解释成特定机器上的汇编指令。从汇编指令的角度看,每个原子操作对应一条汇编指令:
mov ax,[i] ; 将内存中的i的值读取到CPU内寄存器ax中
inc ax ; ax寄存器的值自加一
mov [i],ax ;将ax的内容存入i所在的地址的内存中
另外,java内存模型不保证64位的long和double类型的变量的写操作具有原子性,在不同的机器中处理器和总线的工作机制不同,比如32位机中,对64位的long和double的写可能被拆分成两个原子操作。
重排序
定义:重排序指的是在运行的过程中,指令没有按照编写的顺序依次执行,而是重新排序执行。
重排序有以下几种情况:
- 编译器重排序
- 指令级重排序
- 内存系统重排序
编译器重排序
在执行程序时,为了提高性能,编译器会对程序的字节码进行优化。对生成的机器指令进行重排序,以提高性能。
指令级重排序
程序解释出来的汇编指令实际上并不是按顺序执行的,现代CPU也会对解释的汇编指令进行重新排序,以充分利用CPU,提高CPU对程序的吞吐率,进而提高程序的运行效率。
内存系统重排序
在内存层面上,也是存在重排序,由于可见性问题,代码看上去好像在内存中发生了重排序。
从源码到最终执行的过程,各种重排序的顺序如下:
可见性是什么?
定义:可见性是指一个线程修改了某个共享的变量,在另一个线程中可立刻知道这个变量被修改。
多线程程序中一个线程对于共享变量的修改可能会导致不可见性。
没听说过可见性的可能会说多线程共享变量的修改,对其他线程不是可以感知到吗?既然是共享变量,为什么不能知道修改?请注意!定义中讲的是立刻,即使是共享变量也不一定是实时可见的。
请看代码:
public class TestMain {
public static void main(String[] args) throws Exception {
TestThread testThread = new TestThread();
testThread.start();
//睡眠1秒
Thread.sleep(1000);
//停止线程中的循环
testThread.stopSelf();
//睡眠5秒
Thread.sleep(5000);
System.out.println("testThread线程应该完成了");
System.out.println("isStoped: " + testThread.isStoped());
}
}
class TestThread extends Thread{
private boolean stoped = false;
@Override
public void run(){
int i = 0;
while (!stoped){
i++;
}
System.out.println("我已经完成循环i=" + i);
}
public void stopSelf(){
stoped = true;
}
public boolean isStoped(){
return stoped;
}
}
这段代码很短,线程TestThread
的run方法
中执行的是一个循环i++
操作,stoped属性为false
则一直死循环,在主线程中修改stoped的值,并且等待一段时间后,按理说testThread
线程会执行结束并打印i的值。
看运行结果吧:
结果只打印了主线程的中的提示语句,testThread
线程并没有打印出i,再看看结果图,运行图标还是爆红,并没有运行结束,testThread
还在运行,但是主线程打印的stoped
却是true
,这就是不可见性。
导致这个问题出现的原因是源于java中的内存模型。
java内存模型
java并发编程艺术书中内存模型的图java线程之间的通信是由java内存模型(业界称JMM)控制
主存(main memory),私有的本地内存(local memory),每个线程都拥有私有的本地内存,该内存持有一份主存变量的拷贝,线程在访问共享变量的时候,并不是直接从主存中装载,而是从本地内存中看有无该变量,若无则才从主存加载。本地内存是java内存模型的一个抽象概念,不真实存在。实际上物理上的结构是这样的:
CPU与主存之间存在一层高速缓冲存储器(cache),它位于CPU内部,是为了解决CPU与内存速度不匹配,从而提高运行速率。
但是在多核CPU计算机中每个CPU都有一个cache
,多个线程并发执行时会导致不可见性,这里用CPU/cache 重新解释一下之前的代码:
假设CPU 1 执行testThread线程
,CPU2 执行主线程,testThread线程
和主线程共享布尔变量stoped(初值为false);testThread线程
在CPU1中执行,因此CPU1中的cache保存有一份变量stoped的值,同时主线程在CPU2中的cache也保存有一份变量stoped的值。
刚开始是testThread线程
先对stoped
进行判断是否为false
然后执行i++
操作,在CPU2中的主线程对stoped进行赋值true
操作;然后CPU2将改变后的值写回主存,但是testThread线程
在CPU1运行,并没有感知到这个变化,缓冲区中的stoped
没有被改变所以一直沿用,才导致死循环一直执行。
要使得共享变量对于不同线程的一致性,java中引入了一个关键字:volatile
。通过在上面代码实例中stoped
属性的声明处加volatile
修饰,即可解决不可见性问题。
private volatile boolean stoped = false;
运行结果:
volatile
修饰的属性,会在每次修改之后立即通知其他CPU更新该属性的缓存。这样就保证了可见性。
可以将volatile
看成一个锁,对单个读写操作进行同步,对于64位的long和double即使不是原子操作,也会实现同步使其写操作具有原子性。对于其他类型变量的修改也是可以将整个修改的过程看成一个临界区,临界区中的指令都是同步执行的,线程对于volatile
变量的读和写都要先拿到这个volatile
锁,一旦一个线程修改内存中共享变量,另一个线程如果要读这个共享变量在缓存区中的值,需要先判断volatile
锁的有效性,即需满足内存可见性。从底层讲,volatile修饰的变量在写入CPU寄存器的指令之后插入一条强制写回主存的LOCK指令,并促使其他CPU刷新缓存。
探讨如何防止重排序的发生
为什么要防止重排序?因为对于编译器和处理器的重排序,有时会导致不可见性,并可能导致线程不安全。
你写的代码,CPU不能知道你对于执行顺序的要求,它会尽可能的借助重排序实现优化,遵循as-if-serial语义
,即所有的指令动作都可以为了优化而被重排序。
重排序机制的存在,必须有一套防止重排序的语义机制,因为有些时候,程序员需要保证某些指令的同步执行,不能任由编译器或CPU随意优化。as-if-serial
语义的原则是单线程中重排序不会发生在有数据依赖的操作中,比如前面的指令inc ax
依赖于mov ax,[i]
,编译器和CPU对于这类指令不会进行重排序。但是对于如下的代码,不同线程间就没有保证不发生重排序。
public class TestMain {
static int x = 0, y = 0;
static int a = 0, b = 0;
public static void main(String[] args) throws InterruptedException {
Thread one = new Thread(new Runnable() {
public void run() {
a = 1;
x = b;
}
});
Thread other = new Thread(new Runnable() {
public void run() {
b = 1;
y = a;
}
});
one.start();
other.start();
one.join();
other.join();
System.out.println(" ("+x + ","+y + ")");
}
}
最终x,y的结果可能是(1,0)、(0,1)、(1,1)和(0,0),对于前三种运行结果,可能你知道为什么,但为什么会出现(0,0)的结果呢?(0,0)结果出现可能的执行顺序是这样的
初始化a = 0,b=0,x=0,y=0
1. x = b
2. y = a
3. a = 1
4. b = 1
首先你可能会认为,x=b的执行是会在a=1之后才执行的,因为线程中的代码就是顺序执行的嘛,但是其实这种想法是错误的,重排序机制的存在,编译器和处理器认为在线程one
和线程other
中不存在数据依赖,因此可能对其进行重排序,使得线程中的代码在CPU中实际执行的顺序并不是按顺序执行,在单线程程序中这个问题可能无法发现,但是多线程共享变量的时候就可能会暴露出这个问题。出现(0,0)结果的具体原因如下:
处理器A将共享变量a=0和x=0写入自己的缓冲区,处理器B将共享变量b=0,y=0写入自己的缓冲区中,然后处理器A先执行x=b,会从内存中读入b=0,然后x便被赋值为0,然后处理器B先执行y=a,从内存中读入a=0,使得y被赋值为0,最后AB各自执行a=1,b=1。主线程打印出来的x=0,y=0
。
java编译器为了保证数据可见性,在生成机器指令时,会在适当的位置插入内存屏障
指令来防止特定类型的处理器进行重排序。内存屏障分为四种:
java内存模型中的happens-before
jdk5中引入的新的内存模型JSR-133内存模型
,它使用happens-before
来阐述内存可见性,在内存模型中,如果一个操作的执行结果需要对另一个操作可见,那么这两个操作之间就必须存在happens-before关系,存在的happens-before
关系,并不要求两个操作一定是先后执行的关系。
编译器就会做一些内存屏障等操作防止重排序,从而保证happens-before关系,happen-before的两个操作可以是同一个线程内,也可以是不同线程之间。
以下是happens-before
的一些规则,当然,规范中不止这些规则,只是提出一些与程序员相关的规则。
- 程序顺序规则:一个线程的每个操作happens-before于该线程中的任意后续操作
- 监视器锁规则:对于一个锁的解锁,happens-before于随后对这个锁的加锁。
- volatile变量规则:对一个
volatile
变量的写,happens-before
于任意后续对这个volatile
变量的读 - 传递性:如果A
happens-before
B,且 Bhappens-before
C,那么Ahappens-before
C
参考
- 《java并发编程艺术》
- tech.meituan.com/java-memory-reordering.html
对你若有帮助,欢迎点赞和关注