共享模型之内存

monitor主要是关注访问共享变量的时候，保证临界区代码的原子性。

下面学习共享变量在多线程之间的可见性问题和多条指令之间执行的有序性问题。

JMM 即 Java Memory Model，它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、 CPU 指令优化等。

• JMM 体现在以下几个方面
  • 原子性 - 保证指令不会受到线程上下文切换的影响
  • 可见性 - 保证指令不会受 cpu 缓存的影响
  • 有序性 - 保证指令不会受 cpu 指令并行优化的影响

原子性

基于基本数据类型的访问，读写都是具备原子性的，更大范围的原子性保证，JAVA内存模型提供了lock和unlock的操作来满足，也可以使用synchronized锁机制来保证原子性。

可见性

volatile变量可以保证变量的可见性，但是普通的变量不能保证这一点。

除了volatile关键字保证可见性外，synchronized和final两个关键字也可以保证可见性，synchronized保证可见性是基于在unlock之前，会先把变量的值写会到主存之中保证的，而final关键字的可见性指的是被final修饰的变量在构造器中一旦初始化完成，并且在构造器中没有吧this的引用传递出去，那么其他的线程就可以看见final关键字的值，

有序性

java语言中提供volatile和synchronized两个关键字来保证有序性，volatile关键字本身就可以禁止指令重拍，而synchronized则是由一个变量在同一时刻只允许一个线程对其进行lock操作所保证的。

Java内存模型

JMM 即 Java Memory Model，它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。

主要目的是定义程序中各种变量之间的访问规则。也就是关注虚拟机中国把变量的值存储到内存和从内存中取出变量的值这样的底层细节，这里的变量指的是实例字段，静态字段和数组对象，不包括局部变量和方法的参数，因为这两者是线程私有的，不会被共享。

java内存模型规定的所有变量都保存在主内存中，但是每一条线程都还有各自的工作内存，工作内存中保存的是主内存中变量的副本，线程对所有变量的操作都是在工作内存中进行的，不可以直接操作主内存中的数据。多个线程之间的通信需要通过主内存进行。

JMM 体现在以下几个方面

• 原子性 - 保证指令不会受到线程上下文切换的影响
• 可见性 - 保证指令不会受cpu缓存的影响
• 有序性 - 保证指令不会受 cpu 指令并行优化的影响

volatile关键字可以保证可见性和有序性，不能保证原子性。

可见性

退不出循环

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

public class Test38 {
    static boolean flag=false;

    public static void main(String[] args) throws InterruptedException {
        Thread t=new Thread(()->{
            while (flag){}
        });
        t.start();

        System.out.println("主线程开始执行");
        Thread.sleep(1);
        flag=true;
    }
}

原因分析

1. 初始状态， t 线程刚开始从主内存读取了run的值到工作内存。主存就是存储共享变量的地方，工作内存是各个线程私有的地方。

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

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

解决方法

volatile（易变关键字）

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

解决方法代码说明

//使用volatile关键字
public class Test38 {
     volatile static boolean flag=true;

    public static void main(String[] args) throws InterruptedException {
        Thread t=new Thread(()->{
            while (flag){}
        });
        t.start();

        System.out.println("主线程开始执行");
        Thread.sleep(2);
        flag=false;
    }
}
//使用synchronized关键字
public class Test38 {
     volatile static boolean flag=true;
     public static final Object lock=new Object();

    public static void main(String[] args) throws InterruptedException {
        Thread t=new Thread(()->{
            while (flag){
                synchronized (lock){
                    if(!flag){
                        break;
                    }
                }
            }
        });
        t.start();

        System.out.println("主线程开始执行");
        Thread.sleep(2);
       synchronized (lock){
           flag=false;
       }
    }
}

synchronized是重量级的，所以在解决可见性方面推荐使用volatile关键字

可见性和原子性的理解

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见， 不能保证原子性，仅用在一个写线程，多个读线程的情况： 上例从字节码理解是这样的：

getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
putstatic run // 线程 main 修改 run 为 false， 仅此一次
getstatic run // 线程 t 获取 run false

比较一下之前我们将线程安全时举的例子：两个线程一个 i++ 一个 i-- ，使用volatile关键字只能保证看到最新值，不能解决指令交错，也就是不能保证指令的原子性。

