JVM高级特性与实践（十二）：高效并发时的内外存交互、三大特征（原子、可见、有序性）与 volatile型变量特殊规则

最新推荐文章于 2022-08-29 20:11:26 发布

尼古拉斯--赵四

最新推荐文章于 2022-08-29 20:11:26 发布

阅读量501

点赞数

分类专栏： JVM

JVM 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

Amdahl 定律：该定律通过系统中并行化与串行化的比重来描述多处理器系统能获得的运算加速能力。
摩尔定律：该定律用于描述处理器晶体管数量与运行效率间的发展关系。

并发处理的刚反应用时使得 Amdahl 定律代替摩尔定律成为计算机性能发展源动力的根本原因，也是人类“压榨”计算机运算能力的最有力武器。

多任务处理几乎是现代计算机操作系统的一项必备功能，由于计算机的运算速度与它的存储和通信子系统速度差距太大，大量时间花费在磁盘IO等，所以才去多任务充分利用计算机处理器能力。

“高效并发”将是此篇博文的主题，涉及到的知识点：

硬件、Java内存模型介绍
高效并发时的内外存交互操作
对于volatile 、long 和double型变量的特殊规则
并发过程三大特性
先行发生规则

一. 内存模型

1. 硬件的效率与一致性

（1）物理计算机中的并发

并发问题

首先需要了解以下物理计算机中的并发问题，“让计算机并发执行若干个运算任务”与“更充分地利用计算机处理器的效能”之间的因果关系，两者之前关系并非简单，因为绝大多数的运算任务不可能只靠处理器“计算”就能完成，处理器至少要与内存交互，此IO操作很难消除。

解决方法

由于计算机的存储设备与处理器的运算速率有几个数量级的差距，所以现代计算机必须引入一层读写速度尽可能接近处理器速度的高速缓存（cache）来作为内存与处理器间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓冲同步回内存中，这样处理器就无须等待缓慢的内存读写了。

（2）缓存一致性（Cache Coherence）

缓存的引入产生了一个新问题——缓存一致性：在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存，如下图所示

这里写图片描述

出现问题

当多个处理器的运算任务都涉及到同一块内存区域时，将可能导致各自的缓存数据不一致，那同步到内存时以谁的数据为准呢？

解决方法

需要各个处理器遵循一些协议，在读写时要根据协议来进行操作，这类协议有 MSI， MESI等。

（3）乱序执行

为了使得处理器内部的运算单元能够被尽量使用，处理器可能对输入代码进行乱序执行优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的。

2. Java 内存模型

Java虚拟机规范试图定义一种Java内存模型来屏蔽掉各种硬件和操作系统的内存访问差异，以实现Java程序在各种平台下都能达到一致的内存访问效果。

（1）Java内存模型的主要目标

定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中读取变量这样的底层细节。此处的变量不同于Java编程，不包括局部变量与方法参数，因为后者是线程私有的，不被共享，自然不会存在竞争问题。

（2）Java内存模型规定

Java内存模型规定了：所有的变量都存储在主内存中。

每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取，赋值）都必须在工作内存中进行，而不能直接读写内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量。

（3）线程、内存、工作内存三者关系

线程间变量值的传递均需要通过主内存来完成：线程、内存、工作内存三者关系如下所示：

这里写图片描述

这里所讲的主内存、工作内存与前面讲解Java内存区域中的Java堆、栈、方法区等不适同一个层次划分，两者无任何关系。

3. 内存间交互操作

（1）完成主内存与工作内存交互协议的8种操作

关于主内存与工作内存间的交互协议，即一个变量如何从主内存拷贝到工作内存，如何从工作内存同步回主内存的实现细节。Java 内存模型中定义了以下8种操作（operations）来完成：

lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load 动作使用。
load（载入）：作用于工作内存的变量，它把 read 操作从主内存中得到的变量放入工作内存的变量副本中。
use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中。

（2）执行8种操作需满足的规则

如果要把一个变量从主内存复制到工作内存，那就要顺序地执行 read 和 load 操作。如果要把变量从工作内存同步到主内存，就要顺序地操作 store 和 write 操作。

注意： Java内存模型只要求上述两个操作必须按照顺序执行，而没有保证是连续执行。也就是说，read 和 load 之间、store 和 write 之间是可插入其他指令的。如对内存中的变量a、b 进行访问时，一种可能出现的顺序是：read a、read b、load b、load a 。

