小贺のBLOG

【Java并发编程】Java内存模型（下）

发表于 分类于
本文字数： 11k 阅读时长 ≈ 10 分钟

Java并发/多线程编程系列blog(二）内存模型（下）含final域的内存定义/happens-before/双重检查锁定与延迟初始化/Java内存模型综述

final域的内存定义

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

final域的重排序规则

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

下面给出一个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class FinalExample{
    int i;                  //普通变量
    final int j;            //final变量
    static FinalExample obj;
    public FinalExaple(){   
        this.i = 1;         //写普通域
        this.j = 2;         //写final域
    }
    public void write(){    //写方法 线程A执行
        obj = new FinalExample();//写对象引用
    }
    public void read(){     //读方法 线程B执行
        FinalExample object = obj;//读对象引用
        int a = obj.i;      //读普通变量
        int b = obj.j;      //读final变量
    }
}

写final域的重排序规则

写final域的重排序规则禁止把final域的写重排序到构造函数之外。这个规则的实现包含下面2个方面:

  • JMM禁止编译器把final域的写重排序到构造函数之外。
  • 编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。这个屏障 禁止处理器把final域的写重排序到构造函数之外

写普通域的操作被编译器重排序到了构造函数之外，读线程B错误地读取了普通变量i初始化之前的值。而写final域的操作，被写final域的重排序规则“限定”在了构造函数之内，读线程B正确地读取了final变量初始化之后的值。 写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域不具有这个保障。

读final域的重排序规则

读final域的重排序规则是：在一个线程中，初次读对象引用与初次读该对象包含的final域，JMM禁止处理器重排序这两个操作（注意，这个规则仅仅针对处理器）。编译器会在读final域操作的前面插入一个LoadLoad屏障。 初次读对象引用与初次读该对象包含的final域，这两个操作之间存在间接依赖关系。由于编译器遵守间接依赖关系，因此编译器不会重排序这两个操作。大多数处理器也会遵守间接依赖，也不会重排序这两个操作。但有少数处理器允许对存在间接依赖关系的操作做重排序（比如alpha处理器），这个规则就是专门用来针对这种处理器的。

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

final域为引用类型

上面我们看到的final域是基础数据类型，如果final域是引用类型，将会有什么效果？示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class FinalReferenceExample{
    final int[] arrayint;              //饮用类型的final
    static FinalReferenceExample obj;
    public FinalReferenceExample(){
        arrayint = new int[1];         //1
        arrayint[0] = 1;               //2
    }
    public void writeOne(){            //A执行的写操作
        obj = new FinalReferenceExample();//3
    }
    public void writeTwo(){            //B执行的写操作
        obj.arrayint[0] = 2;           //4
    }
    public void read(){                //C执行的读操作
        if(obj!=null){                 //5
            int temp = obj.arrayint[0];//6
        }
    }
}

本例final域为一个引用类型，它引用一个int型的数组对象。对于引用类型，写final域的重排序规则对编译器和处理器增加了如下约束：在构造函数内对一个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域已经在构造函数中被正确初始化过了。其实，要得到这个效果，还需要一个保证：在构造函数内部，不能让这个被构造对象的引用为其他线程所见，也就是对象引用不能在构造函数中“溢出”。示例代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class FinalReferenceEscapeExample{
    final i;
    FinalReferenceExcapeExample obj;
    public FinalReferenceExcapeExample(){
        i = 1;                    //1写final域
        obj = this                //2this在此溢出
    }
    public writer(){
        new FinalReferenceExcapeExample();
    }
    public void reader(){
        if(obj!=null){            //3
            int temp = obj.i;     //4
        }
    }
}

这里的时序图可能将1放到最后

假设一个线程A执行writer()方法，另一个线程B执行reader()方法。这里的操作2使得对象还未完成构造前就为线程B可见。即使这里的操作2是构造函数的最后一步，且在程序中操作2排在操作1后面，执行reader()方法的线程仍然可能无法看到final域被初始化后的值，因为这里的操作1和操作2之间可能被重排序。所以在构造函数返回前，被构造对象的引用不能为其他线程所见，因为此时的final域可能还没有被初始化。在构造函数返回后，任意线程都将保证能看到final域正确初始化之后的值。

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域在构造函数中被初始化之后的值。

happens-before

happens-before是JMM最核心的概念。对应Java程序员来说，理解happens-before是理解JMM的关键。

JMM的设计

从JMM设计者的角度，在设计JMM时，需要考虑两个关键因素。

  • 程序员对内存模型的使用。程序员希望内存模型易于理解、易于编程。程序员希望基于一个强内存模型来编写代码。
  • 编译器和处理器对内存模型的实现。编译器和处理器希望内存模型对它们的束缚越少越好，这样它们就可以做尽可能多的优化来提高性能。编译器和处理器希望实现一个弱内存模型。

由于这两个因素互相矛盾，所以JSR-133专家组在设计JMM时的核心目标就是找到一个好的平衡点：一方面，要为程序员提供足够强的内存可见性保证；另一方面，对编译器和处理器的限制要尽可能地放松。我们来看JSR-133是如何实现这一目标的

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

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

  • A happens-before B;
  • B happens-before C;
  • A happens-before C。

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

  • 会改变程序执行结果的重排序;
  • 不会改变程序执行结果的重排序。

JMM对这两种不同性质的重排序，采取了不同的策略，如下：

  • 对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序。
  • 对于不会改变程序执行结果的重排序，JMM对编译器和处理器不做要求（JMM允许这种重排序）
    C0RiD.png
  • JMM向程序员提供的happens-before规则能满足程序员的需求。JMM的happens-before规则不但简单易懂，而且也向程序员提供了足够强的内存可见性保证（有些内存可见性保证其实并不一定真实存在，比如上面的A happens-before B;
  • JMM对编译器和处理器的束缚已经尽可能少。从上面的分析可以看出，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。例如，如果编译器经过细致的分析后，认定一个锁只会被单个线程访问，那么这个锁可以被消除。再如，如果编译器经过细致的分析后，认定一个volatile变量只会被单个线程访问，那么编译器可以把这个volatile变量当作一个普通变量来对待。这些优化既不会改变程序的执行结果，又能提高程序的执行效率。

happens-before的定义

  • 1.如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前;
  • 2.两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。
  • 1.是JMM对程序员的承诺。从程序员的角度来说，可以这样理解happens-before关系：如果A happens-before B，那么Java内存模型将向程序员保证——A操作的结果将对B可见，且A的执行顺序排在B之前。注意，这只是Java内存模型向程序员做出的保证！
  • 2.是JMM对编译器和处理器重排序的约束原则。正如前面所言，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。JMM这么做的原因是：程序员对于这两个操作是否真的被重排序并不关心，程序员关心的是程序执行时的语义不能被改变（即执行结果不能被改变）。

happens-before关系本质上和as-if-serial语义是一回事。

  • as-if-serial语义保证单线程内程序的执行结果不被改变，happens-before关系保证正确同步的多线程程序的执行结果不被改变。
  • as-if-serial语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。happens-before关系给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按happens-before指定的顺序来执行的。

as-if-serial语义和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。
  • 5.start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的 ThreadB.start()操作happens-before于线程B中的任意操作。
  • 6.join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作 happens-before于线程A从ThreadB.join()操作成功返回。

这里的规则1、2、3和4前面都说过，这里再做个总结。由于2和3情况类似，这里只以1、3和4为例来说明。

volatile写-读建立的happens-before：
C0gRj.png

  • 1 happens-before 2和3 happens-before 4由程序顺序规则产生。由于编译器和处理器都要遵守as-if-serial语义，也就是说，as-if-serial语义保证了程序顺序规则。因此，可以把程序顺序 规则看成是对as-if-serial语义的“封装”。
  • 2 happens-before 3是由volatile规则产生。前面提到过，对一个volatile变量的读，总是能看到（任意线程）之前对这个volatile变量最后的写入。因此，volatile的这个特性可以保证实现 volatile规则。
  • 1 happens-before 4是由传递性规则产生的。这里的传递性是由volatile的内存屏障插入策略和volatile的编译器重排序规则共同来保证的。

下面我们来看start()规则。假设线程A在执行的过程中，通过执行ThreadB.start()来启动线程B；同时，假设线程A在执行ThreadB.start()之前修改了一些共享变量，线程B在开始执行后会 读这些共享变量。该程序对应的happens-before关系图为：
C0hWk.png

  • 1 happens-before 2由程序顺序规则产生，2 happens-before 4由start()规则产生。根据传递性，将有1 happens-before 4。这实意味着，线程A在执行ThreadB.start()之前对共享变量所做的修改，接下来在线程B开始执行后都将确保对线程B可见。

下面我们来看join()规则。假设线程A在执行的过程中，通过执行ThreadB.join()来等待线 程B终止；同时，假设线程B在终止之前修改了一些共享变量，线程A从ThreadB.join()返回后会读这些共享变量。该程序对应的happens-before关系图为：
C0syn.png

  • 2 happens-before 4由join()规则产生；4 happens-before 5由程序顺序规则产生。 根据传递性规则，将有2 happens-before 5。这意味着，线程A执行操作ThreadB.join()并成功返回后，线程B中的任意操作都将对线程A可见。

双重检查锁定与延迟初始化

在Java程序中，有时候可能需要推迟一些高开销的对象初始化操作，并且只有在使用这些对象时才进行初始化。此时，程序员可能会采用延迟初始化。但要正确实现线程安全的延迟初始化需要一些技巧，否则很容易出现问题。

双重检查锁定的由来

下面是非线程安全的延迟初始化对象的示例代码

1
2
3
4
5
6
7
8
9
public class UnsafeLazyInitialization{
    private static Instance instance;
    public static Instance getInstance(){
        if(instance == null){
            instance = new Instance();
        }
        return instance;
    }
}

双重检查锁定：

1
2
3
4
5
6
7
8
9
10
11
12
13
public class SafeLacyInitialization{
    private static Instance instance;
    public static Instance getInstance(){
        if(instance == null){
            synchronized (DoubleCheckedLoacking.class){
                if(instance == null){
                    instance = new Instance();
                }
            }
        }
        return instance;
    }
}

双重检查锁定看起来似乎很完美，但这是一个错误的优化！在线程执行到第4行，代码读取到instance不为null时，instance引用的对象有可能还没有完成初始化。

问题的根源

双重检查锁定示例代码的第7行（instance=new Singleton();）创建了一个对象。这一行代码可以分解为如下的3行伪代码。

1
2
3
memory = allocata() //为对象分配内存区域
ctorInstance(memory) //对象初始化
instance = memory //设置instance指向刚分配的内存区域

上面3行伪代码中的2和3之间，可能会被重排序
C0Zt1.png

这里A2和A3虽然重排序了，但Java内存模型的intra-thread semantics将确保A2一定会排在A4前面执行。因此，线程A的intra-thread semantics没有改变，但A2和A3的重排序，将导致线程B在B1处判断出instance不为空，线程B接下来将访问instance引用的对象。此时，线程B将会访 问到一个还未初始化的对象。在知晓了问题发生的根源之后，我们可以想出两个办法来实现线程安全的延迟初始化:

  • 不允许2和3重排序。
  • 允许2和3重排序，但不允许其他线程“看到”这个重排序。

基于volatile的解决方案

1
2
3
4
5
6
7
8
9
10
11
12
13
public class SafeLazyInitilization{
    private volatile static Instance instance;
    public static Instance getInstance(){
        if(instance == null){
            synchronized(DoubleCheckedLocking.class){
                if(instance == null){
                    instance = new Instance();
                }
            }
        }
        return instance;
    }
}

当声明对象的引用为volatile后，3行伪代码中的2和3之间的重排序，在多线程环境中将会被禁止，保证了线程安全的延迟初始化。

Java内存模型综述

###处理器的内存模型
顺序一致性内存模型是一个理论参考模型，JMM和处理器内存模型在设计时通常会以顺序一致性内存模型为参照。在设计时，JMM和处理器内存模型会对顺序一致性模型做一些放松，因为如果完全按照顺序一致性模型来实现处理器和JMM，那么很多的处理器和编译器优化都要被禁止，这对执行性能将会有很大的影响。根据对不同类型的读/写操作组合的执行顺序的放松，可以把常见处理器的内存模型划分为如下几种类型：

  • 放松程序中写-读操作的顺序，由此产生了Total Store Ordering内存模型（简称为TSO）;
  • 在上面的基础上，继续放松程序中写-写操作的顺序，由此产生了Partial Store Order内存模型（简称为PSO）;
  • 在前面两条的基础上，继续放松程序中读-写和读-读操作的顺序，由此产生了Relaxed Memory Order内存模型（简称为RMO）和PowerPC内存模型。

注意：这里处理器对读/写操作的放松，是以两个操作之间不存在数据依赖性为前提的（因为处理器要遵守as-if-serial语义，处理器不会对存在数据依赖性的两个内存操作做重排序）。

常见处理器内存模型的细节特征如下：
C2LZd.png

所有处理器内存模型都允许写-读重排序，因为它们都使用了写缓存区。写缓存区可能导致写-读操作重排序。同时，我们可以看到这些处 理器内存模型都允许更早读到当前处理器的写，原因同样是因为写缓存区。由于写缓存区仅对当前处理器可见，这个特性导致当前处理器可以比其他处理器先看到临时保存在自己写缓存区中的写。

表中的各种处理器内存模型，从上到下，模型由强变弱。越是追求性能的处理器，内存模型设计得会越弱。因为这些处理器希望内存模型对它们的束缚越少越好，这样它们就可以做尽可能多的优化来提高性能。由于常见的处理器内存模型比JMM要弱，Java编译器在生成字节码时，会在执行指令序列的适当位置插入内存屏障来限制处理器的重排序。同时，由于各种处理器内存模型的强弱不同，为了在不同的处理器平台向程序员展示一个一致的内存模型，JMM在不同的处理器中需要插入的内存屏障的数量和种类也不相同。

图展示了JMM在不同处理器内存模型中需要插入的内存屏障的示意图。 JMM屏蔽了不同处理器内存模型的差异，它在不同的处理器平台之上为Java程序员呈现了一个一致的内存模型。
C2jI4.png

各种内存模型之间的关系

JMM是一个语言级的内存模型，处理器内存模型是硬件级的内存模型，顺序一致性内存模型是一个理论参考模型。常见的4种处理器内存模型比常用的3中语言内存模型要弱，处理器内存模型和语言内存模型都比顺序一致性内存模型要弱。同处理器内存模型一样，越是追求执行性能的语言，内存模型设计得会越弱。
C2qzA.png

JMM的内存可见性保证

按程序类型，Java程序的内存可见性保证可以分为下列3类。

  • 单线程程序。单线程程序不会出现内存可见性问题。编译器、runtime和处理器会共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
  • 正确同步的多线程程序。正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点，JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。
  • 未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0、null、false）

注意:

最小安全性保障与64位数据的非原子性写并不矛盾。它们是两个不同的概念，它们“发生”的时间点也不同。最小安全性保证对象默认初始化之后（设置成员域为0、null或false），才会被任意线程使用。最小安全性“发生”在对象被任意线程使用之前。64位数据的非原子性写“发生”在对象被多个线程使用的过程中（写共享变量）。当发生问题时（处理器B看到 仅仅被处理器A“写了一半”的无效值），这里虽然处理器B读取到一个被写了一半的无效值，但这个值仍然是处理器A写入的，只不过是处理器A还没有写完而已。最小安全性保证线程读取到的值，要么是之前某个线程写入的值，要么是默认值（0、null、false）。但最小安全性并不保证 线程读取到的值，一定是某个线程写完后的值。最小安全性保证线程读取到的值不会无中生有的冒出来，但并不保证线程读取到的值一定是正确的。 图展示了这3类程序在JMM中与在顺序一致性内存模型中的执行结果的异同。 只要多线程程序是正确同步的，JMM保证该程序在任意的处理器平台上的执行结果，与该程序在顺序一致性内存模型中的执行结果一致。
C2wD7.png

结语

对于Java内存模型的解读比较全面。对Java内存模型的了解也比较深入同时，当然这也有助于解决在Java并发编程中经常遇到的各种内存可见性问题。

参考：
《Java并发编程的艺术》

如果觉得还不错的话，把它分享给朋友们吧(ง •̀_•́)ง