[回顾并发基础] Java内存模型

concurrent

字数统计: 2.4k阅读时长: 8 min

 2019/08/25  Share

Java内存模型

JMM控制线程间的通信，定义了工作内存和主内存的抽象关系，每个线程有私有工作内存，保留该线程使用的变量的主内存副本拷贝，读写都在工作内存中进行。若要通信的话需把本地内存刷新到主内存中，另一个线程从主内存中读取。

模型三种特征

JMM的关键点都是围绕着多线程的原子性、可见性和有序性来建立的。（即为JMM如何解决前篇文中提到的并发问题）

原子性

基本数据类型的访问读写是具备原子性的（例外32位系统中long和double的读写是非原子性）。若应用场景需要更大规模的原子性保证，JVM提供了两个高级的字节码指令monitorenter和monitorexit。这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

可见性

指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。volatile可以保证可见性。普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此，可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。Java中的synchronized和final两个关键字也可以实现可见性。

synchronized规定，线程在加锁时，先清空工作内存→在主内存中拷贝最新变量的副本到工作内存→执行完代码→将更改后的共享变量的值刷新到主内存中→释放互斥锁。

synchronized 的可见性也可以通过 Happens-Before 推断：“对一个锁解锁 Happens-Before 后续对这个锁的加锁”，指的是前一个线程的解锁操作对后一个线程的加锁操作可见，综合 Happens-Before 的传递性原则，我们能得出前一个线程在临界区修改的共享变量（该操作在解锁之前），对后续进入临界区（该操作在加锁之后）的线程是可见的。

final关键字的可见性是指：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把”this”的引用传递出去（this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那在其他线程中就能看见final字段的值。

有序性

程序在执行时，可能会进行指令重排序，重排后的指令与原指令的顺序未必一致。

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

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

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

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

如果在单线程内观察，所有的操作都是有序的，这就是“线程内表现为串行的语义”（Within-Thread As-If-Serial Semantics）。而重排序对多线程则会有影响，重排序只保证单线程串行语义一直，没有义务保证多线程的语义也一致。

在Java中，可以使用volatile和synchronized来保证多线程之间操作的有序性。实现方式有所区别：volatile关键字会禁止指令重排。synchronized关键字保证同一时刻只允许一条线程操作。

as-if-serial语义
不管怎么重排序（编译器和处理器为了提高并行度），单线程程序的执行结果不能被改变。编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。as-if-serial语义把单线程程序保护了起来。

指令重排也是有原则的，并非所有指令都可以随意重排，Happens-before 可以指定两个操作之间的顺序。Happens-Before 并不是说前面一个操作发生在后续操作的前面，它真正要表达的是：前面一个操作的结果对后续操作是可见的。

Happens-Before 原则

下面的这些原则是指令重排不可违背的：

程序顺序原则：在一个线程中，前面的操作 Happens-Before 于后面任何操作。
管程锁定规则：对一个锁的解锁 Happens-Before于后续对这个锁的加锁。
传递性：如果 A happens- before B，且 B happens- before C，那么 A happens- before C。
volatile变量规则：对一个volatile变量的写操作 Happens-Before 于后面对这个变量的读操作。
线程启动规则：Thread对象的start()方法 Happens-Before 于此线程的每一个动作。
线程终止规则：线程中所有操作都 Happens-Before 于此线程的终结。
对象终结规则：对象的构造函数执行结束 Happens-Before 于finalize方法。

这些先行发生关系无须使用任何同步手段就能成立，可以在编码中直接使用，这是Java内存模型对程序员的保证。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们随意地进行重排序。

//////////程序启动规则示例/////////
Thread B = new Thread(()->{
  // 主线程调用 B.start() 之前
  // 所有对共享变量的修改，此处皆可见
  // 此例中，var==77
});
// 此处对共享变量 var 修改
var = 77;
// 主线程启动子线程
B.start();

//////////线程终止规则示例/////////
Thread B = new Thread(()->{
  // 此处对共享变量 var 修改
  var = 66;
});
// 例如此处对共享变量修改，
// 则这个修改结果对线程 B 可见
// 主线程启动子线程
B.start();
B.join()
// 子线程所有对共享变量的修改
// 在主线程调用 B.join() 之后皆可见
// 此例中，var==66

volatile

使用volatile关键字修饰的变量，保证了其在多线程之间的可见性，即当一个线程修改了这个变量的值，新值对于其他线程来说是可以立即得到的：

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存（写语义）；
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量（读语义）。

使用volatile的主要原因是其另一个特性：禁止指令重排序优化。比如说执行完某个操作时将布尔值设定为true，若没有volatile则会存在重排序的可能，设为true的操作会提前执行。编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。

“基于volatile变量的运算在并发下是安全的”不准确。20个线程，对volatile修饰的变量进行10000次自增，结果会小于200000。自增操作在加一时，变量值可能已经过期了。Volatile++ 此种复合操作无法保证原子性。

Case

Q: java 单例模式中双重检查锁定 volatile 的作用

public class Singleton {
    private Singleton() {}
    private volatile static Singleton instance;
    public Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if(instance == null){
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

instance = new Singleton(); 包含了三个操作：1.分配对象的内存空间；2.初始化对象；3.设置instance指向刚分配的内存地址。但由于存在重排序的问题，2和3可能进行重排序。用volatile修饰的话就可以禁止2和3操作重排序，从而避免这种情况。

那volatile是否起到了可见性的作用？否，第二次非null判断是在加锁以后，可见性已经由synchronized来保证了。

volatile重排序规则表

当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后。
当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。
当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。

Reference

https://time.geekbang.org/column/article/84017

《Java并发编程的艺术》

《深入理解Java虚拟机》

Next Post

JVM 类加载机制解析
Previous Post

[回顾并发基础] Java并发编程基础

CATALOG

1. Java内存模型
2. Case
1. 2.0.1. Reference

