巩固剖析并发基础：并发三大特性详解 & 代码实例分析可见性问题 & 深入了解JMM模型

JMM属于整个Java并发编程中最难的部分也是最重要的部分（JAVA多线程通信模型——共享内存模型），涉及的理论知识比较多，我会从三个维度去分析：

• JAVA层面
• JVM层面
• 硬件层面

这块如何学？

这部分理解并发的三大特性，JMM工作内存和主内存关系，知道多线程之间如何通信的，掌握volatile能保证可见性和有序性，CAS就可以了，后续JVM层面和硬件层面的分析，基础比较薄弱的同学听不懂可以先跳过，从后面的Java锁机制课程听起，掌握常用的并发工具类，并发容器之后再来看JMM这块。

并发专题不可避免的会涉及到计算机组成原理和操作系统知识，对这块基础比较薄弱的，需要学习一下。

一、并发和并行

目标都是最大化CPU的使用率。

并行(parallel)：指在同一时刻，有多条指令在多个处理器上同时执行。所以无论从微观还是从宏观来看，二者都是一起执行的。

并发(concurrency)：指在 同一时刻只能有一条指令执行，但多个进程指令被快速的轮换执行，使得在宏观上具有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行。

并行在多处理器系统中存在，而并发可以在单处理器和多处理器系统中都存在，并发能够在单处理器系统中存在是因为并发是并行的假象，并行要求程序能够同时执行多个操作，而并发只是要求程序假装同时执行多个操作（每个小时间片执行一个操作，多个操作快速切换执行） 。

二、并发三大特性

并发编程Bug的源头：可见性、原子性和有序性问题。

2.1 可见性

当一个线程修改了共享变量的值，其他线程能够看到修改的值。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方法来实现可见性的。

如何保证可见性：

• 通过 volatile 关键字保证可见性（使用JVM层面的storyLoader内存屏障保证。X86 linux处理上调用fence()方法，判断处理器是否是多核，如果是则添加lock; adl $0,0 ,即在汇编层面添加Lock指令！因为在X86处理器上，认为Lock指令的性能要优于内存屏障，所以使用的是Lock指令，而并不是系统级别的内存屏障实现。注意：内存屏障和Lock前缀具有相同的作用，都可以使得更新后的值立即刷回主从，并使得其他缓存中的数据副本失效！）。
• 通过直接调用JVM中的内存屏障保证可见性。(UnsafeFactory.gertUnsafe().storeFence()，本质和volatile一样，底层还是在硬件层面上使用Lock前缀)
• 通过synchronized 关键字保证可见性。
• 通过 Lock保证可见性。
• 通过 final 关键字保证可见性。（final修饰的变量，JMM也要保证可见性！！！也需要从主从去加载。）
• Thread.yield(). (上下文切换会从主内存中重新加载数据。回复现场的时候变量对应的值要从主从加载)

总结： Java中可见性是如何保证的？
归类为两种方式：
1、JVM层面：调用storeFence内存屏障（storeLoader）；硬件层面：X86处理器下是使用Lock前缀替换内存屏障实现相同功能；

2、上下文切换（Thread.yield()）

2.2 有序性

即程序执行的顺序按照代码的先后顺序执行。JVM 存在指令重排，所以存在有序性问题。

如何保证有序性：

• 通过 volatile 关键字保证可见性。
• 通过 内存屏障保证可见性。
• 通过 synchronized关键字保证有序性。
• 通过 Lock保证有序性。

2.3 原子性

一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作（64位处理器）。不采取任何的原子性保障措施的自增操作并不是原子性的。

如何保证原子性：

• 通过 synchronized 关键字保证原子性。
• 通过 Lock保证原子性。
• 通过 CAS保证原子性。

思考：在 32 位的机器上对 long 型变量进行加减操作是否存在并发隐患？
https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7

三、Java内存模型（JMM）

3.1 JMM定义

Java虚拟机规范中定义了Java内存模型（Java Memory Model，JMM），用于屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效果，JMM规范了Java虚拟机与计算机内存是如何协同工作的： 规定了一个线程如何和何时可以看到由其他线程修改过后的共享变量的值，以及在必须时如何同步的访问共享变量。JMM描述的是一种抽象的概念，一组规则，通过这组规则控制程序中各个变量在共享数据区域和私有数据区域的访问方式， JMM是围绕原子性、有序性、可见性展开的。

