JUC

1. 谈谈对`volatile`的理解

volatile是Java虚拟机提供的轻量级的同步机制。

三大特性：

保证可见性

一个线程修改了主内存中的值，其他线程回马上收到通知，进行同步
不保证原子性
禁止指令重排

JMM（Java内存模型）

本身是一种抽象的概念，并不真实存在，它描述的是一组规则或者规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字典和构成数组对象的元素）的访问方式。

JMM关于同步的规定：

线程解锁前，必须把共享变量的值刷新回主内存
线程加锁前，必须读取主内存的最新值到自己的工作内存
加锁解锁是同一把锁

由于JVM运行程序的实体是线程，而每个线程创建时，JVM都会为其创建一个工作内存（有些地方称为栈空间），工作内存时每个线程的私有数据区域，而JAVA内存模型中规定所有变量都存储在主内存，主内存时共享内存区域，所有线程都可以访问，但线程对变量的操作（读取赋值等）必须在工作内存中进行，首先要将变量从主内存拷贝到自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，哥哥线程中的工作内存中存储着主内存中的变量拷贝副本，因此不同的线程间无法访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成，简要访问过程如下图：

![屏幕快照 2020-05-23 16.41.11](/Users/allwayz/Desktop/屏幕快照 2020-05-23 16.41.11.png)

JMM三大特性：

可见性

一个线程修改了主内存中的值，其他线程回马上收到通知，进行同步。

通过前面对JMM的介绍，我们知道各个线程对主内存中共享变量的操作都是各个线程各自拷贝到自己工作内存进行操作后再写回到主内存中的。

这就可能存在一个线程0x00修改了共享变量X的值但还未写回主内存时，另一个线程0x01又对主内存中同一个共享变量X进行操作，但此时0x00线程工作内存中共享变量X对线程0x01来说并不可见。

这种工作内存与主内存同步延迟现象就造成了可见性问题。
原子性

number++在多线程环境下是非线程安全的，如何不加synchronized解决

![屏幕快照 2020-05-23 18.41.53](/Users/allwayz/Desktop/屏幕快照 2020-05-23 18.41.53.png)
1
2
3
4
5
6
7
8
/**
* 使用原子类来进行
* AotmicInteger
*/
AtomicInteger atomicInteger = new AtomicInteger();
public void addMyAtomic(){
atomicInteger.getAndIncrement();
}

VolatileDemo演示可见性➕原子性

/**
 * 1. 验证volatile的可见性<br>
 * 1.1 加入 int number = 0; number变量之前没有添加volatile关键字修饰<br>
 * <b>main线程没有收到number变化的消息</b><br>
 * 1.2 在 int number = 0; 前面加上 volatile<br>
 * <b>main线程在number改变的时候就监测到新的值</b><br>
 *
 * @author allwayz
 */
public class VolatileDemo {
    public static void main(String[] args) {
        MyData myData = new MyData();
        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"\t come in...");
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            myData.addT060();
            System.out.println(Thread.currentThread().getName()+"\t number ==> 60");
        },"input thread-AAA").start();

        while (myData.number == 0){

        }
        System.out.println(Thread.currentThread().getName()+"\t mission is over! number = "+myData.number);
    }
}


class MyData{
    volatile int number = 0;
    public void addT060(){
        this.number = 60;
    }
}

有序性

计算机在执行程序时，为了提高性能，编译器和处理器的常常会对指令做重排，一般分以下三种

源代码 –> 编译器优化的重排 –> 指令并行的重排 –> 内存系统的重排 –> 最终的指令

单线程环境里面确保程序最终执行结果和代码顺序执行的结果一致

处理器在进行重排序时必须要考虑指令之间的数据依赖性

多线程环境中线程交替执行，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性时无法确定的，结果无法预测。

重排 0x00

public void mySort(){
    int x = 11;	//语句1
    int y = 12;	//语句2
    x = x + 5;	//语句3
    y = x * x;	//语句4
}

执行顺序可能不一样

重排 0x01

int a,b,x,y = 0;

Thread 0x00	Thread 0x01
x = a;	y = b;
b = 1;	a = 2;

x = 0; y = 0;

如果编译器对这段程序代码执行重排优化后，可能出现下列情况

Thread 0x00	Thread 0x01
b = 1;	a = 2;
x = a;	y = b;

x = 2; y = 1;

案例

public class ReSortSeqDemo{
    int a = 0;
    boolean flag = false;
    
    public void method01(){
        a = 1;
        flag = true;
    }
    //多线程环境下，由于编译器优化重排的存在。
    //两个线程中使用的变量能否保证一致性，是无法确定的，结果无法预测
    public void method02(){
        if(flag){
            a = a + 5;
            System.out.println("retValue: " + a);
        }
    }
}

禁止指令重排小总结

volatile实现禁止指令重排优化，从而避免多线程环境下程序出现乱序执行的现象。
先了解一个概念，内存屏障（Memory Barrier）又称内存栅栏，是一个CPU指令，他的作用有两个
1. 保证特定操作的执行顺序
2. 保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）
  
  由于编译器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插入内存屏障禁止在内存屏障前后的指令集执行重排序优化。内存屏障另外一个作用时强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。

有了JMM，线程安全性获得保障

工作内存与主内存同步延迟现象导致的可见性问题

可以使用synchronized和volatile关键字解决，他们都可以使一个线程修改后的变量立即对其他线程可见
对于指令重排导致的可见性问题和有序性问题

可以使用volatile关键字解决，因为volatile的另外一个作用就是禁止重排序优化。

在那些地方使用过volatile

最经典的案例：单例模式
读写锁手写一个缓存
CAS （JUC的包里面大规模使用valatile）

单例模式DCL代码

/**
 * DCL (Double Check Lock)双端检锁机制<br>
 * 加锁之前和之后都进行判断
 *
 * @return
 */
public static SingletonDemo getInstance(){
    if(instance == null){
        synchronized (SingletonDemo.class){
            if(instance == null){
                instance = new SingletonDemo();
            }
        }
    }
    return instance;
}

单例模式volatile分析

DCL（双端检锁）机制不一定线程安全，原因是有指令重排的存在，加入volatile可以禁止指令重排

原因在于一个线程指定到第一次检测，读取到的instance != null时，instance的引用对象可能没有完成初始化。

instance = new SignletonDemo();
//可以分为以下三步完成
memory = allcate(); //1.分配对象内存空间

instance(memory);	//2.初始化对象

instance = memory;	//3.设置instance只想刚分配的内存地址，此时 instance != null

步骤2和步骤3不存在数据依赖关系，而且无论重排前还是重排后程序的执行结果在单线程中并没有改变，因此这种重排优化时允许的。

instance = new SignletonDemo();
//可以分为以下三步完成
memory = allcate(); //1.分配对象内存空间

instance = memory;	//3.设置instance只想刚分配的内存地址
//此时 instance != null,但是对象还没有初始化完成！

instance(memory);	//2.初始化对象

但是指令重排只会保证串行语义的执行的一致性（单线程），但并不会关心多线程间的语义一致性。

所以当一条线程访问instance不为null时，由于instance实例未必已完成初始化，也就造成了线程安全问题。

JUC

1. 谈谈对volatile的理解