多线程的可见性，原子性和指令重排

多线程的 可见性，原子性，指令重排

一.可见性

1.1 看程序说结果

public class VolatileThread extends Thread {

    // 定义成员变量
    private boolean flag = false ;
    
    public boolean isFlag() { 
        return flag;
    }

    @Override
    public void run() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 将flag的值更改为true
        this.flag = true ;
        System.out.println("flag=" + flag);
    }
}

public class VolatileThreadDemo {// 测试类
    
    public static void main(String[] args) {
        // 创建VolatileThread线程对象
        VolatileThread volatileThread = new VolatileThread() ;
        volatileThread.start();

        // main方法
        while(true) {
            if(volatileThread.isFlag()) {
                System.out.println("执行了======");
            }
        }
    }
}

结果：

我们看到，VolatileThread线程中已经将flag设置为true，但main()方法中始终没有读到，从而没有打印。

1.2 JMM

概述：JMM(Java Memory Model) Java内存模型，是java虚拟机规范中所定义的一种内存模型。

Java内存模型(Java Memory Model)描述了Java程序中各种变量(线程共享变量)的访问规则，以及在JVM中将变量存储到内存和从内存中读取变量这样的底层细节。

所有的共享变量都存储于主内存。这里所说的变量指的是实例变量和类变量。不包含局部变量，因为局部变量是线程私有的，因此不存在竞争问题。

**每一个线程还存在自己的工作内存，**线程的工作内存，保留了被线程使用的变量的工作副本。线程对变量的所有的操作(读，取)都必须在工作内存中完成，而不能直接读写主内存中的变量，不同线程之间也不能直接访问对方工作内存中的变量，线程间变量的值的传递需要通过主内存完成。

关于JMM的一些同步的约定：

1.线程解锁前，必须把共享变量立刻刷回主存

2.线程加锁前，必须读取主存中的最新值到工作内存中

3.加锁和解锁是同一把锁

1.3 问题分析

1. VolatileThread线程从主内存读取到数据放入其对应的工作内存
2. 将flag的值更改为true，但是这个时候flag的值还没有写回主内存
3. 此时main方法读取到了flag的值为false
4. 当VolatileThread线程将flag的值写回去后，但是main函数里面的while(true)调用的是系统比较底层的代码，速度快，快到没有时间再去读取主存中的值，所以while(true)读取到的值一直是false。(如果有一个时刻main线程从主内存中读取到了主内存中flag的最新值，那么if语句就可以执行，main线程何时从主内存中读取最新的值，我们无法控制)

引发：

​ 多个线程访问共享变量，会出现一个线程修改变量的值后，其他线程看不到变量最新值的情况。

总结：

​ 并发编程下，多线程修改变量，会出现线程间变量的不可见性。

不可见性原因：

​ 每个线程都有自己的工作内存，线程都是从主内存拷贝共享变量的副本值。

​ 每个线程都是在自己的工作内存中操作共享变量的。

1.4 问题处理

方式一：加锁synchronized

使用synchronized关键字：

   // main方法
   while(true) {
       synchronized (volatileThread) {
           if(volatileThread.isFlag()) {
               System.out.println("执行了======");
           }
       }
   }

工作原理：

某一个线程进入synchronized代码块前后，执行过程入如下：

a.线程获得锁

b.清空工作内存

c.从主内存拷贝共享变量最新的值到工作内存成为副本

d.执行代码

e.将修改后的副本的值刷新回主内存中

f.线程释放锁

方式二：volatile关键字

使用volatile关键字：

   private volatile boolean flag ;

工作原理：

1.VolatileThread线程从主内存读取到数据放入其对应的工作内存中

2.将flag的值更改为true，但是这个时候flag的值还没有写回主内存

3.此时main方法main方法读取到了flag的值为false

4.当VolatileThread线程将flag的值写回去后，失效其他线程对此变量副本

5.再次对flag进行操作的时候线程会从主内存读取最新的值，放入到工作内存中

