java final 并发_《Java并发编程的艺术》之final

final的重排序规则

以下面的代码为例,讲解final写和final读的重排序规则

public FinalExample{

int a;

final int b;

private static FinalExample self;

private FinalExample(){

this.a = 1;

this.b = 5;

}

public static FinalExample init(){ //线程A执行

self = new FinalExample();

}

public static void read(){ //线程B执行

FinalExample temp = self; // 获取引用

int resultA = temp.a; // 读普通域

int resultB = temp.b; // 读final域

}

}

final写的重排序规则

JMM保证写final变量时不被编译器重排序到构造函数外

编译器会在写final域后,构造函数返回前插入StoreStore屏障

假设现在线程A执行init(),线程B执行read()时,可能的执行顺序如下所示:

0a27496a627d48e75b7f16c8977347c3.png

当A线程初始化构造函数的时候,有可能会将普通域的初始化重排序到构造函数外,所以当B线程读取普通域的时候很可能获取到0,但是在后续的执行中,该值又会变成给定的数值1。

而编译器在遇到final域时,会在final写后面加入StoreStore内存屏障,保证在结束函数构造前执行final写。

final域可以保证任何线程在读取该final变量时,已经正确初始化过。

final读的重排序规则

在讲final写的重排序规则时,着重点放在了写上。而final域在读方面也做了一些特别处理。通常情况下,一个获取对象的引用和读取该对象的普通域是可能发生重排序。所以可能会发生下面这样的执行顺序:

1f04ce0b1a9fe0308a22bd666f9c8afc.png

read()方法乍一看好像不会发生重排序,因为resultA 的写好像依赖temp变量。而resultA实际上是依赖temp引用里的a变量,间接依赖temp对象。虽然有的处理器不会对间接依赖进行重排序,但是不乏万一,比如alpha处理器,JMM就是为了避免这种会重排序间接依赖的处理器,所以给final读加上了下面的重排序规则:

JMM保证 初次读对象引用与初次读该对象的final域不会被重排序

编译器会在读final域的前面插入LoadLoad屏障

final域为引用类型

在构造函数内对一个final引用的对象的成员的写入,与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量,这两个操作不能重排序。

final引用不能从构造函数内“溢出”

写final的重排序规则虽然保证了,final域的写会在构造函数执行之前完成,并对其他线程可见。但是如果在构造函数内,引用就发生了溢出,那么就无法保证了

public EscapeFinalExample{

int a;

final int b;

private static EscapeFinalExample self;

private EscapeFinalExample(){

this.a = 1;

this.b = 5;

self = this; // this引用溢出

}

public static EscapeFinalExample init(){ //线程A执行

new EscapeFinalExample();

}

public static void read(){ //线程B执行

EscapeFinalExample temp = self; // 获取引用

int resultA = temp.a; // 读普通域

int resultB = temp.b; // 读final域

}

}

假设线程A执行init(),线程B执行read(),这里的A线程还未完成完整的初始化方法,对象引用就被B可见了。即使代码上 this溢出操作放在最后,仍然有可能被重排序。它们的执行时序如下所示:

bd5ef6a1fa35f8d32222596f8dd5a9d8.png

上图可以看出,构造函数还没有完成时,final域对其他线程不可见。只有在完成了构造函数后,final域才对其他线程可见。

final语义的特殊例子

在X86处理器上,由于不会发生写写、读写、读读的重排序,所以没有StoreStore内存指令,故在使用final时,编译器会忽略StoreStore内存屏障,同样LoadLoad内存屏障也会被忽略。也就是说,在x86处理器上,final是不做任何处理的。

为什么要增强final语义呢

一方面是final本身是不可修改的,其他线程不该看到final的变化。比如一开始线程读取final值为默认值0,过一段时间再读这个final变量,final值变为值1(被初始化后)。

所以新的模型就保证了,只要正确的完成构造函数(不发生this溢出),即使不用同步,也可以保证其他线程见到final初始化后的值。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值