JUC之可见性和有序性

java内存模型

可见性

现象出现

现象解释

解决方法

有序性

诡异的结果

解决方法

Happens-before规则

java内存模型

Java内存模型（Java Memory Model，简称JMM）定义了Java程序中各种变量、对象的访问方式和内存关系。JMM规定了线程之间的可见性、原子性、顺序性等问题，确保多线程并发访问时的代码正确性。

JMM中的主要概念包括：

主内存与工作内存

主内存是Java的内存模型中的高速缓存，是共享变量的存储区域，所有的线程都可以访问它。

工作内存是每个线程的私有内存，其中保存了线程执行时所需的变量副本。线程对共享变量的读写操作都在工作内存中进行，线程之间不能直接读写彼此的工作内存。
原子性

在JMM中，原子性是指一个操作是不可分割的整体，要么全部执行成功，要么全部执行失败。JMM保证单个变量的读取和赋值操作具有原子性，如果希望在多个变量上实现原子操作，需要加锁或者使用原子类。
可见性

可见性是指一个线程修改的变量对其他线程是可见的。在JMM中，并不保证一个线程修改变量后，另一个线程能够立即看到这个变化，这是因为每个线程都有自己的工作内存，线程之间不能直接读写彼此的工作内存。如果需要确保可见性，可以使用volatile关键字或者加锁同步。
有序性

有序性是指程序执行的顺序与代码编写的顺序是一致的。在JMM中，并不保证程序的执行顺序与代码编写的顺序完全一致，但是会通过各种手段尽量保证程序执行的结果符合预期。

JVM通过约束JMM，来规范多线程并发执行的行为，从而保证Java程序的正确性。虽然JMM是一个模型，但是JVM在实现时会对其进行优化，所以需要开发人员注意编写线程安全、正确、高效的程序。

JMM 体现在以下几个方面

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

可见性

现象出现

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

public class ThreadText  {
    static boolean run = true;

    public static void main(String[] args) throws InterruptedException {

        ThreadText t = new ThreadText();

        new Thread(() -> {
            System.out.println("线程启动了");
            while (run) {
//                 System.out.println("线程进行中");
            }
            System.out.println("线程即将结束了");
        }).start();

        Thread.sleep(100);

        run = false;
        System.out.println("线程状态发生改变");
    }
    
}

现象1：如果你直接运行上面代码，新创建的线程并不会停止。

现象2：如果你打开我注释的代码的话，新创建的线程会停止

现象解释

为什么呢？分析一下：

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

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

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

解决方法

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

可见性 vs 原子性

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 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-- ，只能保证看到最新值，不能解决指令交错

// 假设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

注意 synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是

synchronized 是属于重量级操作，性能相对更低如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，想一想为什么？

System.out.println导致了线程同步
public void println(String x) {
        synchronized (this) {
            print(x);
            newLine();
        }
    }
虽然没有volatile保证多线程下共享数据的可见性, 但是JMM(Java内存模型)里面的happens-before原则里面照样有其它保证数据一致性的约束存在.

有序性

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

static int i;
static int j;
// 在某个线程内执行如下赋值操作
i = ...; 
j = ...;

可以看到，至于是先执行 i 还是先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是

i = ...; 
j = ...;

也可以是

j = ...;
i = ...;

这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 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 已经执行过了）