总结： volatile保证不同线程对共享变量操作的可见性，也就是说一个线程修改了volatile修饰的变量，当修改写回主内存时，另外一个线程立即看到最新的值。

现象：

​ 并发编程下，多线程修改变量，会出现线程间变量的不可见性。

解决线程间变量的不可见性的方案有两种常见方式：

​ 1.加锁

​ 解决原因：会清空工作内存，读取主内存中最新值到工作内存中来。

​ 2.对共享的变量进行volatile关键字修饰

​ 解决原因：一旦一个线程中的变量，添加了volatile修饰符，其它线程可以立即读取到最新值

1.5 volatile与synchronized的区别

1).volatile只能修饰实例变量和类变量，而synchronized可以修饰方法，以及代码块。

2).volatile保证数据的可见性，但是不保证原子性(即：多线程进行写操作，不保证线程安全)；而synchronized是一种排他（互斥）的机制，实现线程安全。

3).从性能上说，volatile更好点，仅仅是对实现线程间变量的可见性上。

二. 原子性

​ 概述：所谓的原子性是指在一次操作或者多次操作中，要么所有的操作全部都得到了执行并且不会受到任何因素的干扰而中断，要么所有的操作都不执行。

2.1 看程序说结果

public class VolatileAtomicThread1 implements Runnable {
    // 定义一个int类型的遍历
    private int count = 0 ;

    @Override
    public void run() {
        // 对该变量进行++操作，100次
        for(int x = 1 ; x <= 100 ; x++) {
            count++ ;					
            System.out.println("count =========>>>> " + count);
        }
    }
}

public class VolatileAtomicThreadDemo1 {
    
    public static void main(String[] args) {
        // 创建VolatileAtomicThread对象
        VolatileAtomicThread1 volatileAtomicThread = new VolatileAtomicThread1() ;

        // 开启100个线程对count进行++操作
        for(int x = 1 ; x <= 100 ; x++) {
            new Thread(volatileAtomicThread).start();
        }
    }
}

执行结果：不保证一定是10000

2.2 问题原理说明

以上问题主要是发生在count++操作上：

count++操作包含3个步骤：

• 从主内存中读取数据到工作内存
• 对工作内存中的数据进行++操作
• 将工作内存中的数据写回到主内存

count++操作不是一个原子性操作，也就是说在某一个时刻对某一个操作的执行，有可能被其他的线程打断。

1）假设此时x的值是100，线程A需要对改变量进行自增1的操作，首先它需要从主内存中读取变量x的值。由于CPU的切换关系，此时CPU的执行权被切换到了B线程。A线程就处于就绪状态，B线程处于运行状态。

2）线程B也需要从主内存中读取x变量的值,由于线程A没有对x值做任何修改因此此时B读取到的数据还是100。

3）线程B工作内存中x执行了+1操作，但是未刷新到主内存中。

4）此时CPU的执行权切换到了A线程上，由于此时线程B没有将工作内存中的数据刷新到主内存，因此A线程工作内存中的变量值还是100，没有失效。A线程对工作内存中的数据进行了+1操作。

5）线程B将101写入到主内存。

6）线程A将101写入到主内存。

虽然计算了2次，但是只对A进行了1次修改。

2.3 volatile原子性测试

代码测试

// 定义一个int类型的变量
private volatile int count = 0 ;

小结：在多线程环境下，volatile关键字可以保证共享数据的可见性，但是并不能保证对数据操作的原子性（在多线程环境下volatile修饰的变量也是线程不安全的）。

在多线程环境下，要保证数据的安全性，我们还需要使用锁机制。

volatile的使用场景

• 开关控制

  利用可见性特点，控制某一段代码执行或者关闭(比如今天课程的第一个案例)。

• 多个线程操作共享变量，但是是有一个线程对其进行写操作，其他的线程都是读

2.4 问题解决

方式一：使用锁机制synchronized