3.2 JMM与硬件内存架构的关系

Java内存模型与硬件内存架构之间存在差异。硬件内存架构没有区分线程栈和堆。对于硬件，所有的线程栈和堆都分布在主内存中。部分线程栈和堆可能有时候会出现在CPU缓存中和CPU内部的寄存器中。如下图所示，Java内存模型和计算机硬件内存架构是一个交叉关系：

3.3 内存交互操作

关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成：

• lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
• unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
• read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
• load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
• use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
• assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
• store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
• write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。
  
  Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：
• 如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作， 如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。但Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。
• 不允许read和load、store和write操作之一单独出现
• 不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。
• 不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
• 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
• 一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现
• 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
• 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
• 对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。

3.3 JMM的内存可见性保证

按程序类型，Java程序的内存可见性保证可以分为下列3类：

• 单线程程序。单线程程序不会出现内存可见性问题。编译器、runtime和处理器会共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
• 正确同步的多线程程序。正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点，JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。
• 未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值未同步程序在JMM中的执行时，整体上是无序的，其执行结果无法预知。 JMM不保证未同步程序的执行结果与该程序在顺序一致性模型中的执行结果一致。

未同步程序在JMM中的执行时，整体上是无序的，其执行结果无法预知。未同步程序在两个模型中的执行特性有如下几个差异。

1）顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的操作会按程序的顺序执行，比如正确同步的多线程程序在临界区内的重排序。
2）顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程能看到一致的操作执行顺序。
3）顺序一致性模型保证对所有的内存读/写操作都具有原子性，而JMM不保证对64位的long型和double型变量的写操作具有原子性（32位处理器）。

JVM在32位处理器上运行时，可能会把一个64位long/double型变量的写操作拆分为两个32位的写操作来执行。这两个32位的写操作可能会被分配到不同的总线事务中执行，此时对这个64位变量的写操作将不具有原子性。从JSR-133内存模型开始（即从JDK5开始），仅仅只允许把一个64位long/double型变量的写操作拆分为两个32位的写操作来执行，任意的读操作在JSR-133中都必须具有原子性.

四、可见性问题深入分析

我们通过下面的Java小程序来分析Java的多线程可见性的问题：

/**
 * -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -Xcomp
 */
public class VisibilityTest {
     

    private boolean flag = true;
    
    private int count = 0;

    public void refresh() {
     
        flag = false;
        System.out.println(Thread.currentThread().getName() + "修改flag");
    }

    public void load() {
     
        System.out.println(Thread.currentThread().getName() + "开始执行.....");
        while (flag) {
     
            count++;
            //TODO  业务逻辑

        }
        System.out.println(Thread.currentThread().getName() + "跳出循环: i=" + count);
    }

    public static void main(String[] args) throws InterruptedException {
     
        VisibilityTest test = new VisibilityTest();

        // 线程threadA模拟数据加载场景
        Thread threadA = new Thread(() -> test.load(), "threadA");
        threadA.start();

        // 让threadA执行一会儿
        Thread.sleep(1000);
        // 线程threadB通过flag控制threadA的执行时间
        Thread threadB = new Thread(() -> test.refresh(), "threadB");
        threadB.start();

    }


    public static void shortWait(long interval) {
     
        long start = System.nanoTime();
        long end;
        do {
     
            end = System.nanoTime();
        } while (start + interval >= end);
    }
}   

思考：上面例子中为什么多线程对共享变量的操作存在可见性问题？

我们从JMM线程模型去思考是比较好理解的。

1、首先ThreadA调用执行load()方法将flag = true从主内存加载到工作内存，然后CPU将工作内存中的flag加载到寄存器中，然后判断flag=true，然后循环执行程序（ 注意，由于此时while(flag)这个条件恒成立，优先级是比较高的，所以运行ThreadA线程的核会被持续占有！很可能其他线程会产生线程饥饿甚至是死锁。）。