// 假设i的初始值为0
getstatic i // 线程2-获取静态变量i的值 线程内i=0
getstatic i // 线程1-获取静态变量i的值 线程内i=0
iconst_1 // 线程1-准备常量1
iadd // 线程1-自增 线程内i=1
putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1
iconst_1 // 线程2-准备常量1
isub // 线程2-自减 线程内i=-1
putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1
  
//上面的例子中，对i添加volatile关键字只能保障获取最新的i值，并不能保证指令不会交错执行

注意

• synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是 synchronized 是属于重量级操作，性能相对更低
• volatile关键字可以保证可见性和有序性，不能保证原子性。
• 如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，想一想为什么？

源码角度看

public void println(String x) {
        synchronized (this) {
            print(x);
            newLine();
        }
    }
//println()函数里面添加了synchronized关键字，可以保障对共享变量访问的可见性

CPU的缓存结构

指令级并行原理

名词

• Clock Cycle Time：主频的概念大家接触的比较多，而 CPU 的 Clock Cycle Time（时钟周期时间），等于主频的倒数，意思是 CPU 能够识别的最小时间单位，比如说 4G 主频的 CPU 的 Clock Cycle Time 就是 0.25 ns，作为对比，我们墙上挂钟的Cycle Time 是 1s，例如，运行一条加法指令一般需要一个时钟周期时间

• CPI:有的指令需要更多的时钟周期时间，所以引出了 CPI （Cycles Per Instruction）指令平均时钟周期数

• IPC:IPC（Instruction Per Clock Cycle） 即 CPI 的倒数，表示每个时钟周期能够运行的指令数

• CPU的执行时间

程序的 CPU 执行时间，即我们前面提到的 user + system 时间，可以用下面的公式来表示

程序 CPU 执行时间 = 指令数 * CPI * Clock Cycle Time

指令重排序优化

• 事实上，现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令。为什么这么做呢？可以想到指令还可以再划分成一个个更小的阶段，例如，每条指令都可以分为： 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 这 5 个阶段

• 在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行，这一技术在 80's 中叶到 90's 中叶占据了计算架构的重要地位。

提示： 分阶段，分工是提升效率的关键！

指令重排的前提是，重排指令不能影响结果，例如

// 可以重排的例子
int a = 10; // 指令1
int b = 20; // 指令2
System.out.println( a + b );
// 不能重排的例子
int a = 10; // 指令1
int b = a - 5; // 指令2

支持流水线的处理器

现代 CPU 支持多级指令流水线，例如支持同时执行取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 的处理器，就可以称之为五级指令流水线。这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一条执行时间最长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了指令地吞吐率。

多条指令可以同时执行，不会影响结果。

SuperScalar 处理器

• 大多数处理器包含多个执行单元，并不是所有计算功能都集中在一起，可以再细分为整数运算单元、浮点数运算单元等，这样可以把多条指令也可以做到并行获取、译码等，CPU 可以在一个时钟周期内，执行多于一条指令，IPC

CPU 缓存结构原理

cpu缓存结构

速度比较

内存屏障

Memory Barrier（Memory Fence）

• 可见性
  • 写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中
  • 而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据
• 有序性
  • 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
  • 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

模式

使用volatile关键字改进两阶段中止模式

如果某一个线程正在睡眠之中而被打断，就会重新设置打断标记，所以我们在catch块中需要重新打断一次，恢复打断标记，这种做法不方便，所以使用一个变量作为标记。

public class Test10 {
    public static void main(String[] args) throws InterruptedException {
        TwoPhaseTermination t1=new TwoPhaseTermination();
        t1.start();

//        主线程休眠3.5秒
        Thread.sleep(3500);
//        主线程去打断子线程的执行
        t1.stop();

    }
}

class TwoPhaseTermination{
//    创建一个监控线程
    private Thread monitor;
  //因为两个线程访问这变量，所以要保证可见性
    private static volatile boolean flag=false;
//    启动监控线程
    public void start(){
        monitor=new Thread(()->{
//            在这里时刻监控当前线程是否被打断
            while (true){
                boolean interrupt=Thread.currentThread().isInterrupted();
                if(flag){
                    System.out.println("程序已经被打断........");
                    break;
                }
//                如果没有被打断，就执行监控操作
                try {
//                    在下面这两条语句都有可能被打断
                    Thread.sleep(1000);//这种情况如果被打断，打断标记将会被设置为false，这里打断会抛出异常
//                    下面语句如果被打断，那么是正常被打断，她的的打断标记会设置为true,可以正常退出
                    System.out.println("执行监控记录......");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                  //不需要重新设置打断标记
                }
            }
        });
        monitor.start();
    }
//monitor是一个线程，调用stop方法的是另一个线程，两个线程修改同一个变量，存在可见性问题
//    所以标记需要添加volatile关键字

//    提供停止监控线程
    public void stop(){
//        对线程进行打断
        flag=true;
      //如果当前线程正在睡眠，那么使用interrupt()可以尽快让线程打断
      monitor.interrupt();
    }
}