除此之外，Java内存模型还规定在执行上述8种操作需满足的规则：

不允许read和 load，store 和 write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现。
不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
不允许一个线程无原因地（没有发生过任何 assign操作）把数据从线程的工作内存同步回主内存中。
一个新变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化的变量，换句话说，对一个变量实施 use，store操作前，必须先执行过 assign 和 load 操作。
一个变量在同一个时刻只允许一个线程对其进行lock 操作，但lock操作可以被同一条线程重复执行多次，多次执行 lock后，只有执行相同次数的unlock 操作，变量才会被解锁。
如果对一个变量执行lock 操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行 load 或 assign 操作初始化变量的值。
如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去 unlock 一个被其他线程锁定住的变量；
对一个变量执行unlock 变量前，必须先把此变量同步回主内存中（执行store， write操作）。

（3）小结

这8种内存访问操作以及上述规则限定，再加上稍后介绍的对 volatile 的一些特殊规定，就已经完全确定了java 程序中哪些内存访问操作在并发下是安全的。

二. Java内存模型中的两大特殊规则

1. 对于 volatile 型变量的特殊规则

（1）volatile的特性 —– 可见性

概念

保证此变量对所有线程的“可见性”，这里的“可见性”指：当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量做不到这一点，其在线程间传递需要通过主内存来完成。例如，线程A修改一个普通变量的值，然后向主内存进行回写，另外一条线程B在线程A回写完成之后再从主内存进行读取操作，新变量值才会对线程B可见。

“可见性”的误解

对于volatile变量的可见性，有一些误解： “volatile变量对所有线程都是可见的，对volatile变量所有的写操作都能立刻反应到其他线程中，即volatile变量在各个线程中是一致的，所有基于 volatile变量的运算在并发下是安全的”。上述语句中的错误在于并不能得出“基于 volatile变量的运算在并发下是安全的”这个结论。

并发下volatile的不安全性示例

volatile变量在各个线程的工作内存中不存在一致性问题，但Java运算并非原子操作，导致 volatile变量的运算在并发下一样是不安全的，通过一段演示来说明：

public class VolatileTest {  
    public static volatile int race = 0;  

    public static void increase() {  
        race++;  
    }  

    public static final int THREADS_COUNT = 20;  

    public static void main(String[] args) {  
        Thread[] threads = new Thread[THREADS_COUNT];  
        for (int i = 0; i < threads.length; i++) {  
            threads[i] = new Thread(new Runnable() {  
                @Override  
                public void run() {  
                    for (int j = 0; j < 10000; j++) {  
                        increase();  
                    }  
                }  
            });  
            threads[i].start();  
        }  

        // 等待所有累计线程都ending  
        while(Thread.activeCount() > 1) {  
            Thread.yield();  
        }  
        System.out.println(race);  
    }  
}  
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

3次运算结果：

这里写图片描述

结果分析

以上代码发起了20个线程，每个线程都对 race 变量进行10000 次自增操作。如果这段代码能够正确并发，最后输出结果是200000。但是我运行了3次，得出的结果都是小于200000的一个数字。

并发失败原因

问题在于自增运算race++ ，当我们用javap反编译这段代码得到如下图所示，发现只有一行代码的increase() 方法在Class文件中是由4条字节码指令构成（return指令不是由 race++产生的，这条指令可不算），从字节码层面上分析并发失败原因：当 getstatic 指令把race的值取到操作栈顶时，volatile 关键字保证了 rece 的值此时是正确的，但是在执行 iconst_1、iadd这些指令时，其他线程可能已经把 race的值加大了，而在操作栈顶的值就变成了过期的数据，所以 putstatic 指令执行后就可能把较小的 race 值同步回内存之中。

increa() 方法对应的字节码：

这里写图片描述

小结

客观而言，在此使用字节码分析并发问题并不严谨，因为即使编译出来的只有一条字节码指令，并不意味执行这条指令是一个原子操作。

由于 volatile 变量只能保证可见性，在不符合以下两条规则的运算场景中，仍然要通过加锁（使用 synchronize 或 java.util.concurrent中的原子类）来保证原子性。

运算结果并不依赖变量的当前值，或者能确保只有单一的线程修改变量的值。
变量不需要与其他的状态变量共同参与不变约束。

像以下代码所示的这类场景很适合使用 volatile 变量来控制并发，当showdown() 方法被调用时，能保证所有线程中执行的doWork() 方法立即停下来：