​ 我们可以给count++操作添加锁，那么count++操作就是临界区的代码，临界区只能有一个线程去执行，所以count++就变成了原子操作。

public class VolatileAtomicThread2 implements Runnable {
    // 定义一个int类型的变量
    private volatile int count = 0 ;
    private static final Object obj = new Object();

    @Override
    public void run() {
        // 对该变量进行++操作，100次
        for(int x = 1 ; x <= 100 ; x++) {
            synchronized (obj) {
                count++ ;
                System.out.println("count =========>>>> " + count);
            }
        }
    }
}

public class VolatileAtomicThreadDemo2 {
    
    public static void main(String[] args) {
        // 创建VolatileAtomicThread对象
        VolatileAtomicThread2 volatileAtomicThread = new VolatileAtomicThread2() ;

        // 开启100个线程对count进行++操作
        for(int x = 1 ; x <= 100 ; x++) {
            new Thread(volatileAtomicThread).start();
        }
    }
}

方式二：原子类

​ Java从JDK1.5开始提供了java.util.concurrent.atomic包(简称Atomic包)，这个包中的原子操作类提供了一种用法简单，性能高效，线程安全地更新一个变量的方式。

AtomicInteger

原子型Integer，可以实现原子更新操作

public AtomicInteger()：	   				初始化一个默认值为0的原子型Integer
public AtomicInteger(int initialValue)： 初始化一个指定值的原子型Integer

int get():   			 				 获取值
int getAndIncrement():      			 以原子方式将当前值加1，注意，这里返回的是自增前的值。
int incrementAndGet():    				 以原子方式将当前值加1，注意，这里返回的是自增后的值。
int addAndGet(int data):				 以原子方式将输入的数值与实例中的值（AtomicInteger里的                                            value）相加，并返回结果。
int getAndSet(int value):   			 以原子方式设置为newValue的值，并返回旧值。

案例改造

使用AtomicInteger对案例进行改造.

public class VolatileAtomicThread3 implements Runnable {
    // 定义一个int类型的变量
    private AtomicInteger atomicInteger = new AtomicInteger() ;

    @Override
    public void run() {
        // 对该变量进行++操作，100次
        for(int x = 1; x <= 100 ; x++) {
            int i = atomicInteger.getAndIncrement();
            System.out.println("count =========>>>> " + i);
        }
    }
}

public class VolatileAtomicThreadDemo3 {
    public static void main(String[] args) {
        // 创建VolatileAtomicThread对象
        VolatileAtomicThread3 volatileAtomicThread = new VolatileAtomicThread3() ;

        // 开启100个线程对count进行++操作
        for(int x = 1 ; x <= 100 ; x++) {
            new Thread(volatileAtomicThread).start();
        }
    }
}

2.5 原子类CAS机制实现线程安全

2.5.1 概述

CAS的全称是： Compare And Swap(比较再交换)；是现代CPU广泛支持的一种对内存中的共享数据进行操作的一种特殊指令。

CAS可以将read-modify-check-write转换为原子操作，这个原子操作直接由处理器保证。

CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。

举例：

1. 在内存地址V当中，存储着值为10的变量。

2. 此时线程1想要把变量的值增加1。对线程1来说，旧的预期值A=10，要修改的新值B=11。

3. 在线程1要提交更新之前，另一个线程2抢先一步，把内存地址V中的变量值率先更新成了11。

4. 线程1开始提交更新，首先进行A和地址V的实际值比较（Compare），发现A不等于V的实际值，提交失败。

5. 线程1重新获取内存地址V的当前值，并重新计算想要修改的新值。此时对线程1来说，A=11，B=12。这个重新尝试的过程被称为自旋。

6. 这一次比较幸运，没有其他线程改变地址V的值。线程1进行Compare，发现A和地址V的实际值是相等的。

7. 线程1进行SWAP，把地址V的值替换为B，也就是12。

可以使用AtomicInteger类中的public final boolean compareAndSet(int expect , int update)方法进行校验。

