集册 Java 并发编程 深入 Java 内存模型（1）

深入 Java 内存模型（1）

欢马劈雪     最近更新时间：2020-08-04 05:37:59

180

happen—before 规则介绍

Java 语言中有一个“先行发生”（happen—before）的规则，它是 Java 内存模型中定义的两项操作之间的偏序关系，如果操作 A 先行发生于操作 B，其意思就是说，在发生操作 B 之前，操作A产生的影响都能被操作 B 观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等，它与时间上的先后发生基本没有太大关系。这个原则特别重要，它是判断数据是否存在竞争、线程是否安全的主要依据。

举例来说，假设存在如下三个线程，分别执行对应的操作:

  • 线程 A 中执行如下操作：i=1

  • 线程 B 中执行如下操作：j=i

  • 线程 C 中执行如下操作：i=2

假设线程 A 中的操作”i=1“ happen—before 线程 B 中的操作“j=i”，那么就可以保证在线程 B 的操作执行后，变量 j 的值一定为 1，即线程 B 观察到了线程 A 中操作“i=1”所产生的影响；现在，我们依然保持线程 A 和线程 B 之间的 happen—before 关系，同时线程 C 出现在了线程 A 和线程 B 的操作之间，但是 C 与 B 并没有 happen—before 关系，那么 j 的值就不确定了，线程 C 对变量 i 的影响可能会被线程 B 观察到，也可能不会，这时线程 B 就存在读取到不是最新数据的风险，不具备线程安全性。

下面是 Java 内存模型中的八条可保证 happen—before 的规则，它们无需任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们进行随机地重排序。

  1. 程序次序规则：在一个单独的线程中，按照程序代码的执行流顺序，（时间上）先执行的操作 happen—before（时间上）后执行的操作。

  2. 管理锁定规则：一个 unlock 操作 happen—before 后面（时间上的先后顺序，下同）对同一个锁的 lock 操作。

  3. volatile变量规则：对一个 volatile 变量的写操作 happen—before 后面对该变量的读操作。

  4. 线程启动规则：Thread 对象的 start()方法 happen—before 此线程的每一个动作。

  5. 线程终止规则：线程的所有操作都 happen—before 对此线程的终止检测，可以通过 Thread.join()方法结束 Thread.isAlive()的返回值等手段检测到线程已经终止执行。

  6. 线程中断规则：对线程 interrupt()方法的调用 happen—before 发生于被中断线程的代码检测到中断时事件的发生。

  7. 对象终结规则：一个对象的初始化完成（构造函数执行结束）happen—before 它的 finalize()方法的开始。

  8. 传递性：如果操作 A happen—before 操作 B，操作 B happen—before 操作 C，那么可以得出 A happen—before 操作 C。

时间上先后顺序和 happen—before 原则

”时间上执行的先后顺序“与”happen—before“之间有何不同呢？

首先来看操作 A 在时间上先与操作 B 发生，是否意味着操作 A happen—before 操作 B？

一个常用来分析的例子如下：

private int value = 0;  

public int get(){  
    return value;  
}  
public void set(int value){  
    this.value = value;  
}

假设存在线程 A 和线程 B，线程 A 先（时间上的先）调用了 setValue(3)操作，然后（时间上的后）线程B调用了同一对象的 getValue()方法，那么线程B得到的返回值一定是3吗？

对照以上八条 happen—before 规则，发现没有一条规则适合于这里的 value 变量，从而我们可以判定线程 A 中的 setValue(3)操作与线程 B 中的 getValue()操作不存在 happen—before 关系。因此，尽管线程 A 的 setValue(3)在操作时间上先于操作 B 的 getvalue()，但无法保证线程 B 的 getValue()操作一定观察到了线程 A 的 setValue(3)操作所产生的结果，也即是 getValue()的返回值不一定为 3（有可能是之前 setValue 所设置的值）。这里的操作不是线程安全的。

因此，”一个操作时间上先发生于另一个操作“并不代表”一个操作 happen—before 另一个操作“。

解决方法：可以将 setValue（int）方法和 getValue()方法均定义为 synchronized 方法，也可以把 value 定义为 volatile 变量（value 的修改并不依赖 value 的原值，符合 volatile 的使用场景），分别对应 happen—before 规则的第 2 和第 3 条。注意，只将 setValue（int）方法和 getvalue()方法中的一个定义为 synchronized 方法是不行的，必须对同一个变量的所有读写同步，才能保证不读取到陈旧的数据，仅仅同步读或写是不够的 。

其次来看，操作 A happen—before 操作 B，是否意味着操作 A 在时间上先与操作 B 发生？

看有如下代码：

x = 1；  
y = 2;

假设同一个线程执行上面两个操作：操作 A：x=1 和操作 B：y=2。根据 happen—before 规则的第 1 条，操作 A happen—before 操作 B，但是由于编译器的指令重排序（Java 语言规范规定了 JVM 线程内部维持顺序化语义，也就是说只要程序的最终结果等同于它在严格的顺序化环境下的结果，那么指令的执行顺序就可能与代码的顺序不一致。这个过程通过叫做指令的重排序。指令重排序存在的意义在于：JVM 能够根据处理器的特性（CPU 的多级缓存系统、多核处理器等）适当的重新排序机器指令，使机器指令更符合 CPU 的执行特点，最大限度的发挥机器的性能。在没有同步的情况下，编译器、处理器以及运行时等都可能对操作的执行顺序进行一些意想不到的调整）等原因，操作 A 在时间上有可能后于操作 B 被处理器执行，但这并不影响 happen—before 原则的正确性。

因此，”一个操作 happen—before 另一个操作“并不代表”一个操作时间上先发生于另一个操作“。

