并发学习笔记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域在构造函数中被初始化之后的值。