2.5.2 CAS总结

比较当前工作内存中的值和主内存中的值，如果这个值是期望的，那么则执行操作，如果不是就一直循环。

缺点：

1.循环会耗时

2.一次性只能保证一个共享变量的原子性

3.会出现ABA问题（此时建议引入原子引用，使用带版本号的原子操作，例如：AtomicStampedReference中的getStamp()方法）

2.6 CAS与Synchronized：乐观锁与悲观锁

共同点：

CAS和Synchronized都可以保证多线程环境下共享数据的安全性。

不同点：

**Synchronized**是从悲观的角度出发**（悲观锁）**

​ 总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。因此Synchronized我们也将其称之为悲观锁。JDK中的ReentrantLock也是一种悲观锁。性能较差！

CAS是从乐观的角度出发**（乐观锁）**

​ 总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。CAS这种机制我们也可以将其称之为乐观锁。综合性能较好！

三. 指令重排

3.1 什么是重排序？

​ 重排序就是编译器或者CPU的代码的的结构重排排序，已达到最佳的执行效果。重排大概分为编译器重排，处理器重排。

// 编译器重排
//优化前
int x = 1;
int y = 2;
int a1 = x * 1;
int b1 = y * 1;
int a2 = x * 2;
int b2 = y * 2;

//优化后
int x = 1;
int y = 2;
int a1 = x * 1;
int a2 = x * 2;
int b1 = y * 1;
int b2 = y * 2;

//经过这样的优化，可能对于CPU来说只要读取一次的x和y值。而原来的可能需要反复读取寄存器来交替x和y的值。

// 处理器重排
//初始化：
int a = 0;
int b = 0;
int x = 0;
int y = 0;

//处理器A执行
a = 1; //A1
x = b; //A2  

//处理器B执行
b = 2; //B1
y = a; //B2  

​ 由于处理器有读、写缓存区，写缓存区没有及时刷新到内存，造成其他处理器读到的值不是最新的，使得处理器执行的读写操作与内存上反应出的顺序不一致。

​ 上面这个例子，可能造成处理器A读到的b=0，处理器B读到的a=0。A1写a=1先写到处理器A的写缓存区中，此时内存中a=0。如果这时处理器B从内存中读a，读到的将是0。

3.2 代码案例

public class Barrier {

    int a = 0;
    int b = 0;
    int x = 0;
    int y = 0;

    //创建单个线程的线程池
    private static ExecutorService executorService1= Executors.newSingleThreadExecutor();
    private static ExecutorService executorService2= Executors.newSingleThreadExecutor();
    private static ExecutorService executorService3= Executors.newSingleThreadExecutor();

    public static void main(String ... args){
        for (int i=0;i< 1000000;i++){
            //初始化
            Barrier barrier=new Barrier();

            //处理器A执行
            executorService1.submit(()->{
                barrier.a = 1; //A1
                barrier.x = barrier.b; //A2
                print(barrier);
            });

            //处理器B执行
            executorService2.submit(()->{
                barrier.b = 2; //B1
                barrier.y = barrier.a; //B2
                print(barrier);
            });
        }
    }

    public static void print(Barrier barrier){
        executorService3.submit(()->{
            if(barrier.x==0 && barrier.y==0){
System.out.println("=======>"+barrier.a+" , "+barrier.b+" , "+barrier.x+" , "+barrier.y);
            }else {
System.out.println(barrier.a+" , "+barrier.b+" , "+barrier.x+" , "+barrier.y);
            }
        });
    }

}

此时运行结果， 可以看到，确实有可能都是0。那么我们有没有办法解决这个问题呢？这时候我们就要提到内存屏障了。

3.3 内存屏障

3.3.1 概述

为了解决上述问题，处理器还是使用提供了个武器——内存屏障指令（Memory Barrier）：