2、休眠1s之后ThreadB启动，然后会运行在另一个核上，因为第一个核仍然在被线程A占用。然后调用refresh()方法，首先将flag = true从主内存加载到工作内存，然后CPU将工作内存中的flag加载到寄存器中，然后修改flag=false（ 注意：此时修改后并不会立即将结果写入到主内存中去，而是等待该线程要被回收的时候，才会将修改后的结果写入到主内存中去，这也是导致可见性问题的一个原因）。

可见性问题分析：

此时ThreadA的工作内存中缓存了flag=true，而且死循环中的逻辑又执行的非常的快，系统认为flag这个变量是一直在被使用的，所以来不及从主内存中获取新的flag值（根据硬件设计，每隔一段时间，如果满足条件是应该要主动刷新工作内存中的值的）。所以这是导致可见性问题的一个原因！

其次是ThreadB修改flag值后并不是立刻的将这个修改刷回到主内存，而是等待线程回收的时候才会刷回，这也是导致可见性的问题之一。

那么，我们可以怎样解决可见性问题呢？

4.1 使用volatile变量修饰属性

private volatile boolean flag = true;

threadA开始执行.....
threadB修改flag
threadA跳出循环: i=455015499

Process finished with exit code 0

可以看到，使用volatile之后，是可以成功解决可见性问题的。那么volatile为何能够保证可见性呢？因为使用volatile变量修饰的属性，JVM底层解析的时候会调用storeLoad()内存屏障。

然后操作系统（Linux X86）在解析这个storeLoad()内存屏障方法的时候，会调用fence()方法。而fence()方法中会判断当前处理器核数是否为多核，如果是则会使用Lock前缀指令来代替内存屏障，因为它认为lock前缀的性能在该处理器中要优于内存屏障。所以volatile变量在X86架构上硬件底层是通过使用lock前缀来保证可见性与有序性的。

inline void OrderAccess::storeload()  {
      fence(); }
