Java 并发 (5) -- happen - before 规则

1. 简介

倘若在程序开发中，仅靠 sychronized 和 volatile 关键字来保证原子性、可见性以及有序性，那么编写并发程序可能会显得十分麻烦。幸运的是，在 Java 内存模型中，还提供了 happens-before 原则来辅助保证程序执行的原子性、可见性以及有序性的问题，它是判断数据是否存在竞争、线程是否安全的依据。happens-before 原则内容如下：

1. 程序顺序原则：即在一个线程内必须保证语义串行性，也就是说按照代码顺序执行；
2. 锁规则：解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前。也就是说，如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)；
3. volatile 规则：volatile 变量的 “写” 先发生于 “读”，这保证了 volatile 变量的可见性。简单的理解就是： volatile 变量在每次被线程访问时，都强迫从主内存中读该变量的值；而当该变量值发生变化时，又会强迫将最新的值刷新到主内存中。因此，任何时刻，不同的线程总是能够看到该变量的最新值；
4. 线程启动规则：线程的 start() 方法先于它的每一个动作，即如果线程 A 在线程 B 执行 start() 方法之前修改了共享变量的值，那么当线程 B 执行 start() 方法时，线程 A 对共享变量的修改对线程 B 是可见的；
5. 传递性：A 先于 B ，B 先于 C ，那么 A 必然先于 C；
6. 线程终止规则：线程的所有操作先于线程的终结，Thread.join() 方法的作用是等待当前执行的线程终止。假设在线程 B 终止之前，修改了共享变量，线程 A 从线程 B 的 join() 方法成功返回后，线程 B 对共享变量的修改将对线程 A 可见。
7. 线程中断规则：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 Thread.interrupted() 方法检测线程是否中断。
8. 对象终结规则：对象的构造函数执行（对象的初始化） 、结束先于 finalize() 方法；

2. 精讲

1. 案例

如下图所示，一个 happens-before 规则通常对应于多个编译器重排序规则和处理器重排序规则。对于 Java 程序员来说，happens-before 规则简单易懂，它避免程序员为了理解 JMM 提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现。

上述8条原则无需手动添加任何同步手段(synchronized|volatile)即可达到效果，下面我们结合前面的案例演示这8条原则如何判断线程是否安全，如下：

class MixedOrder{
    int a = 0;
    boolean flag = false;
    public void writer(){
        a = 1;
        flag = true;
    }

    public void read(){
        if(flag){
            int i = a + 1;
        }
    }
}

同样的道理，存在两条线程 A 和 B，线程 A 调用实例对象的 writer() 方法，而线程 B 调用实例对象的 read() 方法。线程 A 先启动而线程 B 后启动，那么线程 B 读取到的 i 值是多少呢？

现在依据8条原则：

1. 由于存在两条线程同时调用，因此程序次序原则不合适。
2. writer() 方法和 read() 方法都没有使用同步手段，锁规则也不合适。
3. 没有使用 volatile 关键字，volatile 变量原则不适应。
4. 线程启动规则、线程终止规则、线程中断规则、对象终结规则、传递性和本次测试案例也不合适。
5. 线程 A 和线程 B 的启动时间虽然有先后，但线程 B 执行结果却是不确定，也是说上述代码没有适合8条原则中的任意一条，也没有使用任何同步手段，所以上述的操作是线程不安全的，因此线程 B 读取的值自然也是不确定的。修复这个问题的方式很简单，要么给 writer() 方法和 read() 方法添加同步手段，如 synchronized ，要么给变量 flag 添加 volatile 关键字，确保线程 A 修改的值对线程 B 总是可见

2. JMM 与 happen - before 规则

happens-before 是 JMM 最核心的概念。

JMM 设计时一方面要为程序员提供足够强的内存可见性保证；另一方面对编译器和处理器的限制要尽可能的放松，设计 JMM 时需要进行平衡。

【案例1】

double pi = 3.14;          // A
double r = 1.0;            // B
double area = pi * r *r;   // C

上面计算圆的面积的示例代码存在 3 个 happens-before 关系，如下所示：

上面的 3 个 happens-before 关系，2 和 3 是必须的，但是 1 不是必须的。因此，JMM 把 happens- before 要求禁止的重排序分为了下面两类：

1. 会改变程序执行结果的重排序；

2. 不会改变程序执行结果的重排序。

JMM 的设计示意图如下所示：

从上图可以看出两点：

JMM 向程序员提供的 happens- before 规则能满足程序员的需求。JMM 的 happens- before 规则不但简单易懂，而且也向程序员提供了足够强的内存可见性保证（有些内存可见性保证其实并不一定真实存在，比如上面的 A happens- before B）

JMM 对编译器和处理器的束缚已经尽可能的小。从上面的分析我们可以看出，JMM 其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。比如，如果编译器经过细致的分析后，认定一个锁只会被单个线程访问，那么这个锁可以被消除。再比如，如果编译器经过细致的分析后，认定一个 volatile 变量仅仅只会被单个线程访问，那么编译器可以把这个 volatile 变量当作一个普通变量来对待。这些优化既不会改变程序的执行结果，又能提高程序的执行效率。

3. happens-before 的定义

JSR 使用 happens-before 的概念来指定两个操作之间的执行顺序。由于这两个操作可以在一个线程之内，也可以在不同的线程之间。因此，JMM 可以通过 happens-before 关系向程序员提供跨线程的内存可见性保证（如果 A 线程的写操作 a 与 B 线程的读操作 b 之间存在 happens-before 关系，尽管 a 操作和 b 操作在不同的线程中执行，但 JMM 向程序员保证 a 操作将对 b 操作可见）
happens-before 定义：

1. 如果一个操作 happens-before 另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前；

2. 两个操作之间存在 happens-before 关系，并不意味着 Java 平台的具体实现必须要按照 happens-before 关系指定的顺序执行。只要重排序的执行结果与按照 happens-before 执行的结果一致，那么 JMM 就会允许这种重排序

第一点是 JMM 对程序员的承诺，第二点是 JMM 对编译器和处理器重排序的约束原则

4. happens-before 规则的几个案例

1. volatile 规则
   

   • 1 happens-before 2 和 3 happens-before 4由程序的顺序规则产生；

   • 2 happens-before 3 是由volatile规则产生；

   • 1 happens-before 4 是由传递性规则产生的

2. 线程启动原则

   假设线程 A 在执行过程中，通过执行 ThreadB.start() 来启动线程 B；同时，假设线程 A 在执行 ThreadB.start() 之前修改了一些共享变量，线程 B 在开始执行后会读这些共享变量
   

   • 1 happens-before 2 由程序顺序规则产生；
   • 2 happens-before 4 由start()规则产生；
   • 1 happens-before 4 由传递性产生。
     .

   这就意味着，线程 A 在执行 ThreadB.start() 之前对共享变量所做的修改，接下来在线程 B 开始执行后都将确保对线程 B 可见

3. 线程终止原则/join()

   假设线程 A 在执行过程中，通过执行 ThreadB.join() 来等待线程 B 的终止；同时，假设线程 B 在终止之前修改了一些共享变量，线程 A 从 ThreadB.join() 返回后读这些共享变量
   

   • 2 happens-before 4：join()规则产生；
   • 4 happens-before 5：程序顺序规则产生；
   • 2 happens-before 5：传递性规则产生
     .

   这也就意味着，线程 A 执行操作 ThreadB.join() 并成功返回后，线程 B 中的任意操纵都将对线程 A 可见