JUC之可见性和有序性

java内存模型

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

JMM中的主要概念包括：

1. 主内存与工作内存
   主内存是Java的内存模型中的高速缓存，是共享变量的存储区域，所有的线程都可以访问它。
   工作内存是每个线程的私有内存，其中保存了线程执行时所需的变量副本。线程对共享变量的读写操作都在工作内存中进行，线程之间不能直接读写彼此的工作内存。
   
2. 原子性
   在JMM中，原子性是指一个操作是不可分割的整体，要么全部执行成功，要么全部执行失败。JMM保证单个变量的读取和赋值操作具有原子性，如果希望在多个变量上实现原子操作，需要加锁或者使用原子类。
   
3. 可见性
   可见性是指一个线程修改的变量对其他线程是可见的。在JMM中，并不保证一个线程修改变量后，另一个线程能够立即看到这个变化，这是因为每个线程都有自己的工作内存，线程之间不能直接读写彼此的工作内存。如果需要确保可见性，可以使用volatile关键字或者加锁同步。
   
4. 有序性
   有序性是指程序执行的顺序与代码编写的顺序是一致的。在JMM中，并不保证程序的执行顺序与代码编写的顺序完全一致，但是会通过各种手段尽量保证程序执行的结果符合预期。
   

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

JMM 体现在以下几个方面

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

可见性

现象出现

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

1. public class ThreadText  {
2. static boolean run = true;
3. 
4. public static void main(String[] args) throws InterruptedException {
5. 
6. ThreadText t = new ThreadText();
7. 
8. new Thread(() -> {
9.             System.out.println("线程启动了");
10. while (run) {
11. //                 System.out.println("线程进行中");
12.             }
13.             System.out.println("线程即将结束了");
14.         }).start();
15. 
16.         Thread.sleep(100);
17. 
18.         run = false;
19.         System.out.println("线程状态发生改变");
20.     }
21. 
22. }

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

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

现象解释

为什么呢？分析一下：

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

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

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

解决方法

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

可见性 vs 原子性

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

1. getstatic run // 线程 t 获取 run true
2. getstatic run // 线程 t 获取 run true
3. getstatic run // 线程 t 获取 run true
4. getstatic run // 线程 t 获取 run true
5. putstatic run // 线程 main 修改 run 为 false， 仅此一次 
6. getstatic run // 线程 t 获取 run false

两个线程一个 i++ 一个 i-- ，只能保证看到最新值，不能解决指令交错

1. // 假设i的初始值为0
2. getstatic i // 线程2-获取静态变量i的值 线程内i=0
3. 
4. getstatic i // 线程1-获取静态变量i的值 线程内i=0
5. iconst_1 // 线程1-准备常量1
6. iadd // 线程1-自增 线程内i=1
7. putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1
8. 
9. iconst_1 // 线程2-准备常量1
10. isub // 线程2-自减 线程内i=-1
11. putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1

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

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

System.out.println导致了线程同步

1. public void println(String x) {
2. synchronized (this) {
3.             print(x);
4.             newLine();
5.         }
6.     }

虽然没有volatile保证多线程下共享数据的可见性, 但是JMM(Java内存模型)里面的happens-before原则里面照样有其它保证数据一致性的约束存在.

有序性

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

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

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

1. i = ...; 
2. j = ...;

也可以是

1. j = ...;
2. i = ...;

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

诡异的结果

1. int num = 0;
2. boolean ready = false;
3. // 线程1 执行此方法
4. public void actor1(I_Result r) {
5. if (ready) {
6.             r.r1 = num + num;
7.         } else {
8.             r.r1 = 1;
9.         }
10.     }
11. // 线程2 执行此方法
12. public void actor2(I_Result r) {
13.         num = 2;
14.         ready = true;
15.     }

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时，编译器和运行时都会受到限制，不能对这个变量进行指令重排。具体地说，对于volatile变量的读操作和写操作都会通过内存屏障来保证它们的顺序性和可见性。

内存屏障是一组CPU指令，可以防止处理器对内存访问进行重排序，并保证某些指令的执行顺序。对于读操作，内存屏障会使CPU在执行读指令前，强制将之前的所有修改数据的指令刷回主存；对于写操作，内存屏障会使CPU在执行写指令后，强制将数据写入主存。

Happens-before原则是Java内存模型中的一个概念，它定义了在并发情况下，对共享变量的写操作和读操作之间的可见性关系，包括线程启动、线程终止、同步块、volatile变量等多种场景，确保了多个线程之间的操作顺序。

Happens-before规则

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

具体地，如果操作A happens-before操作B，那么我们可以保证看到操作A的线程对共享变量的修改对操作B的线程是可见的。换句话说，happens-before原则规定了不同线程之间操作执行顺序的一些规范，可以避免一些因并发带来的问题。

以下是几个重要的Happens-before规则：

1. 程序的顺序性规则：一个线程内的每个操作按程序代码顺序执行
   
2. volatile变量规则：对于一个volatile变量的写操作先于后面对该变量的读操作
   
3. 传递性：如果操作A happens-before操作B，操作B happens-before操作C，则操作A happens-before操作C
   
4. synchronized规则：对于同一个锁，锁的解锁操作happens-before后续的对锁的加锁操作
   
5. 线程启动规则：一个线程的start()方法happens-before该线程的任何操作
   
6. 线程终止规则：一个线程的所有操作都happens-before其他线程检测到该线程已经终止
   
7. 对象的构造函数规则：一个对象的构造函数执行完成(happens-before)它的finalize()方法
   

Happens-before原则是Java实现多线程操作时的重要基础，在理解和分析多线程程序时，需要遵守和应用这些规则，避免出现线程安全问题。