同步模式之-baking模式

上面的监控线程，每调用一次，都会创建一个新的监控线程，这样会创建大量的监控线程，这样做是没有意义的。

定义

Balking （犹豫）模式用在一个线程发现另一个线程或本线程已经做了某一件相同的事，那么本线程就无需再做了，直接结束返回

代码实现

public class Test10 {
    public static void main(String[] args) throws InterruptedException {
        TwoPhaseTermination t1=new TwoPhaseTermination();
      //两次调用监控线程，会创建两个监控线程
        t1.start();
        t1.start();

//        主线程休眠3.5秒
//        Thread.sleep(3500);
////        主线程去打断子线程的执行
//        t1.stop();

    }
}

class TwoPhaseTermination{
//    创建一个监控线程
    private Thread monitor;
    private static boolean flag=false;

//    添加一个boolean表示start()是否被调用过
    private boolean starting=false;
//    启动监控线程
    public void start(){
//下面的判断在单线程下可以正确执行，但是在多线程下就会出现问题
       synchronized (this){
         //这个锁是保证starting在多线程情况下正确执行，注意和flag区分开，因为starting共享变量既有读也有写，有多行语句，所以使用锁
//           锁中的代码越多，执行时间越长，所以也可以把锁添加在对starting的修改中，并不会影响并发程度
           if(starting){
//            如果starting为真，就说明已经有监控线程了，就不在需要创建监控线程，直接返回
               return;
           }
           starting=true;
         //可以把线程的创建放在锁的外面，可以提高效率，思考为什么？
           monitor=new Thread(()->{
//            在这里时刻监控当前线程是否被打断
               while (true){
                   boolean interrupt=Thread.currentThread().isInterrupted();
                   if(flag){
                       System.out.println("程序已经被打断........");
                       break;
                   }
//                如果没有被打断，就执行监控操作
                   try {
//                    在下面这两条语句都有可能被打断
                       Thread.sleep(1000);//这种情况如果被打断，打断标记将会被设置为false，这里打断会抛出异常
//                    下面语句如果被打断，那么是正常被打断，她的的打断标记会设置为true,可以正常退出
                       System.out.println("执行监控记录......");
                   } catch (InterruptedException e) {
                       e.printStackTrace();
//                  重新设置打断标记
                       Thread.currentThread().interrupt();//在这里把打断标记重新设置为true
                   }
               }
           });
       }
        monitor.start();
    }
//monitor是一个线程，调用stop方法的是另一个线程，两个线程修改同一个变量，存在可见性问题
//    所以标记需要添加volatile关键字

//    提供停止监控线程
    public void stop(){
//        对线程进行打断
        monitor.interrupt();
        flag=true;
    }
}
//多次启动线程，只会创建一个线程
//同步块越短，性能越好，思考为什么？

线程安全的单例模式

public final class Singleton {
    private Singleton() {
    }
    private static Singleton INSTANCE = null;
  //synchronized锁保证多线程的安全，是一种懒惰创建对象，先判断有没有对象，有的话直接返回，没有的话在创建对象
    public static synchronized Singleton getInstance() {
        if (INSTANCE != null) {
            return INSTANCE;
        }

        INSTANCE = new Singleton();
        return INSTANCE;
    }
}

对比一下保护性暂停模式：保护性暂停模式用在一个线程等待另一个线程的执行结果，当条件不满足时线程等待。

有序性

JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码

static int i;
static int j;
// 在某个线程内执行如下赋值操作
i = ...;
j = ...;
//可以看到，至于是先执行 i 还是 先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是
i = ...;
j = ...;
//也可以是
j = ...;
i = ...;

这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU执行指令的原理来理解一下吧

参考前面的cpu缓存结构和cpu缓存结构原理章节

代码示例

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 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现

解决方法

volatile 修饰的变量，可以禁用指令重排

volatile boolean ready = false;
//给ready添加volatile关键字，可以防止给ready赋值之前的语句进行重排序操作

