java 内存模型-08-final
基础知识
基本用法
- 修饰类
当用final修饰一个类时，表明这个类不能被继承。
也就是说，如果一个类你永远不会让他被继承，就可以用final进行修饰。
final类中的成员变量可以根据需要设为final，但是要注意final类中的所有成员方法都会被隐式地指定为final方法。
- 修饰方法
使用final方法的原因有两个。
第一个原因是把方法锁定，以防任何继承类修改它的含义；
第二个原因是效率。
在早期的Java实现版本中，会将final方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升。
在最近的Java版本中，不需要使用final方法进行这些优化了。
- 修饰变量
对于一个final变量，如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；
如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。
匿名内部类
匿名内部类使用外部变量时为何要强制使用 final 修饰
private void initViews() {
final int a = 3; // Compilation error if remove final
btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
if (a > 1) {
// volala
}
}
}
}
那么，有没有想过为什么？
而像其他支持完整闭包的语言如JavaScript，Python等，是没有这等限制的。
究其原因，是Java对闭包支持不够完整，或者说它并不是像动态语言那样的完整闭包。
对于匿名内部类来说，编译器会创建一个命名类(OutClass$1之类的)，然后把匿名类所在的[能捕获的变量](https://en.wikipedia.org/wiki/Closure_(computer_programming)，以构造参数的形式传递给内部类使用，这样一样，外部的变量与内部类看到的变量是不同的，虽然它们的值是相同的，因此，如果再允许外部修改这些变量，或者内部类里面修改这些变量，都会造成数据的不一致性（因为它们是不同的变量），所以Java强制要求匿名内部类访问的外部变量要加上final来修饰。
对于其他语言，匿名内部类，持有的是外部变量的一个包装的引用(wrapper reference)，这可以能看不懂，但是理解起来就是内部类能直接访问外部变量，外部与闭包内部访问的是同一个变量，因此外部修改了，内部能看到变化，内部修改了，外部也能看到变化。
一句话总结就是，Java 内部类与外部持有的是值相同的不同的变量；其他支持闭包的语言则持有的是相同的变量。
ps: Jdk 1.8+ 就没有这种限制了。
JLS 规范
各种博客内容大都人云亦云，此处从官方文档进行再次学习。
final class
如果未声明 final 的类被更改为要声明 final，那么如果加载了该类已有子类的二进制文件，则抛出 VerifyError，
因为 final 类不能有子类;对于广泛分布的类，不推荐这样的更改。
更改已声明为 final 的类，不再被声明为 final，不会破坏与已有二进制文件的兼容性。
final methods
将已声明为 final 的方法更改为不再声明为final不会破坏与已有二进制文件的兼容性。
更改未声明为 final 的实例方法可能会破坏与依赖于重写方法能力的现有二进制文件的兼容性。
- 普通版本
class Super { void out() { System.out.println("out"); } }
class Test extends Super {
public static void main(String[] args) {
Test t = new Test();
t.out();
}
void out() { super.out(); }
}
- final 版本
class Super { final void out() { System.out.println("!"); } }
如果Super被重新编译，但没有进行测试，那么使用已有的测试二进制文件运行新的二进制文件将导致VerifyError，因为类测试不正确地尝试覆盖实例方法。
更改未声明为final的类(static)方法不会破坏与现有二进制文件的兼容性，因为该方法不可能被重写。
final & static
final fields
...
JMM final
与前面介绍的锁和 volatil e相比较，对 final 域的读和写更像是普通的变量访问。
对于 final 域，编译器和处理器要遵守两个重排序规则：
-
在构造函数内对一个 final 域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。
-
初次读一个包含 final 域的对象的引用，与随后初次读这个 final 域，这两个操作之间不能重排序。
实例
- FinalExample.java
public class FinalExample {
int i; //普通变量
final int j; //final变量
static FinalExample obj;
public void FinalExample () { //构造函数
i = 1; //写普通域
j = 2; //写final域
}
public static void writer() { //写线程A执行
obj = new FinalExample ();
}
public static void reader() { //读线程B执行
FinalExample object = obj; //读对象引用
int a = object.i; //读普通域
int b = object.j; //读final域
}
}
这里假设一个线程 A 执行 writer() 方法，随后另一个线程 B 执行 reader() 方法。
下面我们通过这两个线程的交互来说明这两个规则。
写 final 域的重排序规则
写 final 域的重排序规则禁止把 final 域的写重排序到构造函数之外。这个规则的实现包含下面 2 个方面：
-
JMM 禁止编译器把 final 域 的写重排序到构造函数之外。
-
编译器会在 final 域的写之后，构造函数 return 之前，插入一个 StoreStore 屏障。这个屏障禁止处理器把 final 域的写重排序到构造函数之外。
现在让我们分析 writer() 方法。
writer() 方法只包含一行代码：finalExample = new FinalExample()。
这行代码包含两个步骤：
-
构造一个 FinalExample 类型的对象；
-
把这个对象的引用赋值给引用变量 obj。
假设线程 B 读对象引用与读对象的成员域之间没有重排序（马上会说明为什么需要这个假设），下图是一种可能的执行时序：
时间线：----------------------------------------------------------------->
线程A：执行构造函数 写j=2 StoreStore屏障 构造函数结束 构造函数的引用赋值给引用变量obj (...线程B...) 写i=1
线程B：读对象引用obj 读对象普通域i(×) 读对象final域j(√)
在以上流程中，写普通域的操作被编译器重排序到了构造函数之外，读线程 B 错误的读取了普通变量i初始化之前的值。
而写 final 域的操作，被写 final 域的重排序规则“限定”在了构造函数之内，读线程 B 正确的读取了 final 变量初始化之后的值。
写 final 域的重排序规则可以确保：
在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域不具有这个保障。
以上图为例，在读线程 B “看到”对象引用 obj 时，很可能 obj 对象还没有构造完成（对普通域i的写操作被重排序到构造函数外，此时初始值 2 还没有写入普通域 i）。
读 final 域的重排序规则
读 final 域的重排序规则如下：
- 在一个线程中，初次读对象引用与初次读该对象包含的 final 域，JMM禁止处理器重排序这两个操作（注意，这个规则仅仅针对处理器）。
编译器会在读 final 域操作的前面插入一个 LoadLoad 屏障。
初次读对象引用与初次读该对象包含的 final 域，这两个操作之间存在间接依赖关系。
由于编译器遵守间接依赖关系，因此编译器不会重排序这两个操作。
大多数处理器也会遵守间接依赖，大多数处理器也不会重排序这两个操作。
但有少数处理器允许对存在间接依赖关系的操作做重排序（比如alpha处理器），这个规则就是专门用来针对这种处理器。
reader() 方法包含三个操作：
-
初次读引用变量 obj;
-
初次读引用变量 obj 指向对象的普通域 j。
-
初次读引用变量 obj 指向对象的 final 域 i。
现在我们假设写线程 A 没有发生任何重排序，同时程序在不遵守间接依赖的处理器上执行，下面是一种可能的执行时序：
时间线：------------------------------------------------------------------------->
线程A：执行构造函数 写i=1 写j=2 StoreStore屏障 构造函数结束 构造函数的引用赋值给引用变量obj
线程B：读对象普通域i(×) (...A执行完...) 读对象引用obj LoadLoad屏障 读对象final域j(√)
在上图中，读对象的普通域的操作被处理器重排序到读对象引用之前。
读普通域时，该域还没有被写线程A写入，这是一个错误的读取操作。
而读final域的重排序规则会把读对象final域的操作“限定”在读对象引用之后，此时该final域已经被A线程初始化过了，这是一个正确的读取操作。
读 final 域的重排序规则可以确保：
在读一个对象的 final 域之前，一定会先读包含这个final域的对象的引用。
在这个示例程序中，如果该引用不为null，那么引用对象的final域一定已经被A线程初始化过了。
如果 final 域是引用类型
上面我们看到的 final 域是基础数据类型，下面让我们看看如果 final 域是引用类型，将会有什么效果？
请看下列示例代码：
public class FinalReferenceExample {
final int[] intArray; //final是引用类型
static FinalReferenceExample obj;
public FinalReferenceExample () { //构造函数
intArray = new int[1]; //1
intArray[0] = 1; //2
}
public static void writerOne () { //写线程A执行
obj = new FinalReferenceExample (); //3
}
public static void writerTwo () { //写线程B执行
obj.intArray[0] = 2; //4
}
public static void reader () { //读线程C执行
if (obj != null) { //5
int temp1 = obj.intArray[0]; //6
}
}
}
这里 final 域为一个引用类型，它引用一个int型的数组对象。
对于引用类型，写final域的重排序规则对编译器和处理器增加了如下约束：
- 在构造函数内对一个 final 引用的对象的成员域的写入，与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。
对上面的示例程序，我们假设首先线程 A 执行 writerOne() 方法，执行完后线程 B 执行 writerTwo() 方法，
执行完后线程 C 执行 reader() 方法。
下面是一种可能的线程执行时序：
时间线：-------------------------------------------------------------------------------------------->
线程A：执行构造函数 1.写final引用 2.写final引用的对象成员域 StoreStore屏障 构造函数结束 3.构造函数的引用赋值给引用变量obj
线程B：4.写final引用的对象的成员域
线程C：5.读对象引用obj LoadLoad屏障 6.读final引用的对象成员域
在上图中，1 是对 final 域的写入，2 是对这个 final 域引用的对象的成员域的写入，3 是把被构造的对象的引用赋值给某个引用变量。
这里除了前面提到的 1 不能和 3 重排序外，2 和 3 也不能重排序。
JMM 可以确保读线程 C 至少能看到写线程 A 在构造函数中对 final 引用对象的成员域的写入。
即 C 至少能看到数组下标 0 的值为 1。
而写线程 B 对数组元素的写入，读线程 C 可能看的到，也可能看不到。
JMM 不保证线程 B 的写入对读线程 C 可见，因为写线程 B 和读线程 C 之间存在数据竞争，此时的执行结果不可预知。
如果想要确保读线程 C 看到写线程 B 对数组元素的写入，写线程 B 和读线程 C 之间需要使用同步原语（lock 或 volatile）来确保内存可见性。
为什么 final 引用不能从构造函数内“逸出”
前面我们提到过，写 final 域的重排序规则可以确保：在引用变量为任意线程可见之前，该引用变量指向的对象的final域已经在构造函数中被正确初始化过了。
其实要得到这个效果，还需要一个保证：
在构造函数内部，不能让这个被构造对象的引用为其他线程可见，也就是对象引用不能在构造函数中“逸出”。
为了说明问题，让我们来看下面示例代码：
public class FinalReferenceEscapeExample {
final int i;
static FinalReferenceEscapeExample obj;
public FinalReferenceEscapeExample () {
i = 1; //1 写final域
obj = this; //2 this引用在此“逸出”
}
public static void writer() {
new FinalReferenceEscapeExample ();
}
public static void reader {
if (obj != null) { // 3
int temp = obj.i; // 4
}
}
}
假设一个线程 A 执行 writer() 方法，另一个线程 B 执行 reader() 方法。
这里的操作 2 使得对象还未完成构造前就为线程 B 可见。
即使这里的操作 2 是构造函数的最后一步，且即使在程序中操作 2 排在操作 1 后面，执行 read() 方法的线程仍然可能无法看到 final 域被初始化后的值，
因为这里的操作 1 和操作 2 之间可能被重排序。
实际的执行时序可能如下图所示：
时间线：-------------------------------------------------------------------------------------------->
线程A：执行构造函数 2.obj=this;被构造对象的引用在此处“溢出” 1.i=1;对final域初始化 构造函数结束
线程B：3.if(obj!=null);读取不为null的引用a 4.temp=obj.i;这里将读取到final域初始化之前的值
final 语义在处理器中的实现
现在我们以 x86 处理器为例，说明 final 语义在处理器中的具体实现。
上面我们提到，写 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域在构造函数中被初始化之后的值。
- String 的值可能会改变
String s1 = "/usr/tmp";
String s2 = s1.substring(4);
字符串s2的偏移量为4，长度为4。
但是，在旧的模型下，另一个线程可以看到偏移量的默认值为0，然后再看到正确的值4，它将显示为字符串“/usr”变为“/tmp”。
参考资料
- final 基础
http://toughcoder.net/blog/2016/11/12/understanding-java-keyword-final/
https://juejin.im/entry/58c4811161ff4b005d94fed2
https://www.cnblogs.com/dolphin0520/p/3736238.html
http://www.importnew.com/7553.html
https://blog.csdn.net/ch717828/article/details/46922777
- jls
final Fields and static Constant Variables
- jmm