// 使用volatile变量来控制并发  
public class VolatileVariableTest {  
    volatile boolean shutdownRequested; // volatile变量  

    public void shutdown() {  
        shutdownRequested = true;  
    }  
    public void doWork() {  
        while(!shutdownRequested) {  
            // do sth.  
        }  
    }
 
 1
2
3
4
5
6
7
8
9
10
11
12

（2）volatile的特性 —– 禁止指令重排序优化

使用volatile变量的第二个语义是禁止指令重排序优化：普通变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，这也就是java 内存模型中描述的所谓的 “线程内表现为串行的语义”。

上述理论略微抽象，通过一个实际例子来了解：

【指令重排序演示（伪代码）】

        Map configOptions;  
        char[] configText;  
        //  此变量必须为 volatile  
        volatile boolean initialized = false;  

        // 假设以下代码在线程A 中执行  
        // 模拟读取配置信息，当读取完成后将 initialized 设置为true 已通知其他线程配置可用  
        configOptions = new HashMap();  
        configText = readConfigFile(filename);  
        processConfigOptions(configText, configOptions);  
        initialized = true;  

        // 假设以下代码在线程B 中执行  
        // 等待initialized 为true，代表线程A 已经把配置信息初始化完成  
        while(!initialized) {  
            sleep();  
        }  
        // 使用线程A 中初始化好的配置信息  
        doSomethingWithConfig();  
    }  
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

代码解析

以上程序是一段伪代码，描述场景十分常见。如果定义initialized变量没有使用volatile修饰：就可能会由于指令重排序的优化，导致位于线程A 中最后一句码initialized=true被提前执行（即这行代码对应的汇编代码被提前执行），这样在线程B中使用配置信息的代码就可能出现错误，而volatile关键字则可以避免此类情况的发生。

内存屏障示例

接下来再以一个实例来分析volatile关键字是如何禁止指令重排序优化的，以下代码是一段单例模式代码，可以观察加入 volatile和未加入volatile关键字时所生成汇编代码的差别：

【 单例模式（分析volatile关键字是如何禁止指令重排序优化的）】

public class Singleton {  
    private volatile static Singleton instance;  

    public static Singleton getInstance() {  
        if(instance == null) {  
            synchronized (Singleton.class) { // 同步块  
                if(instance == null) {  
                    instance = new Singleton();  
                }  
            }  
        }  
        return instance;  
    }  

    public static void main(String[] args) {  
        Singleton.getInstance();  
    }  
}  
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

编译后，这段代码对 instance赋值部分生产的汇编代码：

这里写图片描述

分析

通过对比，volatile修饰的区别就是上图红框标记的指令操作，它的作用相当于一个内存屏障（Memory Barrier），指重排序时不能把后面的指令重排序到内存屏障之前的位置。当两个或以上的CPU访问同一块内存时，需要内存屏障来保证一致性。

为何说它禁止指令重排序呢？

从硬件上而言，指令重排序呢是指CPU采用允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。并非说是任意重排，例如（a*b）+c 与 c+（a+b），代表c相加的指令是可以重排的。因此，上图中红框中的指令把修改同步到内存时，意味着所有之前的操作都已经执行完成，这便形成了“指令重排序无法越过内存屏障”的效果。

使用 volatile 还是锁？

众多保障并发工具都使用了volatile 关键字，在某些情况下，它的同步机制性能要优于锁（使用synchronized 关键字或java.util.concurrent包里的锁），但由于虚拟机对锁实行的许多消除和优化，它并非快多少。

若让volatile 关键字与自己比较，可确定一个原则：它读操作的、性能消耗与普通变量几乎无差别，写操作可能较慢，因为需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。但即便如此，大多数volatile 关键字的总开销仍比锁低，选择的唯一依据是它的语义能否满足使用常见的要求。

2. 对于 long 和 double 型变量的规则

（1）64位数据类型的非原子性协定

Java内存模型要求lock， unlock， read， load， assign， use，store，write这8个操作都具有原子性，但对于64位的数据类型（long和double），在模型中特别定义了一条相对宽松的规定：允许虚拟机将没有被 volatile 修饰的64位数据的读写操作划分为两次 32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的 load， store，read和write 这4个操作的原子性，这点就是所谓的 long 和double 的非原子性协定（Nonatomic Treatment of double and long Variable）。

