java并发原理实战(17) -- 重排序

摘自<<java并发编程的艺术>>一书，加深记忆，记录下:

重排序

什么是重排序

重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段。

数据依赖性

如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间
就存在数据依赖性。数据依赖分为下列3种类型，如表3-4所示。

上面3种情况，只要重排序两个操作的执行顺序，程序的执行结果就会被改变。
前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。
这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

as-if-serial语义

as-if-serial语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。
为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。为了具体说明，请看下面计算圆面积的代码示例。

如图3-6所示，A和C之间存在数据依赖关系，同时B和C之间也存在数据依赖关系。因此在最终执行的指令序列中，C不能被重排序到A和B的前面（C排到A和B的前面，程序的结果将会被改变）。但A和B之间没有数据依赖关系，编译器和处理器可以重排序A和B之间的执行顺序。
图3-7是该程序的两种执行顺序。

as-if-serial语义把单线程程序保护了起来，遵守as-if-serial语义的编译器、runtime和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。asif-serial语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

指令重排序分类

在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。重排序分3种类
型。

• 1）编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。

• 2）指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-LevelParallelism，ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应
  机器指令的执行顺序。

• 3）内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上
  ​ 去可能是在乱序执行。

  从Java源代码到最终实际执行的指令序列，会分别经历下面3种重排序，如图3-3所示

上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特定类型的内存屏障（Memory Barriers，Intel称之为Memory Fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序。
JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

重排序会产生什么问题

1. 重排序可能会导致多线程程序出现内存可见性问题。(工作内存和主内存，编译器处理器重排序导致的可见性）
2. 重排序会导致有序性问题，程序的读写顺序于内存的读写顺序不一样（编译器处理器重排序，内存缓冲区(是处理器重排序的内容))

happen-before概述

从JDK 5开始，Java使用新的JSR-133内存模型（除非特别说明，本文针对的都是JSR-133内存模型）。JSR-133使用happens-before的概念来阐述操作之间的内存可见性。在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须要存在happens-before关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。
与程序员密切相关的happens-before规则如下。

·1）程序顺序规则：

一个线程中的每个操作，happens-before于该线程中的任意后续操作。

·2）监视器锁规则：

对一个锁的解锁，happens-before于随后对这个锁的加锁。

·3）volatile变量规则：

对一个volatile域的写，happens-before于任意后续对这个volatile域的读。

·4）传递性：

如果A happens-before B，且B happens-before C，那么A happens-before C。

注意：两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visible to and ordered before the second）。happens-before的定义很微妙，后文会具体说明happens-before为什么要这么定义。

5）start()规则：

如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的
ThreadB.start()操作happens-before于线程B中的任意操作。

6）join()规则：

如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作
happens-before于线程A从ThreadB.join()操作成功返回。

锁的内存语义

1.锁的释放-获取建立的happens-before关系

锁是Java并发编程中最重要的同步机制。锁除了让临界区互斥执行外，还可以让释放锁的线程向获取同一个锁的线程发送消息。

class MonitorExample {
	int a = 0;
	public synchronized void writer() {　　　　 // 1
		a++;　　　　　　　　　　 // 2
	}　　　　　　　　　　　　 // 3
	public synchronized void reader() {　　　 // 4
		int i = a;　　　　　　　　 // 5
		……
	}　　　　　　　　　　　　 // 6
}

假设线程A执行writer()方法，随后线程B执行reader()方法。根据happens-before规则，这个
过程包含的happens-before关系可以分为3类。
1）根据程序次序规则，1 happens-before 2,2 happens-before 3;4 happens-before 5,5 happens-before 6。
2）根据监视器锁规则，3 happens-before 4。
3）根据happens-before的传递性，2 happens-before 5。

在图3-24中，每一个箭头链接的两个节点，代表了一个happens-before关系。黑色箭头表示程序顺序规则；橙色箭头表示监视器锁规则；蓝色箭头表示组合这些规则后提供的happensbefore保证。
图3-24表示在线程A释放了锁之后，随后线程B获取同一个锁。在上图中，2 happens-before 5。因此，线程A在释放锁之前所有可见的共享变量，在线程B获取同一个锁之后，将立刻变得对B线程可见。

2.锁的释放和获取的内存语义

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。以上面的MonitorExample程序为例，A线程释放锁后，共享数据的状态示意图如图3-25所示。

当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必须从主内存中读取共享变量。图3-26是锁获取的状态示意图。

对比锁释放-获取的内存语义与volatile写-读的内存语义可以看出：锁释放与volatile写有相同的内存语义；锁获取与volatile读有相同的内存语义。
下面对锁释放和锁获取的内存语义做个总结。
·线程A释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息。
·线程B获取一个锁，实质上是线程B接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息。
·线程A释放锁，随后线程B获取这个锁，这个过程实质上是线程A通过主内存向线程B发送消息。

volatile内存语义

1.volatile写-读建立的happens-before关系

从JSR-133开始（即从JDK5开始），volatile变量的写-读可以实现线程之间的通信。
从内存语义的角度来说，volatile的写-读与锁的释放-获取有相同的内存效果：volatile写和锁的释放有相同的内存语义；volatile读与锁的获取有相同的内存语义。
请看下面使用volatile变量的示例代码。

