【总结】Java内存模型

该文章为面试精华版，如果是初学者，建议学习专栏：Java并发专栏

Java并发需要结合JVM以及操作系统的相关知识，建议先学习这两个部分：JVM专栏 和 操作系统专栏

一、Java内存模型JMM

处理器上的寄存器的读写的速度比内存快几个数量级，为了解决这种速度矛盾，在它们之间加入了高速缓存。

加入高速缓存带来了一个新的问题：缓存一致性。如果多个缓存共享同一块主内存区域，那么多个缓存的数据可能会不一致，需要一些协议来解决这个问题。

所有的变量都存储在主内存中，每个线程还有自己的工作内存，工作内存存储在高速缓存或者寄存器中，保存了该线程使用的变量的主内存副本拷贝。

线程只能直接操作工作内存中的变量，不同线程之间的变量值传递需要通过主内存来完成。

二、内存间交互操作

1. lock（锁定）：作用于`主内存`的变量，它把一个变量标识为一条线程独占的状态。
2. unlock（解锁）：作用于`主内存`的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

// 读入工作内存
3. read（读取）：主内存 ---> 工作内存。
4. load（载入）：把read操作从主内存中得到的`变量值` ---> `工作内存的变量副本`。

// 中间步骤
5. use（使用）：工作内存中一个`变量的值`--->`执行引擎`，每当虚拟机遇到一个需要`使用到变量的值`的字节码指令时将会执行这个操作。
6. assign（赋值）：把一个`从执行引擎`接收到的值---赋给--->`工作内存的变量`，每当虚拟机遇到一个给变量`赋值`的字节码指令时执行这个操作。

// 写入主内存
7. store（存储）：把工作内存中一个`变量的值`--->`主内存`。
8. write（写入）：把store操作从工作内存中得到的变量的值--->主内存的变量。

三、内存模型三大特性

原子性

Java 内存模型保证了 read、load、use、assign、store、write、lock 和 unlock 操作具有原子性，例如对一个 int类型的变量执行 assign 赋值操作，这个操作就是原子性的。但是 Java 内存模型允许虚拟机将没有被 volatile 修饰的64 位数据（long，double）的读写操作划分为两次 32 位的操作来进行，即 load、store、read 和 write 操作可以不具备原子性。

int 等原子性的类型在多线程环境中不会出现线程安全问题？

有一个错误认识就是，int 等原子性的类型在多线程环境中不会出现线程安全问题。前面的线程不安全示例代码中，cnt 属于 int 类型变量，1000 个线程对它进行自增操作之后，得到的值为 997 而不是 1000。
为了方便讨论，将内存间的交互操作简化为 3 个：load、assign、store。

下图演示了两个线程同时对 cnt 进行操作，load、assign、store 这一系列操作整体上看不具备原子性，那么在 T1修改 cnt 并且还没有将修改后的值写入主内存，T2 依然可以读入旧值。可以看出，这两个线程虽然执行了两次自增运算，但是主内存中 cnt 的值最后为 1 而不是 2。因此对 int 类型读写操作满足原子性只是说明 load、assign、store 这些单个操作具备原子性。

如何保证原子性呢？

• Atomic原子类可以利用CAS的方式，在不加锁的情况下保证原子性
• synchronized 互斥锁来保证操作的原子性，它对应的内存间交互操作为：lock 和unlock

可见性

可见性指当一个线程修改了共享变量的值，其它线程能够立即得知这个修改。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值来实现可见性的。

主要有三种实现可见性的方式：

• volatile关键字，是工作内存失效
• synchronized，对一个变量执行 unlock 操作之前，必须把变量值同步回主内存 。
• final，被 final 关键字修饰的字段在构造器中一旦初始化完成，并且没有发生 this 逃逸（其它线程通过 this 引用访问到初始化了一半的对象），那么其它线程就能看见 final 字段的值。

public class FinalTest{
    final int i;
    static FinalTest obj;

    public FinalTest(){
        i  =1;
        /**
         *这里会使正在被构造的对象逸出，如果和上一句做了重排序，那么其他线程就可以通过obj访问到还为被初始化的final域。
         **/
        obj = this;
    }
}

类的 final 域在编译器层面会保证在类的构造器运行结束之前一定要初始化完成，同时 Java 内存模型会保证对象实例化后它的 final 域对其他线程是可见的，然而非 final 域并没有这种待遇。例如如下代码：

public class FinalFiled {
    final int x;
    int y;
    static FinalFiled f;

    public FinalFiled() {
        x = 100;
        y = 100;
    }

    static void writer() {
        f = new FinalFiled();
    }