（2）非原子性协定导致的问题

如果有多个线程共享一个并未声明为 volatile的 long 或 double类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了“半个变量”的数值。

（3）“半个变量”的情况

不过这种读取到的“半个变量”的情况非常罕见（商业JVM中尚未出现）：因为Java内存模型虽然允许虚拟机不把long 和 double 变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为具有原子性的操作，而且还强烈建议虚拟机这样实现。

实际开发中，目前各平台下的商用虚拟机几乎选择把64位数据读写操作作为原子操作来对待，因此平时编写代码时不需要把long 和 double 变量专门声明为 volatile。

三. 并发过程三大特征与先行发生原则

1. 原子性、可见性与有序性

以上介绍完Java内存模型的相关操作和规则，再次整体回顾一下此模型特征。Java内存模型是围绕着在并发过程中如何处理原子性，可见性和有序性这3个特征来建立的。

（1）原子性（Atomicity）

定义

由于Java内存模型来直接保证的原子性变量操作包括 read，load，assign，use，store和write，我们大致认为基本数据类型的访问读写数据是具备原子性的。

更大范围的原子性保证

如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock 和 unlock 操作来满足这些需求，尽管虚拟机没有把lock 和 unlock 操作直接开放给用户使用，但是却提供了更高层次的字节码指令 monitorenter 和 monitorexit 来隐式地使用这两个操作。

synchronized关键字

monitorenter 和 monitorexit 这两个字节码指令反映到java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

（2）可见性（Visibility）

定义

可见性：指当一个线程修改了共享变量的值，其他能够立即得知这个修改。

Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此

普通变量与 volatile变量的区别

volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新，所以volatile保证了多线程操作时变量的可见性，普通变量则不能保证这一点。

synchronized 和 final关键字

除了volatile关键字外，Java还有两个关键字实现可见性： synchronized 和 final。

synchronized同步块的可见性：是由对一个变量执行unlock 操作前，必须先把此变量同步回主内存中；
final关键字的可见性：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把this 的引用传递出去（this引用传递很危险，其他线程很有可能通过此引用访问到“初始化了一半”的对象），那在其他线程中就能看见final 字段的值。

关于final关键字的可见性，下面通过一个简单例子进行说明，以下代码中的变量i 与 j 都具备可见性，它们无须同步就能被其他线程正确访问：

public class FinalVisibilityTest {  
    public static final int i;  

    public final int j;  

    static {  
        i = 0;  
        // do sth  
    }  
    {  
        // 也可以选择在构造函数中初始化  
        j = 0;  
        // do sth  
    }  
}     
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

（3）有序性（Ordering）

java程序中天然的有序性总结为一句话

如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指 “线程内表现为串行”的语义，后半句是指 “指令重排序”现象和“工作内存与主内存同步延迟”现象。

volatile和 synchronized关键字保证了线程间操作的有序性

volatile关键字本身就包含了禁止指令重排序的语义。
synchronized则是由一个变量在同一时刻只允许一条线程对其进行lock 操作这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行地进入。

（4）小结

介绍完以上3种特性后，发现synchronized关键字在需要这3中特性时都可以作为其中一种解决方案。大部分的并发控制操作都能使用synchronized完成，也间接造成程序员滥用的现象。需要注意，这种“万能”的并发控制，往往伴随着较大的性能影响，后续讲解。

2. 先行发生（happens-before）原则

若Java内存模型中所有的有序性都仅仅靠 volatile 和 synchronized 来完成，那么有些操作将很繁琐，而Java语言中的“先行发生”语言已考虑到，它是按断数据是否存在竞争、线程是否安全的主要依据。

（1）定义

先行发生原则定义：先行发生是Java内存模型中定义的两项操作之间的偏序关系，如果说操作A 先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到，影响包括修改了内存中共享变量的值，发送了消息，调用了方法等。

（2）实例解释

下面通过一个简单例子来说说明：

【先行发生原则示例1】

        // 以下操作在线程A中执行  
        i = 1;  
        // 以下操作在线程 B 中执行  
        j = i;  
        // 以下操作在线程 C 中执行  
        i = 2;   
 
 1
2
3
4
5
6
7
8

代码分析

线程A先于线程B操作，可以肯定线程B执行完后，j一定等于1，得出结论的依据：根据先行原则，i = 1; 的结果可被观察和线程C还未“登场”，线程A执行完后暂时没有其它线程修改i 的值。