class VolatileExample {
	int a = 0;
	volatile boolean flag = false;
	public void writer() {
		a = 1;　　　　　 // 1
		flag = true;　　　 // 2
	}
	public void reader() {
		if (flag) {　　　　// 3
		int i = a;　　 // 4
		……
	}
}

假设线程A执行writer()方法之后，线程B执行reader()方法。根据happens-before规则，这个
过程建立的happens-before关系可以分为3类：
1）根据程序次序规则，1 happens-before 2;3 happens-before 4。
2）根据volatile规则，2 happens-before 3。
3）根据happens-before的传递性规则，1 happens-before 4。
上述happens-before关系的图形化表现形式如下。

在上图中，每一个箭头链接的两个节点，代表了一个happens-before关系。黑色箭头表示程序顺序规则；橙色箭头表示volatile规则；蓝色箭头表示组合这些规则后提供的happens-before保证。
这里A线程写一个volatile变量后，B线程读同一个volatile变量。A线程在写volatile变量之前所有可见的共享变量，在B线程读同一个volatile变量后，将立即变得对B线程可见。

2.volatile写-读的内存语义

volatile写的内存语义如下。
当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。
以上面示例程序VolatileExample为例，假设线程A首先执行writer()方法，随后线程B执行reader()方法，初始时两个线程的本地内存中的flag和a都是初始状态。图3-17是线程A执行volatile写后，共享变量的状态示意图。

如图3-17所示，线程A在写flag变量后，本地内存A中被线程A更新过的两个共享变量的值被刷新到主内存中。此时，本地内存A和主内存中的共享变量的值是一致的。
volatile读的内存语义如下。
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。
图3-18为线程B读同一个volatile变量后，共享变量的状态示意图。
如图所示，在读flag变量后，本地内存B包含的值已经被置为无效。此时，线程B必须从主内存中读取共享变量。线程B的读取操作将导致本地内存B与主内存中的共享变量的值变成一
致。
如果我们把volatile写和volatile读两个步骤综合起来看的话，在读线程B读一个volatile变量后，写线程A在写这个volatile变量之前所有可见的共享变量的值都将立即变得对读线程B可见。

下面对volatile写和volatile读的内存语义做个总结。
·线程A写一个volatile变量，实质上是线程A向接下来将要读这个volatile变量的某个线程发出了（其对共享变量所做修改的）消息。
·线程B读一个volatile变量，实质上是线程B接收了之前某个线程发出的（在写这个volatile变量之前对共享变量所做修改的）消息。
·线程A写一个volatile变量，随后线程B读这个volatile变量，这个过程实质上是线程A通过主内存向线程B发送消息。

final内存语义

与前面介绍的锁和volatile相比，对final域的读和写更像是普通的变量访问。下面将介绍final域的内存语义。

1.final域的重排序规则

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

下面通过一些示例性的代码来分别说明这两个规则:

public class FinalExample {
	int i;　　　　　　　　　　 // 普通变量
	final int j;　　　　　　　　 // final变量
	static FinalExample obj;
	public 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()方法。下面我们通过这两个线程的交互来说明这两个规则.

2.写final域的重排序规则

写final域的重排序规则禁止把final域的写重排序到构造函数之外。这个规则的实现包含
下面2个方面。
1）JMM禁止编译器把final域的写重排序到构造函数之外。
2）编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外。
现在让我们分析writer()方法。writer()方法只包含一行代码：finalExample=newFinalExample()。这行代码包含两个步骤，如下。
1）构造一个FinalExample类型的对象。
2）把这个对象的引用赋值给引用变量obj。
假设线程B读对象引用与读对象的成员域之间没有重排序（马上会说明为什么需要这个假设），图3-29是一种可能的执行时序。
在图3-29中，写普通域的操作被编译器重排序到了构造函数之外，读线程B错误地读取了普通变量i初始化之前的值。而写final域的操作，被写final域的重排序规则“限定”在了构造函数之内，读线程B正确地读取了final变量初始化之后的值。
写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域不具有这个保障。以上图为例，在读线程B“看到”对象引用obj时，很可能obj对象还没有构造完成（对普通域i的写操作被重排序到构造函数外，此时初始值1还没有写入普通域i）。

3.读final域的重排序规则

读final域的重排序规则是，在一个线程中，初次读对象引用与初次读该对象包含的final域，JMM禁止处理器重排序这两个操作（注意，这个规则仅仅针对处理器）。编译器会在读final域操作的前面插入一个LoadLoad屏障。
初次读对象引用与初次读该对象包含的final域，这两个操作之间存在间接依赖关系。由于编译器遵守间接依赖关系，因此编译器不会重排序这两个操作。大多数处理器也会遵守间接依赖，也不会重排序这两个操作。但有少数处理器允许对存在间接依赖关系的操作做重排序
（比如alpha处理器），这个规则就是专门用来针对这种处理器的。
reader()方法包含3个操作。
·初次读引用变量obj。
·初次读引用变量obj指向对象的普通域j。
·初次读引用变量obj指向对象的final域i。
现在假设写线程A没有发生任何重排序，同时程序在不遵守间接依赖的处理器上执行，图3-30所示是一种可能的执行时序。

在图3-30中，读对象的普通域的操作被处理器重排序到读对象引用之前。读普通域时，该域还没有被写线程A写入，这是一个错误的读取操作。而读final域的重排序规则会把读对象final域的操作“限定”在读对象引用之后，此时该final域已经被A线程初始化过了，这是一个正确的读取操作。
读final域的重排序规则可以确保：在读一个对象的final域之前，一定会先读包含这个final域的对象的引用。在这个示例程序中，如果该引用不为null，那么引用对象的final域一定已经被A线程初始化过了。

---

完