volatile关键字原理

两个作用

1. 保证某一个变量对所有线程的可见性，，也就是当一个线程对某一个变量修改了之后，新的值对于其他的线程来说是立即可知的。
2. 基于volatile的变量在并发的环境下不一定是线程安全的。volatile变量不存在线程一致性问题，但是java里面的运算操作符并非是原子操作的，所以不一定线程安全。就比如race变量用volatile修饰过，虽然改变race变量对于其他线程可见，但是++操作并不是原子操作，所以非线程安全。
3. 使用volatile的第二个语义是可以保证指令重拍操作。

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

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

如何保证可见性

写屏障（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;
 }
}
//也就是在读取之前添加一个读屏障，在读屏障之后所有的读取操作都会在主存中读取

图示

如何保证有序性

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

 public void actor2(I_Result r) {
        num = 2;
        ready = true; // ready 是 volatile 赋值带写屏障
        // 写屏障
    }
//也就是说num=2指令不会出现在ready=true指令的后面

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

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

图示

还是那句话，不能解决指令交错：比如i++或者i–的指令交错问题。

• 写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去
• 而有序性的保证也只是保证了本线程内相关代码不被重排序，本线程内的读写操作有序，但是两个线程之间的读写操作并不能保证有序，所以这可能就会导致指令交错。
• volatile只能解决有序性和可见性，不能保证原子性，但是synchronized三者都可以保证。

比如上图中t2线程在t1线程写入之前已经读取i的值，然后在写入，所以volatile不能保证指令交错问题。

double-checked locking 问题

以著名的 double-checked locking 单例模式为例

