Java笔记 ·

并发学习笔记09-final域的内存语义

并发学习系列以阅读《Java并发编程的艺术》一书的笔记为蓝本,汇集一些阅读过程中找到的解惑资料而成。这是一个边看边写的系列,有兴趣的也可以先自行购买此书学习。

重排序规则

final域,编译器和处理器要遵守两个重排序规则:
- 在构造函数内对一个final域的写入,与随后把这个被构造对象的引用赋值给一个引用变量,这两个操作之间不能重排序。
- 初次读一个包含final域的引用,与随后初次读这个final域,这两个操作之间不能重排序。

写final域的重排序规则

写final域的重排序规则禁止把final域的写重排序到构建函数之外。其实现包含以下2个方面:
- JMM禁止编译器把final域的写重排序到构建函数之外。
- 编译器会在final域的写之后,构造函数return之前插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构建函数之外。

写final域的重排序规则可以确保:在对象引用为任意线程可见之前,对象的final域已经被正确初始化过了,而普通域不具有这个保障:
写普通域的操作可能会被编译器重排序到构建函数之外,而写final域的操作被写final域的重排序规则“限定”在了构造函数之内。

读final域的重排序规则

读final域的重排序规则是:
- 在一个线程中,初次读对象引用与初次读该对象包含的final域,JMM禁止处理器重排序这两个操作(该规则仅针对处理器)。
- 编译器会在读final域操作的前面插入一个LoadLoad屏障。

初次读对象引用与初次读该对象包含的final域,这两个操作之间存在间接依赖关系。由于编译器遵守间接依赖关系,因此编译器不会重排序这两个操作。大多数处理器也会遵守间接依赖,也不会重排序这两个操作。但有少数处理器允许对存在间接依赖关系的操作做重排序(比如alpha处理器),这个规则专门用来针对这种处理器的。

读final域的重排序规则可以确保:在读一个对象的final域之前,一定会先读包含这个final域的对象的引用。如果该引用不为null,则引用对象的final域一定被已经被初始化过了。

final域为引用类型

对于引用类型,写final域的重排序规则对编译器和处理器增加了如下约束:在构造函数内对一个final引用的对象的成员域的写入,与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量,这两个操作不能重排序。

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

写final域的重排序规则可以确保:在对象引用为任意线程可见之前,对象的final域已经在构造函数中被正确初始化过了。要到达该效果还需要一个保证:
在构造函数内部,不能让这个被构造对象的引用为其他线程所见,也就是对象引用不能在构造函数中“逸出”。

在构造函数返回之前,被构造对象的引用不能为其他线程所见,因为此时的final域可能还没被初始化。在构造函数返回后,任意线程都将保证能看到final域正确初始化之后的值。

final语义在处理器中的实现

以x86处理器为例来了解在处理器中的具体实现。

写final域的重排序会要求编译器在final域的写之后,构造函数return之前插入一个StoreStore屏障。读final域的重排序规则要求编译器在读final域的操作之前插入一个LoadLoad屏障。

  • 由于x86处理器不会对写-写操作做重排序,所以x86中,写final域需要的StoreStore屏障会被省略掉。
  • 由于x86处理器不会对存在间接依赖关系的操作做重排序,所以x86中,读final域需要的LoadLoad屏障会被省略掉。
  • 综上,x86中,final域的读/写不会插入任何内存屏障。

JSR-133增强final的语义

在旧的Java内存模型中,一个最严重的缺陷就是线程可能看到final域的值会改变。比如,一个线程当前看到一个整形final域的值为0(还未初始化之前的默认值),过了一段时间之后这个线程再去读这个final域的值时,发现变成了1(被某个线程初始化之后的值)。最常见的例子就是在旧的Java内存模型中,String的值可能会改变。

为了修复这个漏洞,JSR-133专家组增强了final的语义。通过为final域增加写和读的重排序规则,可以确为Java程序员提供初始化安全保证:只要对象是正确构造的(被构造对象的引用在构造函数中没有“逸出”),那么不需要使用同步(指lock和volatile的使用)就可以保证任意线程都可以看到这个final域在构造函数中被初始化之后的值。

参与评论