inline void OrderAccess::fence() {
     
  if (os::is_MP()) {
     
    // always use locked addl since mfence is sometimes expensive
#ifdef AMD64
    __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
#else
    __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
#endif
  }

lock前缀指令的作用：

1. 确保后续指令执行的原子性。在Pentium及之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其它处理器暂时无法通过总线访问内存，很显然，这个开销很大。在新的处理器中，Intel使用缓存锁定来保证指令执行的原子性，缓存锁定将大大降低lock前缀指令的执行开销。
2. LOCK前缀指令具有类似于内存屏障的功能，禁止该指令与前面和后面的读写指令重排序。
3. LOCK前缀指令会等待它之前所有的指令完成、并且所有缓冲的写操作写回内存(也就是将store buffer中的内容写入内存)之后才开始执行，并且根据缓存一致性协议，刷新store buffer的操作会导致其他cache中的副本失效。

4.2 使用storeFence

我们在load()方法中调用JVM中提供的storeFence方法：

public void load() {
     
        System.out.println(Thread.currentThread().getName() + "开始执行.....");
        while (flag) {
     
            count++;
            //TODO  业务逻辑
            UnsafeFactory.getUnsafeInstance().storeFence();

        }
        System.out.println(Thread.currentThread().getName() + "跳出循环: i=" + count);
    }

此时也可以保证可见性。

其实现原理和volatile一样，这里会添加一个storeLoad内存屏障，内存屏障的作用就是可以让修改后的值立即刷回主从，并使得其他缓存中的值失效。但是硬件层面，还是使用Lock前缀来实现，因为考虑的还是性能问题！注意，JVM是调用系统库函数想使用内存屏障解决这个问题，但是内存屏障的具体实现是操作系统自己决定的。X86架构中如果是多核，就认为使用Lock前缀要比内存屏障性能高！所以我们才说硬件层面是使用的Lock前缀！！！

4.3 使用synchronized关键字

public void load() {
     
        System.out.println(Thread.currentThread().getName() + "开始执行.....");
        while (flag) {
     

            //TODO  业务逻辑

            // 方式二
            // UnsafeFactory.getUnsafeInstance().storeFence();

            // 方式三
            synchronized (this) {
     
                count++;
            }

            // 方式四
            //System.out.println(flag);

        }
        System.out.println(Thread.currentThread().getName() + "跳出循环: i=" + count);
    }

注意，synchronized关键是用monitor对象锁实现的，但是最终底层也是使用内存屏障保证的。这个后面学习到synchronized的时候再详细了解。

4.4 System.out.println(flag);

 public void load() {
     
    System.out.println(Thread.currentThread().getName() + "开始执行.....");
     while (flag) {
     
         count++;
         //TODO  业务逻辑

         // 方式二
         // UnsafeFactory.getUnsafeInstance().storeFence();

         // 方式三
         System.out.println(flag);

     }
     System.out.println(Thread.currentThread().getName() + "跳出循环: i=" + count);
 }

这样也可以保证可进行跳出循环，为什么呢？查看sout方法源码可知调用了synchronized关键字。

public void println(boolean x) {
     
    synchronized (this) {
     
        print(x);
        newLine();
    }
}

4.5 Thread.yield()方法

public void load() {
     
        System.out.println(Thread.currentThread().getName() + "开始执行.....");
        while (flag) {
     

            //TODO  业务逻辑

            // 方式二
            // UnsafeFactory.getUnsafeInstance().storeFence();

            // 方式三
//            synchronized (this) {
     
//                count++;
//            }

            // 方式四
            //System.out.println(flag);

            // 方式五
            Thread.yield();

        }
        System.out.println(Thread.currentThread().getName() + "跳出循环: i=" + count);
    }

这种方式保存可见性的原理是：

Thread.yield()方法会释放CPU时间片，所以需要保存现场。但是while(true)这种优先级又是很高的所有很快又会抢到CPU执行权，所以又需要还原现场。还原现场的时候变量的值必须从主内存中重新获取，所以可以读取到flag修改后的值，可以跳出循环。

注意，这种方式不是使用内存屏障实现的。

4.5 使用Integer变量

private Integer count = 0;

public void load() {
     
        System.out.println(Thread.currentThread().getName() + "开始执行.....");
        while (flag) {
     

            //TODO  业务逻辑

            // 方式二
            // UnsafeFactory.getUnsafeInstance().storeFence();

            // 方式三
//            synchronized (this) {
     
//                count++;
//            }

            // 方式四
            //System.out.println(flag);

            // 方式五
            //Thread.yield();
            count++;

        }
        System.out.println(Thread.currentThread().getName() + "跳出循环: i=" + count);
    }

这种方式也可以跳出循环？ 为什么？？？ 是不是比较奇怪。。。

4.6 什么也不做，让方法执行的时间长一点

public void load() {
     
        System.out.println(Thread.currentThread().getName() + "开始执行.....");
        while (flag) {
     

            //TODO  业务逻辑

            // 方式二
            // UnsafeFactory.getUnsafeInstance().storeFence();

            // 方式三
//            synchronized (this) {
     
//                count++;
//            }

            // 方式四
            //System.out.println(flag);

            // 方式五
            //Thread.yield();
            count++;
            
            // 方式六
            shortWait(5000000);

        }
        System.out.println(Thread.currentThread().getName() + "跳出循环: i=" + count);
    }

public static void shortWait(long interval) {
     
    long start = System.nanoTime();
    long end;
    do {
     
        end = System.nanoTime();
    } while (start + interval >= end);
}

shortWait方法只是延长了程序的执行时间，没有任何和锁有关的代码。

我们多测试几次，看看结果：

threadA开始执行.....
threadB修改flag
threadA跳出循环: i=193

Process finished with exit code 0

threadA开始执行.....
threadB修改flag
threadA跳出循环: i=191

Process finished with exit code 0

threadA开始执行.....
threadB修改flag
threadA跳出循环: i=195

Process finished with exit code 0

可以看到这个i是随机的。

那么原理是什么呢？

记得我们前面是否分析过，while(true)这种优先级是非常高的，会一直占用CPU。如果while(true)中执行的逻辑非常短的时候，认为flag变量被一直使用，就不会主动从主内存获取新值（但是从设计的角度，执行一段时间后是需要重新获取主内存中的值的）。

但是我们现在让这段逻辑执行的时间加长了，那么系统就有条件去从主内存中获取新的值了！