1. 写内存屏障（Store Memory Barrier）：处理器将当前存储缓存的值写回主存，以阻塞的方式。
2. 读内存屏障（Load Memory Barrier）：处理器处理失效队列，以阻塞的方式。

​ 通过加入内存屏障，保证了两个操作之间数据的可见性。 volatile关键字通过“内存屏障”来防止指令被重排序 ， volatile会在读取数据前插入一个读屏障，写数据之后加入一个写屏障，所以，它可以避免CPU重排导致的问题，实现多线程之间数据的可见性。

3.3.2 内存屏障的主要类型

​ 为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。然而，对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能，为此，Java内存模型采取保守策略。

下面是基于保守策略的JMM内存屏障插入策略：
在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障。
在每个volatile读操作的前面插入一个LoadStore屏障。

内存屏障的主要类型（以下了解即可）
不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由JVM来为不同的平台生成相应的机器码。
Java内存屏障主要有Load和Store两类。
对Load Barrier来说，在读指令前插入读屏障，可以让高速缓存中的数据失效，重新从主内存加载数据
对Store Barrier来说，在写指令之后插入写屏障，能让写入缓存的最新数据写回到主内存

对于Load和Store，在实际使用中，又分为以下四种：

LoadLoad 屏障
序列：Load1,Loadload,Load2
确保Load1所要读入的数据能够在被Load2和后续的load指令访问前读入。通常能执行预加载指令或/和支持乱序处理的处理器中需要显式声明Loadload屏障，因为在这些处理器中正在等待的加载指令能够绕过正在等待存储的指令。 而对于总是能保证处理顺序的处理器上，设置该屏障相当于无操作。

StoreStore 屏障
序列：Store1，StoreStore，Store2
确保Store1的数据在Store2以及后续Store指令操作相关数据之前对其它处理器可见（例如向主存刷新数据）。通常情况下，如果处理器不能保证从写缓冲或/和缓存向其它处理器和主存中按顺序刷新数据，那么它需要使用StoreStore屏障。

LoadStore 屏障
序列： Load1; LoadStore; Store2
确保Load1的数据在Store2和后续Store指令被刷新之前读取。在等待Store指令可以越过loads指令的乱序处理器上需要使用LoadStore屏障。

StoreLoad 屏障
序列: Store1; StoreLoad; Load2
确保Store1的数据在被Load2和后续的Load指令读取之前对其他处理器可见。StoreLoad屏障可以防止一个后续的load指令 不正确的使用了Store1的数据，而不是另一个处理器在相同内存位置写入一个新数据。正因为如此，所以在下面所讨论的处理器为了在屏障前读取同样内存位置存过的数据，必须使用一个StoreLoad屏障将存储指令和后续的加载指令分开。Storeload屏障在几乎所有的现代多处理器中都需要使用，但通常它的开销也是最昂贵的。它们昂贵的部分原因是它们必须关闭通常的略过缓存直接从写缓冲区读取数据的机制。这可能通过让一个缓冲区进行充分刷新（flush）,以及其他延迟的方式来实现。

3.3.3 示例

下面是在保守策略下，volatile读插入内存屏障后生成的指令序列示意图：

上述volatile写和volatile读的内存屏障插入策略非常保守。在实际执行时，只要不改变volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。

下面我们通过具体的示例代码来说明：

class VolatileBarrierExample {
    int a;
    volatile int v1 = 1;
    volatile int v2 = 2;

    void readAndWrite() {
        int i = v1;           // 第一个volatile读
        int j = v2;           // 第二个volatile读
        a = i + j;            //普通写
        v1 = i + 1;           // 第一个volatile写
        v2 = j * 2;           // 第二个 volatile写
    }

    …                    //其他方法
}

针对readAndWrite()方法，编译器在生成字节码时可以做如下的优化：

3.4 volatile总结

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

1.保证可见性

2.不保证原子性

3.禁止指令重排

volatile是可以保持可见性，不能保证原子性，由于内存屏障，可以保证避免指令重排的现象产生。