来考虑C，线程C 出现在线程A 和 B之间，但线程C 和 B 并没有先行发生关系，那j 的值会是多少，答案是1还是2不确定的，线程B存在读取到过期数据的危险，不具备线程安全性。

（3）先行发生规则

下面是 Java内存模型下一些天然的先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用：

程序次序规则（Program Order Rule）：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作，准确地说，应该是控制流顺序。
管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作；这里必须强调的是同一个锁，而后面是指时间上的先后顺序。
volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的后面是指时间上的先后顺序。
线程启动规则（Thread Start Rule）： Thread对象的start() 方法先行发生于此线程的每一个动作。
线程终止规则（Thread Temination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，可以通过Thread.join() 方法结束，Thread.isAlive() 的返回值等手段检测到线程已经终止运行。
线程中断规则（Thread Interruption Rule）：对线程interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 Thread.interrrupted() 方法检测到是否有中断发生。
对象终结规则（Finalizer Rule）：一个对象的初始化完成先行发生于它的finalize() 方法的开始。
传递性（Transitivity）：如果操作A 先行发生于操作B，操作B 先行发生于操作C，那就可以得出操作A 先行发生于操作C的结论。

（4）时间先后顺序与先行发生原则关系探讨

以下示例来判定操作间是否具备顺序性，对于读写共享变量操作而言，就是线程是否安全，理解“时间上的顺序”和“先行发生”的不同：

private int value = 0;  

    public void setValue(int value) {  
        this.value = value;   
    }  

    public int getValue() {  
        return value;  
    }  
 
 1
2
3
4
5
6
7
8
9

问题假设

以上代码是经常出现JavaBean中的 get/set方法，假设线程A 先调用了 setValue(1)，之后线程B 调用了同一个对象的getValue() ，那么线程B 收到的value是什么？

问题分析

仔细对比以上先行发生规则，并无对应，因此可以判定尽管线程A在操作时间上先于线程B，但是无法确定线程B 中getValue() 方法的返回结果，换句话说，这里面的操作不是线程安全的。

解决办法

我们至少有两种简单的解决方案：

要么把getter 和 setter方法都定义为 synchronized方法，这样就可以套用管程锁定规则；
要么把value定义为 volatile变量，由于setter方法对value的修改不依赖于 value的原值，满足volatile关键字使用场景，这样就可以套用volatile变量规则来实现先行发生关系；

结论

一个操作 “时间上的先发生” 不代表这个操作会是“先行发生”。那如果一个操作“先行发生”是否就能推导出这个操作必定是 “时间上的先行发生”呢？

此推理时不成立的。一个典型的例子就是多次提到的“指令重排序”，代码如下：

// 以下操作在同一个线程中执行  
int i = 1;  
int j = 2;  
 
 1
2
3

代码分析

根据程序次序规则， int i = 1 的操作先行发生于 int j =2，但 int j = 2 完全可能先被处理器执行，这并不影响先行发生原则的正确性。

（5）最终结论

时间先后顺序与先行发生原则之间基本没有太大的关系，所以我们衡量并发安全问题的时候不要受到时间顺序的干扰，一切必须以先行发生原则为准。

四. 总结

“高效并发”部分概括

“并发”一直是Java语言中考察的重点，更是JVM学习中不可或缺的一部分，此部分主要从底层的角度讲解虚拟机是如何实现多线程、多线程之间由于共享和竞争数据而导致的一系列问题及解决方案。

此篇博文总结

此篇博文的第一大点主旨在于介绍硬件的结构、Java主内存和工作内存、内外存交互的操作，基本上是一些理论依据，主要讲解一些模型结构，也算是为后续内容打好基础。而第二大点着重结合理论与实践讲解了volatile、long、double 型变量的特殊规则，特别是volatile变量，在后续第三大点中的三大特性讲解中都有涉及到，算是一个“万能”并发控制，还有最后的先行并发原则，切勿混淆“时间先后顺序”与“先行发生原则”的关系。

博主的tips

在此特别提个醒，面试Java时总会提问到volatile 的相关问题，以往我都是往Java语言的角度去思考，如今可以试着从JVM底层来理解volatile 型变量的相关使用、特点与原理，这要是仔细捋明白了，还不得把面试官给怔住？所以说，高手过招，比的是内功心法，这些东西还是必不可少~