Java内存模型的基础

本文是《java并发编程的艺术》一书的学习笔记

1.Java内存模型的抽象结构

1.Java线程之间的通讯由Java内存模型(JMM)控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。

2.线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存存储了该线程以读/写共享变量的副本。本地内存是一个抽象概念，并不真实存在。

3.Java内存模型的抽象示意图如下

如果线程A与线程B之间要通讯的话，需要经历下面两个步骤。

1.线程A把本地内存A中更新的共享变量刷新到主内存中去。
2.线程B到主内存中去读取线程A之前已更新过的共享变量。

2.happens-before简介

1.从JDK5开始，Java使用新的JSR-133内存模型。JSR-133使用happens-before的概念来阐述操作之间的内存可见性。

2.在JMM中如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。这里的操作既可以是在一个线程内，也可以在不同线程之间。

3.与程序员密切相关的happens-before规则如下

程序顺序规则:一个线程中的每个操作，happens-before于该线程中的任意后续操作。
监视器锁规则:对一个锁的解锁，happens-before于随后对这个锁加锁。
volatile变量规则:对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
传递性:如果 A happens-before B, 且 B happens-before C,那么 A happens-before C.

注意

两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！ happens-before仅仅要求前一个操作(执行的结果)对后一个操作可见，且前一个操作按顺序排在第二个操作之前

happens-before与JMM的关系如下：

Volatile内存语义

Volatile的特性

理解volatile特性的一个方法是把对volatile变量的单个读/写，看成是使用同一个锁对这个读/写做了同步。下面通过具体示例说明：

假设有多个线程分别调用上面程序的3个方法，这个程序在语义上和下面的程序等价

如上面的程序所示，一个volatile变量的单个读/写操作，与一个普通变量的读/写操作是使用同一个锁来同步，它们之间的执行效果相同。

volatile具有以下特性

可见性。当线程A对volatile变量写入时，该变量会刷新到主内存。然后当线程B读取该volatile变量时，会在主内存中进行读取，避免在自身的本地线程读取。对一个volatile变量的读，总是能看到(任意线程)对这个volatile变量最后的写入。
原子性。对任意单个volatile变量的读/写具有原子性，但类似volatile++这种复合操作不具有原子性。
禁止编译器处理器指令重排序。严格限制编译器处理器对volatile变量与普通变量的重排序，确保volatile的读/写和锁的释放/获取具有相同的内存语义。

volatile内存语义的实现

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。

下面是基于保守策略的JMM内存屏障插入策略。

在每个volatile写操作的前面插入一个StoreStore屏障
在每个volatile写操作的后面插入一个StoreLoad屏障
在每个volatile读操作的后面插入一个LoadLoad屏障
在每个volatile读操作的后面插入一个LoadStore屏障

锁的内存语义

1.当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中

2.当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使被监视器保护的临界区代码必须从主内存中读取共享变量。

final域的内存语义

1.通过为final域增加读写重排序规则，可以为java程序员提供初始化安全保证：

只要对象是正确构造的(被构造对象的引用在构造函数中没有“逸出”)，那么不需要使用同步(指lock和volatile的使用)就可以保证任意线程都能看到这个final域在构造函数中被初始化之后的值

2.为什么final引用不能从构造函数内”逸出”？

看下示例代码：

假设线程A执行writer()方法，线程B执行reader()方法。这里的操作2使得对象还未完成构造前就为线程B可见。即使这里的操作2是构造函数的最后一步，且在程序中操作2排在操作1后面，执行read()方法的线程仍然可能无法看到final域被初始化后的值，因为这里的操作1和操作2可能被重排序。

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

双重检查锁定的由来

下面是示例代码

上面的代码是有问题的，问题的根源在第7行初始化的时候。
因为初始化构造的时候会存在重排序
new DclSinglenton()初始化构造的时候可以分解如下三行伪代码：

memory = allocate(); //1.分配对象的内存空间
ctorInstance(memory);//2.初始化对象
instance = memory;//3.设置instance指向刚分配的内存地址

多线程情况下2，3可能会重排序，如下：

memory = allocate(); //1.分配对象的内存空间
instance = memory;//3.设置instance指向刚分配的内存地址
                      //注意，此时对象还没有被初始化
ctorInstance(memory);//2.初始化对象

第7行如果发生重排序，另一个并发执行的线程B就有可能在第4行判断instance不为null. 线程B接下来将访问instance所引用的对象，但此时这个对象可能还没有被A线程初始化！

解决方法：
1.不允许2和3重排序
2.允许2和3重排序，但不允许其他线程”看到“这个重排序。

基于volatile的解决方案

public class SafeDoubleCheckedLocking{
    private volatile static Instance instance;//声明volatile
    public static Instance getInstance(){
        if (instance == null){
            synchronized (SafeDoubleCheckedLocking.class){
                if (instance == null){
                    instance = new Instance(); //没有问题
                }
            }
        }
    }
}

声明对象的引用为volatile后，禁止伪代码中的2，3重排序

基于类初始化的解决方案

JVM在类的初始化阶段(即在Class被加载后，且被线程使用之前)，会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。

基于这个特性，可以实现另一种线程安全的延迟初始化方案

public class StaticInnerSingleton {
private StaticInnerSingleton() {
}
public static StaticInnerSingleton getInstance() {
    return SingletonHolder.sInstance;
}
// 静态内部类
private static class SingletonHolder {
    private static final StaticInnerSingleton sInstance = new StaticInnerSingleton();
}
}

参考：

《java并发编程的艺术》