最后，一个操作和另一个操作必定存在某个顺序，要么一个操作或者是先于或者是后于另一个操作，或者与两个操作同时发生。同时发生是完全可能存在的，特别是在多 CPU 的情况下。而两个操作之间却可能没有 happen-before 关系，也就是说有可能发生这样的情况，操作 A 不 happen-before 操作 B，操作 B 也不 happen-before 操作 A，用数学上的术语 happen-before 关系是个偏序关系。两个存在 happen-before 关系的操作不可能同时发生，一个操作 A happen-before 操作 B，它们必定在时间上是完全错开的，这实际上也是同步的语义之一（独占访问）。

利用 happen—before 规则分析 DCL

DCL 即双重检查加锁，下面是一个典型的在单例模式中使用 DCL 的例子：

public class LazySingleton {  
    private int someField;  

    private static LazySingleton instance;  

    private LazySingleton() {  
        this.someField = new Random().nextInt(200)+1;         // (1)  
    }  

    public static LazySingleton getInstance() {  
        if (instance == null) {                               // (2)  
            synchronized(LazySingleton.class) {               // (3)  
                if (instance == null) {                       // (4)  
                    instance = new LazySingleton();           // (5)  
                }  
            }  
        }  
        return instance;                                      // (6)  
    }  

    public int getSomeField() {  
        return this.someField;                                // (7)  
    }  
}

这里得到单一的 instance 实例是没有问题的，问题的关键在于尽管得到了 Singleton 的正确引用，但是却有可能访问到其成员变量的不正确值。具体来说 Singleton.getInstance().getSomeField() 有可能返回 someField 的默认值 0。如果程序行为正确的话，这应当是不可能发生的事，因为在构造函数里设置的 someField 的值不可能为 0。为也说明这种情况理论上有可能发生，我们只需要说明语句(1)和语句(7)并不存在 happen-before 关系。

假设线程Ⅰ是初次调用 getInstance()方法，紧接着线程Ⅱ也调用了 getInstance()方法和 getSomeField()方法，我们要说明的是线程Ⅰ的语句(1)并不 happen-before 线程Ⅱ的语句(7)。线程Ⅱ在执行 getInstance()方法的语句(2)时，由于对 instance 的访问并没有处于同步块中，因此线程Ⅱ可能观察到也可能观察不到线程Ⅰ在语句(5)时对 instance 的写入，也就是说 instance 的值可能为空也可能为非空。我们先假设 instance 的值非空，也就观察到了线程Ⅰ对 instance 的写入，这时线程Ⅱ就会执行语句(6)直接返回这个 instance 的值，然后对这个 instance 调用 getSomeField()方法，该方法也是在没有任何同步情况被调用，因此整个线程Ⅱ的操作都是在没有同步的情况下调用 ，这时我们便无法利用上述 8 条 happen-before 规则得到线程Ⅰ的操作和线程Ⅱ的操作之间的任何有效的 happen-before 关系（主要考虑规则的第 2 条，但由于线程Ⅱ没有在进入 synchronized 块，因此不存在 lock 与 unlock 锁的问题），这说明线程Ⅰ的语句(1)和线程Ⅱ的语句(7)之间并不存在 happen-before 关系，这就意味着线程Ⅱ在执行语句(7)完全有可能观测不到线程Ⅰ在语句(1)处对 someFiled 写入的值，这就是 DCL 的问题所在。很荒谬，是吧？DCL 原本是为了逃避同步，它达到了这个目的，也正是因为如此，它最终受到惩罚，这样的程序存在严重的 bug，虽然这种 bug 被发现的概率绝对比中彩票的概率还要低得多，而且是转瞬即逝，更可怕的是，即使发生了你也不会想到是 DCL 所引起的。

前面我们说了，线程Ⅱ在执行语句(2)时也有可能观察空值，如果是种情况，那么它需要进入同步块，并执行语句(4)。在语句(4)处线程Ⅱ还能够读到 instance 的空值吗？不可能。这里因为这时对 instance 的写和读都是发生在同一个锁确定的同步块中，这时读到的数据是最新的数据。为也加深印象，我再用 happen-before 规则分析一遍。线程Ⅱ在语句(3)处会执行一个 lock 操作，而线程Ⅰ在语句(5)后会执行一个 unlock 操作，这两个操作都是针对同一个锁--Singleton.class，因此根据第 2 条 happen-before 规则，线程Ⅰ的 unlock 操作 happen-before 线程Ⅱ的 lock 操作，再利用单线程规则，线程Ⅰ的语句(5) -> 线程Ⅰ的 unlock 操作，线程Ⅱ的 lock 操作 -> 线程Ⅱ的语句(4)，再根据传递规则，就有线程Ⅰ的语句(5) -> 线程Ⅱ的语句(4)，也就是说线程Ⅱ在执行语句(4)时能够观测到线程Ⅰ在语句(5)时对 Singleton 的写入值。接着对返回的 instance 调用 getSomeField()方法时，我们也能得到线程Ⅰ的语句(1) -> 线程Ⅱ的语句(7)（由于线程Ⅱ有进入 synchronized 块，根据规则 2 可得），这表明这时 getSomeField 能够得到正确的值。但是仅仅是这种情况的正确性并不妨碍 DCL 的不正确性，一个程序的正确性必须在所有的情况下的行为都是正确的，而不能有时正确，有时不正确。

对 DCL 的分析也告诉我们一条经验原则：对引用（包括对象引用和数组引用）的非同步访问，即使得到该引用的最新值，却并不能保证也能得到其成员变量（对数组而言就是每个数组元素）的最新值。

解决方案

最简单而且安全的解决方法是使用 static 内部类的思想，它利用的思想是：一个类直到被使用时才被初始化，而类初始化的过程是非并行的，这些都有 JLS 保证。

如下述代码：

展开阅读全文