public final class Singleton {
    private Singleton() { }
    private static Singleton INSTANCE = null;
    public static Singleton getInstance() {
        if(INSTANCE == null) { // t2
            // 首次访问会同步，而之后的使用没有 synchronized
            synchronized(Singleton.class) {
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}
synchronized加的范围太大，对性能的影响较大
上面的代码存在问题，因为INSTANCE可能存在指令重拍问题

• 以上的实现特点是：
  • 懒惰实例化
  • 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
  • 有隐含的，但很关键的一点：第一个 if 使用了 INSTANCE 变量，是在同步块之外

但在多线程环境下，上面的代码是有问题的，getInstance 方法对应的字节码为：

0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;//获取静态对象
3: ifnonnull 37 //if语句判断是否是null
6: ldc #3 // class cn/itcast/n5/Singleton //获取类对象进行加锁
8: dup//复制类对象的引用指针
9: astore_0 //存储类对象的引用指针
10: monitorenter //进入同步代码块，创建monitor对象
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton; //获取静态变量
14: ifnonnull 27//判断静态变量是否是空，如果不是空，就执行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;
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。如果两个线程 t1，t2 按如下时间序列执行：

• 关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取INSTANCE 变量的值
• 这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例
• 对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效

注意：上面说过，synchronized可以保证操作的可见性，原子性，有序性，但是上面INSTANCE 对象的创建过程还是出现了问题，所以synchronized可以保证操作的可见性，原子性，有序性是有一个前提的，也就是共享变量完全被synchronized锁保护的时候，那么共享变量的使用是没有有序性，原子性和可见性的问题，但是上面的共享变量INSTANCE 并没有被完全的保护，因为在锁之外还有一次判断操作。

double-checked locking 解决

public final class Singleton {
    private Singleton() { }
  //添加volatile关键字即可
    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;
    }
}

字节码上看不出来 volatile 指令的效果

// -------------------------------------> 加入对 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

• 如上面的注释内容所示，读写 volatile 变量时会加入内存屏障（Memory Barrier（Memory Fence）），保证下面两点：

  • 可见性

    写屏障（sfence）保证在该屏障之前的 t1 对共享变量的改动，都同步到主存当中 而读屏障（lfence）保证在该屏障之后 t2 对共享变量的读取，加载的是主存中最新数据

  • 有序性

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

  • 更底层是读写变量时使用 lock 指令来多核 CPU 之间的可见性与有序性

图解

下面加24put()之前添加写屏障，也就是put()之前的指令不可以被重排序到写屏障之后。如果t2在put之前获取数据，那么获取的是Null值，那么这个时候可以由synchronized来保证安全性。

happens-before

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

• 线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见,synchronized`会保证对共享变量的原子性，可见性，有序性。

 //synchronized对共享变量的影响
    static int x;
    static Object m = new Object();
new Thread(()->{
synchronized(m){
        x=10;
        }
        },"t1").start();
        new Thread(()->{
synchronized(m){
        System.out.println(x);
        }
        },"t2").start();

• 线程对 volatile 变量的写，对接下来其它线程对该变量的读可见

//volatile修饰的变量，一个线程对变量的修改，对其他线程可见
//volatile本来就是保证可见性问题的
volatile static int x;
new Thread(()->{
        x = 10;
        },"t1").start();
new Thread(()->{
        System.out.println(x);
        },"t2").start();

• 线程start前对变量的写，对该线程开始后对该变量的读可见

static int x;
x = 10;
new Thread(()->{
 System.out.println(x);
},"t2").start();

• 线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束）

static int x;
Thread t1 = new Thread(()->{
 x = 10;
},"t1");
t1.start();
t1.join();
System.out.println(x);

• 线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过 t2.interrupted 或 t2.isInterrupted）

static int x;
    public static void main(String[] args) {
        Thread t2 = new Thread(()->{
            while(true) {
                if(Thread.currentThread().isInterrupted()) {
                    System.out.println(x);
                    break;
                }
            }
        },"t2");
        t2.start();
        new Thread(()->{
            sleep(1);
            x = 10;
          //在这里吧t2线程打断，但是在打断之前对变量已经修改，这个修改对t2线程是可见的
            t2.interrupt();
        },"t1").start();
        while(!t2.isInterrupted()) {
            Thread.yield();
        }
        System.out.println(x);
    }

• 对变量默认值（0，false，null）的写，对其它线程对该变量的读可见
• 具有传递性，如果x hb-> y并且 y hb-> z 那么有 x hb-> z ，配合 volatile 的防指令重排，有下面的例子

volatile static int x;
static int y;
new Thread(()->{
 y = 10;
 x = 20;
  //在写入x之前会添加一个写屏障，屏障之前的内容都会同步到主存当中
},"t1").start();
new Thread(()->{
 // x=20 对 t2 可见, 同时 y=10 也对 t2 可见
  //因为虚拟机会在读之前添加读屏障，读屏障之前的代码全部会同步到主存内
 System.out.println(x);
},"t2").start();

变量都是指成员变量或静态成员变量

balking 模式习题

希望 doInit() 方法仅被调用一次，下面的实现是否有问题，为什么？

public class TestVolatile {
 volatile boolean initialized = false;
 void init() {
 if (initialized) {
 return;
 }
 doInit();
 initialized = true;
 }
 private void doInit() {
 }
}
//不会仅仅调用一次，因为initialized被volatile修饰，仅仅可以保证共享变量的可见性，代码中有多次对共享变量进行修改，并不能保证代码执行的原子性，所以有可能两个线程都会执行到initialized = true;，但是都还没有对共享变量进行修改，所以可能执行多次方法，解决方法是用synchronized保证原子性

volatile适用于一个线程写，其他线程读的情况，这样可以保证写线程的写对所有的读线程均可见。

线程安全单例练习

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

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

实现一

// 问题1：为什么加 final-->防止有子类继承，然后重写其中的方法，破坏单例模式
// 问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例
public final class Singleton implements Serializable {
 // 问题3：为什么设置为私有? 是否能防止反射创建新的实例?--》防止调用构造器创建对象，不能，利用反射可以重新设置构造器的可见性
 private Singleton() {}
 // 问题4：这样初始化是否能保证单例对象创建时的线程安全?--》可以，静态变量的初始化操作是在类加载阶段完成，类加载阶段是由jvm保证线程安全性的
 private static final Singleton INSTANCE = new Singleton();//饿汉式，类加载时候已经初始化
 // 问题5：为什么提供静态方法而不是直接将 INSTANCE 设置为 public, 说出你知道的理由
  //用方法提供更好的封装性，可以实现懒惰的初始化，还可以支持泛型
 public static Singleton getInstance() {
 return INSTANCE;
 }
  //问题二的答案，这样做返回的时候回直接返回单例的那个对象，而不会直接返回使用反序列化生成的那个对象
 public Object readResolve() {
 return INSTANCE;
 }
}

实现二

// 问题1：枚举单例是如何限制实例个数的,枚举类里面的变量其实就是静态变量，也就是实例的个数
// 问题2：枚举单例在创建时是否有并发问题，没有，应为其成员变量也是静态的，会在类加载阶段初始化，由虚拟机保证线程的安全性
// 问题3：枚举单例能否被反射破坏单例，不能
// 问题4：枚举单例能否被反序列化破坏单例，可以避免反序列化时候出现问题，不需要自己干预
// 问题5：枚举单例属于懒汉式还是饿汉式,饿汉式，类加载时候已经初始化
// 问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做，添加构造方法
enum Singleton {
 INSTANCE;
}

实现三

public final class Singleton {
 private Singleton() { }
 private static Singleton INSTANCE = null;
 // 分析这里的线程安全, 并说明有什么缺点
  //把锁添加在静态方法上相当于添加在class对象上面，可以控制对静态变量的访问，缺点是锁的范围太大，第一次调用创建对象加锁，以后每一次获取对象，都要加锁，降低性能 
 public static synchronized Singleton getInstance() {
 if( INSTANCE != null ){
 return INSTANCE;
 }
 INSTANCE = new Singleton();//懒汉式
 return INSTANCE;
 }
}
//可以保证线程安全问题，锁住的是类对象
//如果一个对象是null，那么不能加锁，因为无法关联monitor对象

对象是null的话不可以加锁

实现四

public final class Singleton {
    private Singleton() { }
    // 问题1：解释为什么要加 volatile ?
 // synchronized代码块中的指令会发生重排序，对于synchronized代码块外面的指令，有可能先做赋值操作，然后在进行初始化，所以外面拿到的引用对象就没有进行初始化，也就是没有调用构造方法
  instance对象没有完全被synchronized锁保护，所以可能会发生指令重排序操作，使用volatile可以避免这种情况发生，也就是说对于获取锁的线程，先对instance做赋值操作，然后在调用构造方法，对于外面的线程，此时instance已经不是空，那么获取的对象实例还没有经过调用沟改造方法初始化，所以使用vaolatie可以防止指令排序操作，也就是防止synchronized内部重排序，即使赋值操作和调用构造方法之间重排序
    private static volatile Singleton INSTANCE = null;

    // 问题2：对比实现3, 说出这样做的意义
  第一次调用需要加锁初始化对象，后续再次获取对象的时候就不需要进行加锁操作，可以支架获取锁。方法三实现每次都粗腰加锁，开销很大
  
    public static Singleton getInstance() {
        if (INSTANCE != null) {
            return INSTANCE;
        }
        synchronized (Singleton.class) {
            // 问题3：为什么还要在这里加为空判断, 之前不是判断过了吗
          //为了防止首次去创建对象，多个线程并发问题造成创建对象超过一个
          //比如t1线程首次来获取对象，发现对象是空的，那么就会获取锁创建对象，但是这个时候换没有创建对象，也就是对象的初始化没有完成，此时t2线程也来获取对象，发现对象是空，也进来创建对象，但是这个时候无法获取到锁，那么就会阻塞，当t1线程创建好对象退出时候，这个时候t2线程获取到了锁，然后创建对象，这种情况就创建了2个对象，所以需要在锁内部再次进行判断，这样就可以避免那种情况的发生
            if (INSTANCE != null) { // t2
                return INSTANCE;
            }
            INSTANCE = new Singleton();
            return INSTANCE;
        }
    }
}

实现五

public final class Singleton {
    private Singleton() { }
    // 问题1：属于懒汉式还是饿汉式
    private static class LazyHolder {
      //懒汉式，因为类的加载机制就是懒汉式，首次使用的时候才会进行加载，所以第一次加载并不会加载内部类，第一次只会加载外部的来，内部类并不会被加载，所以内部的静态变量也不会初始化，只有使用到的时候才会进行加载
        static final Singleton INSTANCE = new Singleton();
    }
    // 问题2：在创建时是否有并发问题，没有，线程安全，由jvm保证线程安全
    public static Singleton getInstance() {
        return LazyHolder.INSTANCE;
    }
}

本章小结

本章重点讲解了 JMM 中的

• 可见性 - 由 JVM 缓存优化引起
• 有序性 - 由 JVM 指令重排序优化引起
• happens-before 规则
• 原理方面
  • CPU 指令并行
  • volatile
• 模式方面
  • 两阶段终止模式的 volatile 改进
  • 同步模式之 balking（用于只希望某一段代码执行一次的情况）

reetrantlock模式问题

线程八锁问题

贡献者

codingLab

版权所有

版权归属：codingLab

许可证：bugcode