一 volatile

主内存：所有的变量都存储在主内存。线程间变量值的传递均需要通过主内存来完成。
线程的工作内存：保存了被该线程使用的变量的主内存副本。线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同的线程之间也无法直接访问对方工作内存中的变量。线程间变量值的传递均需要通过主内存来完成。

这里所讲的主内存、工作内存与第2章所讲的Java内存区域中的Java堆、栈、方法区等并不是同一个层次的对内存的划分，这两者基本上是没有任何关系的。

如果两者一定要勉强对应起来，那么从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。从更基础的层次上说，主内存直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机（或者是硬件、操作系统本身的优化措施）可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问的是工作内存。

可见性

先来看一个现象，main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：

static boolean run = true;

public static void main(String[] args) throws InterruptedException {
 　　Thread t = new Thread(()->{
　　 　　while(run){
 　　　　　　// ....
 　　　　}
 　　});
 　　t.start();
 　　sleep(1);
 　　run = false; // 线程t不会如预想的停下来
}

为什么呢？分析一下：

1. 初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存。

2. 因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中， 减少对主存中 run 的访问，提高效率

3. 1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值

解决方法 volatile（易变关键字）

它可以用来修饰 成员变量 和 静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存

在工作内存中，每次使用V前都必须先从主内存刷新最新的值（可见性）
在工作内存中，每次修改V后都必须立刻同步回主内存中（可见性）

可见性 vs 原子性

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见，

不能保证原子性，仅用在一个写线程，多个读线程的情况（sychronized既能保证原子性也能保证可见性）。

不能解决多个线程对同一个变量读写时的指令交错问题。

有序性

int num=0;
boolean ready = false;
// 线程1 执行此方法
public void actor1(I_Result r) {
 　　if(ready) {
 　　　　r.r1 = num + num;
 　　} else {
 　　　　r.r1 = 1;
 　　}
}
// 线程2 执行此方法
public void actor2(I_Result r) { 
 　　num = 2;
 　　ready = true; 
}

I_Result 是一个对象，有一个属性 r1 用来保存结果，问，可能的结果有几种？

有同学这么分析

情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1
情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1
情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）

但我告诉你，结果还有可能是 0 ???，信不信吧！这种情况下是：线程2 执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2 相信很多人已经晕了 ???

这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化。（好像目的是为了提高指令的吞吐量？？）

在 ready 前加 volatile 可以禁止指令重排，有人问为啥不加在 num 前面呢？

因为加 volatile 可以禁止对它前面所有命令的指令重排，所以加一个就好了。

二 volatile原理

volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）

对 volatile 变量的写指令后会加入写屏障
对 volatile 变量的读指令前会加入读屏障

1.如何保证可见性

写屏障（sfence）保证在该屏障之前，对共享变量的改动，都同步到主存当中

public void actor2(I_Result r) {
 num = 2;
 ready = true; // ready 是 volatile 赋值带写屏障
 // 写屏障
}

而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

public void actor1(I_Result r) {
 // 读屏障
 // ready 是 volatile 读取值带读屏障
 if(ready) {
 　　r.r1 = num + num;
 } else {
 　　r.r1 = 1;
 }
}

2.如何保证有序性

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

public void actor2(I_Result r) {
 num = 2;
 ready = true; // ready 是 volatile 赋值带写屏障
 // 写屏障
}

读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

public void actor1(I_Result r) {
 // 读屏障
 // ready 是 volatile 读取值带读屏障
 　　if(ready) {
 　　　　r.r1 = num + num;
 　　} else {
 　　　　r.r1 = 1;
 　　}
}

3.从单例双重锁检查来看volatile

public final class Singleton {
 　 private Singleton() { }
 　　
　　private static volatile Singleton INSTANCE = null;
 
　　public static Singleton getInstance() {
 　　　　// 实例没创建，才会进入内部的 synchronized代码块
 　　　　if (INSTANCE == null) { 
 　　　　　　synchronized (Singleton.class) { // t2
 　　　　　　　　// 也许有其它线程已经创建实例，所以再判断一次
 　　　　　　　　if (INSTANCE == null) { // t1
 　　　　　　　　　　INSTANCE = new Singleton();
　　　　　　　　 }
 　　　　　　}
 　　　　}
 　　　　return INSTANCE;
 　　}
}

字节码

// -------------------------------------> 加入对 INSTANCE 变量的读屏障
0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3 // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter -----------------------> 保证原子性、可见性
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3 // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4 // Method "<init>":()V
24: putstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
// -------------------------------------> 加入对 INSTANCE 变量的写屏障
27: aload_0
28: monitorexit ------------------------> 保证原子性、可见性
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn

其中

17 表示创建对象，将对象引用入栈 // new Singleton
20 表示复制一份对象引用 // 引用地址
21 表示利用一个对象引用，调用构造方法
24 表示利用一个对象引用，赋值给 static INSTANCE

也许 jvm 会优化为：先执行 24 赋值，再执行 21 再调用构造方法（INSTANCE = new Singleton();）。如果两个线程 t1，t2 按如下时间序列执行：

上图：

t1 线程执行 INSTANCE = new Singleton(); 这一句时21行和24行重排序了，也就是先赋值再调用构造方法。
t2 线程在t1赋值完还没调用初始化之前，在这个间隙正在执行外层的 if (INSTANCE == null) ，因为t1已经赋值了，不为 null ，所以直接返回了没有初始化的 instance，若 t2 再紧接着使用这个没有初始化的 instance ，就会出现问题

关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取 INSTANCE 变量的值

这时 t1 只是被赋值了，还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例

对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效

解决

给 instance 加上 volatile 修饰。构造方法一定不能排到写屏障下面去

三 happens-before 规则

happens-before 规定了对共享变量的写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结，抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见

线程解锁 m 之前对变量的写，对于接下来对 m 加锁（sychronized）的其它线程对该变量的读可见
线程对 volatile 变量的写，对接下来其它线程对该变量的读可见
线程 start 前对变量的写，对该线程开始后对该变量的读可见
线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束）
线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过 t2.interrupted 或 t2.isInterrupted）
对变量默认值（0，false，null）的写，对其它线程对该变量的读可见

四单例其它

单例模式有很多实现方法，饿汉、懒汉、静态内部类、枚举类，试分析每种实现下获取单例对象（即调用 getInstance）时的线程安全，并思考注释中的问题

饿汉式：类加载就会导致该单实例对象被创建
懒汉式：类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建

实现1（饿汉式）

// 问题1：为什么加 final
// 问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例
public final class Singleton implements Serializable {
 　　// 问题3：为什么设置为私有? 是否能防止反射创建新的实例?
 　　private Singleton() {}
 　　// 问题4：这样初始化是否能保证单例对象创建时的线程安全?
 　　private static final Singleton INSTANCE = new Singleton();
 　　// 问题5：为什么提供静态方法而不是直接将 INSTANCE 设置为 public, 说出你知道的理由
 　　public static Singleton getInstance() {
 　　　　return INSTANCE;
 　　}
 　　public Object readResolve() {
 　　　　return INSTANCE;
 　　}
}

问题1：为什么加 final

怕有子类，子类里不适当地覆盖了父类地方法，破坏了单例

问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例（不止能用 new 创建对象，如果实现了序列化接口，反序列化也会创建对象）

加一个方法，反序列化时发现如果有 readResolve() 那么会把这个方法返回的对象当作反序列化对象，而不真正反序列化

public Object readResolve() {
 return INSTANCE;
 }

问题3：为什么设置为私有? 是否能防止反射创建新的实例?

为了防止其它类调用构造方法创建对象。但是这样不能防止反射创建新的实例。

问题4：这样初始化是否能保证单例对象创建时的线程安全?

可以，静态变量是类加载时候初始化的，由 JVM 保证它的线程安全

问题5：为什么提供静态方法而不是直接将 INSTANCE 设置为 public, 说出你知道的理由

提供更好的封装性：便于以后实现懒惰初始化；可以提供泛型的支持；可以防止其它类修改 instance

实现2（枚举类）

enum Singleton { 
 INSTANCE; 
}

问题1：枚举单例是如何限制实例个数的

问题2：枚举单例在创建时是否有并发问题
问题3：枚举单例能否被反射破坏单例
问题4：枚举单例能否被反序列化破坏单例
问题5：枚举单例属于懒汉式还是饿汉式
问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做

JZTXT

共享模型之内存

一 volatile

可见性

解决方法 volatile（易变关键字）

可见性 vs 原子性

有序性

二 volatile原理

1.如何保证可见性

2.如何保证有序性

3.从单例双重锁检查来看volatile

解决

三 happens-before 规则

四单例其它

实现1（饿汉式）

实现2（枚举类）

JZTXT

共享模型之内存

一 volatile

可见性

解决方法 volatile（易变关键字）

可见性 vs 原子性

有序性

二 volatile原理

1.如何保证可见性

2.如何保证有序性

3.从单例双重锁检查来看volatile

解决

三 happens-before 规则

四 单例其它

实现1（饿汉式）

实现2（枚举类）

四单例其它