重排序
在Java中,所有实例域、静态域和数组元素都存储在堆内存中,堆内存在线程之间共享 。局部变量(Local Variables),方法定义参数(Java语言规范称之为Formal Method Parameters)和异常处理器参数(ExceptionHandler Parameters)不会在线程之间共享 ,它们不会有内存可见性问题,也不受内存模型的影响。 从图来看,如果线程A与线程B之间要通信的话,必须要经历下面2个步骤。 1线程A把本地内存A中更新过的共享变量刷新到主内存中去。 2)线程B到主内存中去读取线程A之前已更新过的共享变量。 在执行程序时,为了提高性能,编译器和处理器常常会对指合做重排序。重排序分3种类 型。
编译器优化的重排序 。编译器在不改变单线程程序语义的前提下 ,可以重新安排语句的执行顺序。指合级并行的重排序 。现代处理器采用了指命级并行技术(Instruction-LevelParallelism,ILP)来将多条指命重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指爷的执行顺序。内存系统的重排序 。由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。
数据依赖性
编译器和处理器不会对存在数据依赖关系的操作做重排序 ,因为这种重排序会改变执行结果。但是,如果操作之间不存在数据依赖关系,这些操作就可能被编译器和处理器重排序。所谓数据依赖性就是比如俩个操作同时操作一个变量, 并且只要有一个是写操作, 那这俩个操作就存在数据依赖性 这里所说的数据依赖性仅针对单个处理器中执行的指命序列和单个线程中执行的操作,不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。
重排序对多线程的影响
class Service {
private int a= 0 ;
private boolean flag= false ;
public void write ( ) {
a = 1 ;
flag= true ;
}
public int read ( ) {
int i = 0 ;
if ( flag) {
i = a * a;
}
return i;
}
}
key是一个标记, 用来判断i是否被写入, 如果此时有俩个线程, A首先执行write操作, B执行read操作, 那线程B在执行4操作 , 也就是读取i的值 是否是已经写入的呢? 这个答案的否定的 由于操作1和操作2没有数据依赖的关系, 编译器和处理器可能会对这俩个操作进行重排序, 然后就会出现下面的问题
这时你会发现, 他是先置flag为true , 那么线程B就会判断为true, 所以线程B在读取a的值有可能就会读到脏数据 再看当三四操作的指令重排序 三四操作存在控制依赖关系, 会影响执行序列的执行并行度, 但是在编译器在进行调优重排序的时候, 是不鸟他的, 所以上图中线程B读取到的a值, 还是一个脏数据
如果解决?
使用同步程序达到一致性效果, 简单来说就是直接咔咔上锁
class Service {
private int i = 0 ;
private boolean key = false ;
public synchronized void write ( ) {
i = 1 ;
key = true ;
}
public synchronized int read ( ) {
int a = 0 ;
if ( key) {
a = i * i;
}
return a;
}
}
在同步程序中, 这俩个write和read就成了同步方法, 也就是他们会串行执行, 这样即使在一个方法内发生了重排序, 对另一个线程来说是没有影响的
volatile域的重排序规则
volatile修饰的变量只是保证内存可见性, 也就是只是说你这个线程读到的数据一定是从内存中读出来的. 但是他并不是原子的, 如果你在多线程环境下进行运算, 依旧不是安全的. 所以volatile域就会有重排序规则 上图中, 我们可以发现
当第二个操作是volatile写时,不管第一个操作是什么,都不能重排序。这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后。 当第一个操作是volatile读时,不管第二个操作是什么,都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。 当第一个操作是volatile写,第二个操作是volatile读时,不能重排序。
总而言之就是在单个volatile写之前和读之后是绝对不让重排序的, 俩个操作都是volatile操作 ,是更是不让重排序的, 写之前 读之后
final域的重排序规则
对于final域,编译器和处理器要遵守两个重排序规则。
在构造函数内对一个final域的写入,与随后把这个被构造对象的引用赋值给一个引用 变量,这两个操作之间不能重排序。 初次读一个包含final域的对象的引用,与随后初次读这个final域,这两个操作之间不能 重排序。
class FinalExample {
int i;
final int j;
static FinalExample obj;
public FinalExample ( ) {
this . i = 1 ;
this . j = 2 ;
}
public static void write ( ) {
obj = new FinalExample ( ) ;
}
public static void read ( ) {
FinalExample object = obj;
int a = object. i;
int b = object. j;
}
}
写final域的重排序规则
写final域的重排序规则禁止把final域的写重排序到构造函数之外 。这个规则的实现包含下面2个方面。
JMM禁止编译器把final域的写重排序到构造函数之外。 编译器会在final域的写之后,构造函数return之前,插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外。
现在让我们分析writer()方法。writer()方法只包含一行代码:finalExample=new FinalExample()。这行代码包含两个步骤,如下。 1)构造一个FinalExample类型的对象。 2)把这个对象的引用赋值给引用变量obj 上图我们发现写普通域的操作被编译器重排序到了构造函数之外,读线程B错误地读取了 普通变量i初始化之前的值。而写final域的操作,被写final域的重排序规则“限定”在了构造函数 之内,读线程B正确地读取了final变量初始化之后的值。 写final域的重排序规则可以确保:在对象引用为任意线程可见之前,对象的final域已经被 正确初始化过了,而普通域不具有这个保障。
读final域的重排序规则
读final域的重排序规则是,在一个线程中,初次读对象引用与初次读该对象包含的final域, 这俩个操作是不让重排序的 reader()方法包含3个操作。 1· 初次读引用变量obj。 2· 初次读引用变量obj指向对象的普通域j。 3· 初次读引用变量obj指向对象的final域i。 读对象的普通域的操作被处理器重排序到读对象引用之前 。读普通域时,该 域还没有被写线程A写入,这是一个错误的读取操作。而读final域的重排序规则会把读对象 final域的操作“限定”在读对象引用之后,此时该final域已经被A线程初始化过了,这是一个正 确的读取操作.读final域的重排序规则可以确保:在读一个对象的final域之前,一定会先读包含这个final 域的对象的引用。如果该引用不为null,那么引用对象的final域一定已经被初始化过了。
如果final域修饰的是引用类型
class FinalReferenceExample {
final int [ ] array;
static FinalReferenceExample obj;
private FinalReferenceExample ( ) {
array = new int [ 1 ] ;
array[ 0 ] = 1 ;
}
public static void writeOne ( ) {
obj = new FinalReferenceExample ( ) ;
}
public static void writeTwo ( ) {
obj. array[ 0 ] = 2 ;
}
public static void read ( ) {
if ( obj != null) {
System. out. println ( obj. array[ 0 ] ) ;
}
}
}
final域为一个引用类型,它引用一个int型的数组对象。对于引用类型,写final域的重 排序规则对编译器和处理器增加了如下约束:在构造函数内对一个final引用的对象的初始化, 和将初始化后的这个对象的地址赋值给final域修饰的引用,这两个操作之间不能重排序。 就如上图所示, 我们前面说到写final域一定是在构造函数结束前执行的, 并且是不可以重排序的, 在这里包括初始化final引用的这个对象, 和将这个对象赋值给array这个引用, 包括下面给array[0]的写入, 都是不可以重排序的. 总之final域的写重排序规则就是确保你在访问我这个final域的时候, 我是完好无损的, 是可以直接使用的.