final域的内存语义

与volatile和锁相比，对final域的读和写更像是普通变量的访问

final域的重排序规则

对final域，编译器和处理器要遵守两个重排序规则

• 在构造函数内对一个final域的写入，与随后把这个被构造对象引用的赋值给一个引用变量，这两个操作之间不能重排序。
• 初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序。

写final域的重排序规则

写final域的重排序规则禁止把final域的写重排序到构造函数之外。这个规则的实现包含下面两个方面：

• JMM禁止编译器把final域的写重排序到构造函数之外
• 编译器会把final域的写之后，构造函数之前，插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外

读final域的重排序规则

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

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

final域为引用类型

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

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

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

final语义在处理器中的实现。

上面提到，写final域的重排序规则要求编译器在final域写之后，构造函数return之前插入一个StoreStroe屏障。读final域的重排序规则要求编译器在读final域操作前面插入一个LoadLoad屏障。
X86处理器中，final域的读/写不会插入任何内存屏障（因为X86不会对final域的写-写重排序，也不会对存在间接依赖关系的操作做重排序）

JSR-133为什么要增强final的语义

在旧的Java内存模型中，一个最严重的缺陷就是线程kennel看到final域的值会改变。最常见的例子就是在旧的Java内存模型中，String的值可能会变。
为了修补这个漏洞，JSR-133增强了final的语义。通过为final域增加写和读重排序规则，可以为Java程序员提供初始化安全保证：只要对象是正确构造的（被构造对象的引用在构造函数中没有“溢出”），那么不需要使用同步就可以保证任意线程都能看到这个final域在构造函数中被初始化之后的值。