final的两个重排序规则

final的两个重排序规则_riemann_的博客-CSDN博客_final域要遵守的两个重排序规则

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

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

  先看一段示例代码：

  package com.test;
  ​
  /**
   * final域为基本类型
   *
   * @author riemann
   * @date 2019/07/17 23:24
   */
  public class FinalDemo {
  ​
      private int a;                        //普通变量
      private final int b;                  //final变量
      private static FinalDemo finalDemo;
  ​
      public FinalDemo() {      //构造函数
          a = 1;                //写普通域
          b = 2;                //写final域
      }
  ​
      public static void writer() {    //写线程A执行
          finalDemo = new FinalDemo();
      }
  ​
      public static void reader() {        //读线程B执行
          FinalDemo object = finalDemo;    //读对象引用
          int a = object.a;                //读普通域
          int b = object.b;                //读final域
      }
  ​
  }
  123456789101112131415161718192021222324252627282930

  假设线程A在执行writer()方法，线程B执行reader()方法。

  一、final域为基本类型

  （一）、写final域重排序规则

  写final域的重排序规则禁止对final域的写重排序到构造函数之外，这个规则的实现主要包含了两个方面：

  1、JMM禁止编译器把final域的写重排序到构造函数之外； 2、编译器会在final域写之后，构造函数return之前，插入一个storestore屏障（关于内存屏障可以看这篇文章）。这个屏障可以禁止处理器把final域的写重排序到构造函数之外。

  我们再来分析writer方法，虽然只有一行代码，但实际上做了两件事情：

  1、构造了一个FinalDemo对象； 2、把这个对象赋值给成员变量finalDemo。 我们来画下存在的一种可能执行时序图，如下：

  

  由于a,b之间没有数据依赖性，普通域（普通变量）a可能会被重排序到构造函数之外，线程B就有可能读到的是普通变量a初始化之前的值（零值），这样就可能出现错误。而final域变量b，根据重排序规则，会禁止final修饰的变量b重排序到构造函数之外，从而b能够正确赋值，线程B就能够读到final变量初始化后的值。

  因此，写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域就不具有这个保障。比如在上例，线程B有可能就是一个未正确初始化的对象finalDemo。

  （ 二）、读final域重排序规则

  读final域重排序规则为：在一个线程中，初次读对象引用和初次读该对象包含的final域，JMM会禁止这两个操作的重排序。（注意，这个规则仅仅是针对处理器），处理器会在读final域操作的前面插入一个LoadLoad屏障。实际上，读对象的引用和读该对象的final域存在间接依赖性，一般处理器不会重排序这两个操作。但是有一些处理器会重排序，因此，这条禁止重排序规则就是针对这些处理器而设定的。

  read()方法主要包含了三个操作：

  1、初次读引用变量finalDemo; 2、初次读引用变量finalDemo的普通域a; 3、初次读引用变量finalDemo的final与b;

  假设线程A写过程没有重排序，那么线程A和线程B有一种的可能执行时序为下图：

  

  读对象的普通域被重排序到了读对象引用的前面就会出现线程B还未读到对象引用就在读取该对象的普通域变量，这显然是错误的操作。而final域的读操作就“限定”了在读final域变量前已经读到了该对象的引用，从而就可以避免这种情况。

  读final域的重排序规则可以确保：在读一个对象的final域之前，一定会先读这个包含这个final域的对象的引用。

  二、final域为引用类型

  我们已经知道了final域是基本数据类型的时候重排序规则是怎么的了？如果是引用数据类型了？我们接着继续来探讨。

  （一）、对final修饰的对象的成员域写操作

  针对引用数据类型，final域写针对编译器和处理器重排序增加了这样的约束：在构造函数内对一个final修饰的对象的成员域的写入，与随后在构造函数之外把这个被构造的对象的引用赋给一个引用变量，这两个操作是不能被重排序的。注意这里的是“增加”也就说前面对final基本数据类型的重排序规则在这里还是使用。这句话是比较拗口的，下面结合实例来看。

  package com.test;
  ​
  /**
   * final域为引用类型
   *
   * @author riemann
   * @date 2019/07/18 0:33
   */
  public class FinalReferenceDemo {
  ​
      final int[] arrays;
      private FinalReferenceDemo finalReferenceDemo;
  ​
      public FinalReferenceDemo() {
          arrays = new int[1];  //1
          arrays[0] = 1;        //2
      }
  ​
      public void writerOne() {
          finalReferenceDemo = new FinalReferenceDemo(); //3
      }
  ​
      public void writerTwo() {
          arrays[0] = 2;  //4
      }
  ​
      public void reader() {
          if (finalReferenceDemo != null) {  //5
              int temp = finalReferenceDemo.arrays[0];  //6
          }
      }
  ​
  }
  123456789101112131415161718192021222324252627282930313233

  针对上面的实例程序，线程线程A执行wirterOne方法，执行完后线程B执行writerTwo方法，然后线程C执行reader方法。下图就以这种执行时序出现的一种情况来讨论（耐心看完才有收获）。

  

  由于对final域的写禁止重排序到构造方法外，因此1和3不能被重排序。由于一个final域的引用对象的成员域写入不能与随后将这个被构造出来的对象赋给引用变量重排序，因此2和3不能重排序。

  （二）、对final修饰的对象的成员域读操作

  JMM可以确保线程C至少能看到写线程A对final引用的对象的成员域的写入，即能看下arrays[0] = 1，而写线程B对数组元素的写入可能看到可能看不到。JMM不保证线程B的写入对线程C可见，线程B和线程C之间存在数据竞争，此时的结果是不可预知的。如果可见的，可使用锁或者volatile。

  三、关于final重排序的总结

  按照final修饰的数据类型分类：

  基本数据类型:

  final域写：禁止final域写与构造方法重排序，即禁止final域写重排序到构造方法之外，从而保证该对象对所有线程可见时，该对象的final域全部已经初始化过。 final域读：禁止初次读对象的引用与读该对象包含的final域的重排序。

  引用数据类型：

  额外增加约束：禁止在构造函数对一个final修饰的对象的成员域的写入与随后将这个被构造的对象的引用赋值给引用变量 重排序

  四、final的实现原理

  上面我们提到过，写final域会要求编译器在final域写之后，构造函数返回前插入一个StoreStore屏障。读final域的重排序规则会要求编译器在读final域的操作前插入一个LoadLoad屏障。 很有意思的是，如果以X86处理为例，X86不会对写-写重排序，所以StoreStore屏障可以省略。由于不会对有间接依赖性的操作重排序，所以在X86处理器中，读final域需要的LoadLoad屏障也会被省略掉。也就是说，以X86为例的话，对final域的读/写的内存屏障都会被省略！具体是否插入还是得看是什么处理器。

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

  这里还有一个比较有意思的问题：上面对final域写重排序规则可以确保我们在使用一个对象引用的时候该对象的final域已经在构造函数被初始化过了。但是这里其实是有一个前提条件的，也就是：在构造函数，不能让这个被构造的对象被其他线程可见，也就是说该对象引用不能在构造函数中“逸出”。以下面的例子来说：

  package com.test;
  ​
  /**
   * @author riemann
   * @date 2019/07/18 0:46
   */
  public class FinalReferenceEscapeDemo {
  ​
      private final int a;
      private FinalReferenceEscapeDemo referenceDemo;
  ​
      public FinalReferenceEscapeDemo() {
          a = 1;  //1
          referenceDemo = this; //2
      }
  ​
      public void writer() {
          new FinalReferenceEscapeDemo();
      }
  ​
      public void reader() {
          if (referenceDemo != null) {  //3
              int temp = referenceDemo.a; //4
          }
      }
      
  }
  123456789101112131415161718192021222324252627

  可能的执行时序如图所示：

  

  假设一个线程A执行writer方法另一个线程执行reader方法。因为构造函数中操作1和2之间没有数据依赖性，1和2可以重排序，先执行了2，这个时候引用对象referenceDemo是个没有完全初始化的对象，而当线程B去读取该对象时就会出错。尽管依然满足了final域写重排序规则：在引用对象对所有线程可见时，其final域已经完全初始化成功。但是，引用对象“this”逸出，该代码依然存在线程安全的问题。