    static void reader() {
        if (f != null) {
            int i = f.x;  // 保证此时一定是 100
            int j = f.y;  // 有可能此时还是 0
        }
    }
}

有序性

有序性是指：在本线程内观察，所有操作都是有序的。在一个线程观察另一个线程，所有操作都是无序的，无序是因为发生了指令重排序。在 Java 内存模型中，允许编译器和处理器对指令进行重排序，重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。

如何保证有序性？

• volatile 关键字通过添加内存屏障的方式来禁止指令重排，即重排序时不能把后面的指令放到内存屏障之前。
• 通过 synchronized 来保证有序性，它保证每个时刻只有一个线程执行同步代码，相当于是让线程顺序执行同步代码。

四、重排序

执行任务的时候，为了提高编译器和处理器的执行性能，编译器和处理器(包括内存系统，内存在行为没有重排但是存储的时候是有变化的)会对指令重排序。编译器优化的重排序是在编译时期完成的，指令重排序和内存重排序是处理器重排序

1. 编译器优化的重排序，在不改变单线程语义的情况下重新安排语句的执行顺序
2. 指指令级并行重排序，处理器的指令级并行技术将多条指令重叠执行，如果不存在数据的依赖性将会改变语句对应机器指令的执行顺序
3. 内存系统的重排序，因为使用了读写缓存区，使得看起来并不是顺序执行的

五、happens-before原则

1. 程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
2. 监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。
3. volatile规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
4. 传递性：如果Ahappens-before B，并且B happens-before C，那么A happens-before C。
5. start()规则：如果线程A执行操作ThreadB.start()，那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
6. join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

含义：两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。所以只要能够满足A的操作结果一定要对B可见

六、volatitle

1. volatitle变量为何立即可见？

在对有volatile修饰符修饰的共享变量进行写操作时，汇编代码会多一条lock前缀的指令。该指令有如下两个作用：

1. 将当前缓存行的数据回写到内存中
2. 使其他cpu里缓存了该内存地址的数据无效(缓存一致性机制)

2. 如何禁止重排序优化？

通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化

3. 和synchronized的区别？

• volatile本质是在告诉JVM当前变量在寄存器(工作内存)中的值是不确定的,需要从主存中读取; synchronized则是锁定当前变量， 只有当前线程可以访问该变量,其他线程被阻塞住直到该线程完成变量操作为止
• volatile仅能使用在变量级别; synchronized则可以使用在变量、方法和类级别
• volatile仅能实现变量的修改可见性,不能保证原子性;而synchronized则可以保证变量修改的可见性和原子性
• volatile不会造成线程的阻塞; synchronized可能会造成线程的阻塞
• volatile标记的变量不会被编译器优化; synchronized标记的变量可以被编译器优化

七、单例模式

1. 饿汉式

public class Singleton {

    private final static Singleton INSTANCE = new Singleton();
    
    private Singleton(){}

    public static Singleton getInstance(){
        return INSTANCE;
    }

}

2. 普通的懒汉式

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

• 线程不安全，不支持多线程

3. 同步方法的懒汉式

class Singleton{
    private static Singleton singleton;
    
    private Singleton(){}
    
    public static synchronized Singleton getSingleton(){
        if (singleton==null){
            singleton = new Singleton();
        }
        return singleton;
    }
}

• 线程安全，但是性能差

4. 二次检查

class Singleton{
    private static volatile Singleton singleton;

    private Singleton(){}

    public static  Singleton getSingleton(){
        if (singleton==null){
            synchronized (Singleton.class){
                if (singleton==null){
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

• 需要加一个volatile关键字，避免指令重排序如果不加volatile关键字，可能会出现空指针异常，因为在构造singleton的时候，可能也会构造其他的对象，如果出现了指令重排序，会导致singleton构造完成时，其他对象没有构造完成

5. Holder方式

class Singleton{
    
    private Singleton(){}

    private static class instanceHolder {
        private static Singleton singleton = new Singleton();
    }

    public static  Singleton getSingleton(){
        return instanceHolder.singleton;
    }
}

• 静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonInstance类，从而完成对象的实例化。

• 同时，因为类的静态属性只会在第一次加载类的时候初始化，也就保证了SingletonInstance中的对象只会被实例化一次，并且这个过程也是线程安全的。

6. 枚举

class Singleton{
    private Singleton(){}

    private enum enmuSingleton{
        INSTANCE;

        private Singleton singleton;
        enmuSingleton(){
            singleton = new Singleton();
        }

        public Singleton getSingleton() {
            return singleton;
        }
    }


    public static  Singleton getSingleton(){
        return enmuSingleton.INSTANCE.getSingleton();
    }
}