共计 10100 个字符，预计需要花费 26 分钟才能阅读完成。
上星期因为一些起因没有持续写并发编程的内容，这个星期还是持续写并发编程，对于汇合类后续也会持续写，临时先写并发类，一块一块的来。
一、内存模型
计算机在执行程序的时候，每一条指令都是由 cpu 实现的，执行指令的过程中势必会呈现对数据的操作，长期数据都寄存在主内存中 (内存条)。然而这么做存在一个问题，cpu 的运算速度很快，相较于从内存中读取数据来说，那是快很多的，如果每执行一次指令都要从内存中读取下一条指令，那么会拖慢 cpu 的速度，针对这个问题，当初的 cpu 都内置了高速缓存(关上工作管理器，在性能选项中查看 cpu 的信息，能够看到 cpu 的 L1-L3 缓存信息)。
也就是说程序运行的时候并不是读取一条指令条执行一条指令，而是将须要的数据一次性缓存到 cpu 的高速缓存中，运算实现之后一次性把数据刷新到主内存里，举个简略的例子。例如上面的代码：
i = i+1；
线程执行这个语句时会从主内存读取 i 的值，复制一份到高速缓存里，而后 cpu 执行指令对 i 进行加 1 操作，最初将数据写入到高速缓存，再从高速缓存刷新到主内存。这个代码在单线程的状况下是没有任何问题的，然而多线程运行的时候就有问题了。在多核的 cpu 中，每个线程可能运行在不同的外围外面，假如有两个线程执行这行代码，咱们料想的后果是 i =2，但事实上很可能不是这样，可能会存在上面的状况：初始的时候两个线程别离读取 i 的值存入各自所在的 CPU 的高速缓存当中，而后线程 1 进行加 1 操作，而后把 i 的最新值 1 写入到内存。此时线程 2 的高速缓存当中 i 的值还是 0，进行加 1 操作之后，i 的值为 1，而后线程 2 把 i 的值写入内存。
最终后果 i 的值是 1，而不是 2。这就是驰名的缓存一致性问题。通常称这种被多个线程拜访的变量为共享变量。
也就是说如果一个变量在多个 cpu 中都有缓存，那么就可能会呈现缓存不统一的问题。
为了解决缓存不一致性问题，通常来说有以下 2 种解决办法：
1）通过在总线加 LOCK# 锁的形式
2）通过缓存一致性协定
这 2 种形式都是硬件层面上提供的形式。
在晚期的 CPU 当中，是通过在总线上加 LOCK#锁的模式来解决缓存不统一的问题。因为 CPU 和其余部件进行通信都是通过总线来进行的，如果对总线加 LOCK# 锁的话，也就是说阻塞了其余 CPU 对其余部件拜访（如内存），从而使得只能有一个 CPU 能应用这个变量的内存。比方下面例子中 如果一个线程在执行 i = i +1，如果在执行这段代码的过程中，在总线上收回了 LCOK# 锁的信号，那么只有期待这段代码齐全执行结束之后，其余 CPU 能力从变量 i 所在的内存读取变量，而后进行相应的操作。这样就解决了缓存不统一的问题。
然而下面的形式会有一个问题，因为在锁住总线期间，其余 CPU 无法访问内存，导致效率低下。
所以就呈现了缓存一致性协定。最闻名的就是 Intel 的 MESI 协定，MESI 协定保障了每个缓存中应用的共享变量的正本是统一的。它外围的思维是：当 CPU 写数据时，如果发现操作的变量是共享变量，即在其余 CPU 中也存在该变量的正本，会发出信号告诉其余 CPU 将该变量的缓存行置为有效状态，因而当其余 CPU 须要读取这个变量时，发现自己缓存中缓存该变量的缓存行是有效的，那么它就会从内存从新读取。
图片来源于网络
二、并发编程中的三个概念
并发编程中常会遇见三个问题：原子性问题，可见性问题，有序性问题。先不焦急说这三个问题，先弄清楚这三个概念。
- 原子性
原子性指的是将一个操作或者多个操作看做一个整体，要么就全副执行，要么就一个都不执行，不会被任何因素打断。一个很经典的例子就是银行账户转账问题。
如从账户 A 向账户 B 转 1000 元，那么必然包含 2 个操作：从账户 A 减去 1000 元，往账户 B 加上 1000 元。试想一下，如果这 2 个操作不具备原子性，会造成什么样的结果。如果从账户 A 减去 1000 元之后，操作忽然停止。而后又从 B 取出了 500 元，取出 500 元之后，再执行 往账户 B 加上 1000 元 的操作。这样就会导致账户 A 尽管减去了 1000 元，然而账户 B 没有收到这个转过来的 1000 元。以这 2 个操作必须要具备原子性能力保障不呈现一些意外的问题。
同样反映到并发编程中会呈现什么后果呢？
举个简略的例子，假如为一个 32 位的变量赋值过程不具备原子性的话可能会呈现什么问题。
i = 100;
若一个线程执行到这个语句，那么会有两个过程，为低 16 位赋值和高 16 位赋值，失常的 100 应该是 00000000000000000000000001100100，若一个线程为高 16 位赋之后被打断了，当初另外一个线程来读取这个数值，那么后果天然是 0，因为低 16 位还没来得及赋值就被打断了，所以你的 100 块变成了 0 块，又要去找银行扯皮，然而家喻户晓银行是老弱势群体了，咱们不得不了解他们，后果很可能是你平白无故少了 100。抖个伶俐，这就是原子性带来的问题了。
- 可见性
可见性是指多个线程拜访同一个变量时，一个线程批改了这个变量的值，其余线程可能立刻看到这个批改的值，举个简略的例子，看上面的代码：
// 线程一执行的代码
Int i= 0；
i= 10；
// 线程二执行的代码
j= i；
假若执行线程一的是 cpu1，执行线程二的是 cpu2. 由下面的剖析能够晓得，当线程一执行了 i = 10 这句话时，会先把 i 的初始值加载到 CPU1 的高速缓存中，而后赋值为 10，那么在 CPU1 的高速缓存当中 i 的值变为 10 了，却没有立刻写入到主存当中。
此时线程 2 执行 j = i，它会先去主存读取 i 的值并加载到 CPU2 的缓存当中，留神此时内存当中 i 的值还是 0，那么就会使得 j 的值为 0，而不是 10。
这就是可见性问题，线程 1 对变量 i 批改了之后，线程 2 没有立刻看到线程 1 批改的值。 - 有序性
有序性：即程序执行的程序依照代码的先后顺序执行。举个简略的例子，看上面的代码：
int i= 0；
boolean flag = false；
i= 1；
flag = true；
下面代码定义了一个 int 型变量，定义了一个 boolean 类型变量，而后别离对两个变量进行赋值操作。从代码程序上看，语句 1 是在语句 2 后面的，那么 JVM 在真正执行这段代码的时候会保障语句 1 肯定会在语句 2 后面执行吗？不肯定，为什么呢？这里可能会产生指令重排序（Instruction Reorder）。
上面解释一下什么是指令重排序，一般来说，处理器为了进步程序运行效率，可能会对输出代码进行优化，它不保障程序中各个语句的执行先后顺序同代码中的程序统一，然而它会保障程序最终执行后果和代码程序执行的后果是统一的。
比方下面的代码中，语句 1 和语句 2 谁先执行对最终的程序后果并没有影响，那么就有可能在执行过程中，语句 2 先执行而语句 1 后执行。
然而要留神，尽管处理器会对指令进行重排序，然而它会保障程序最终后果会和代码程序执行后果雷同，那么它靠什么保障的呢？再看上面一个例子：
int a = 10; // 语句 1
int r = 2; // 语句 2
a = a + 3; // 语句 3
r = a*a; // 语句 4
这段代码有四个语句，那么可能的一个执行程序是语句 2 -> 语句 1 -> 语句 3 -> 语句 4，那么有可能是语句 2 -> 语句 1 -> 语句 4 -> 语句 3 吗？很显然不可能，因为指令重排序不能影响数据之间的依赖性，如果指令 2 必须用到指令 1 的后果，那么指令 1 肯定会在指令 2 之前执行。尽管重排序不影响单个线程的后果，那么多线程呢
// 线程 1:
context = loadContext(); // 语句 1
inited = true; // 语句 2
// 线程 2:
while(!inited){
sleep()；
}
doSomethingwithconfig(context);
下面的代码中因为语句 1 和语句 2 没有数据依赖性，因而可能会被重排序。如果产生了重排序，在线程 1 执行过程中先执行语句 2，而此是线程 2 会认为初始化工作曾经实现，那么就会跳出 while 循环，去执行 doSomethingwithconfig(context)办法，而此时 context 并没有被初始化，就会导致程序出错。
从下面能够看出，指令重排序不会影响单个线程的执行，然而会影响到线程并发执行的正确性。
也就是说，要想并发程序正确地执行，必须要保障原子性、可见性以及有序性。只有有一个没有被保障，就有可能会导致程序运行不正确。
三、Java 的内存模型
在后面谈到了一些对于内存模型以及并发编程中可能会呈现的一些问题。上面咱们来看一下 Java 内存模型，钻研一下 Java 内存模型为咱们提供了哪些保障以及在 java 中提供了哪些办法和机制来让咱们在进行多线程编程时可能保障程序执行的正确性。
在 Java 虚拟机标准中试图定义一种 Java 内存模型（Java Memory Model，JMM）来屏蔽各个硬件平台和操作系统的内存拜访差别，以实现让 Java 程序在各种平台下都能达到统一的内存拜访成果。那么 Java 内存模型规定了哪些货色呢，它定义了程序中变量的拜访规定，往大一点说是定义了程序执行的秩序。留神，为了取得较好的执行性能，Java 内存模型并没有限度执行引擎应用处理器的寄存器或者高速缓存来晋升指令执行速度，也没有限度编译器对指令进行重排序。也就是说，在 java 内存模型中，也会存在缓存一致性问题和指令重排序的问题。
Java 内存模型规定所有的变量都是存在主存当中（相似于后面说的物理内存），每个线程都有本人的工作内存（相似于后面的高速缓存）。线程对变量的所有操作都必须在工作内存中进行，而不能间接对主存进行操作。并且每个线程不能拜访其余线程的工作内存。
举个简略的例子：在 java 中，执行上面这个语句：
i = 10;
执行线程必须先在本人的工作线程中对变量 i 所在的缓存行进行赋值操作，而后再写入主存当中。而不是间接将数值 10 写入主存当中。
那么 Java 语言 自身对 原子性、可见性以及有序性提供了哪些保障呢？
- 原子性
在 Java 中，对根本数据类型的变量的读取和赋值操作是原子性操作，即这些操作是不可被中断的，要么执行，要么不执行。
下面一句话尽管看起来简略，然而了解起来并不是那么容易。看上面一个例子 i：
请剖析以下哪些操作是原子性操作：
x = 10; // 语句 1
y = x; // 语句 2
x++; // 语句 3
x = x + 1; // 语句 4
乍一看，有些敌人可能会说下面的 4 个语句中的操作都是原子性操作。其实只有语句 1 是原子性操作，其余三个语句都不是原子性操作。
语句 1 是间接将数值 10 赋值给 x，也就是说线程执行这个语句的会间接将数值 10 写入到工作内存中。
语句 2 实际上蕴含 2 个操作，它先要去读取 x 的值，再将 x 的值写入工作内存，尽管读取 x 的值以及 将 x 的值写入工作内存 这 2 个操作都是原子性操作，然而合起来就不是原子性操作了。
同样的，x++ 和 x = x+ 1 包含 3 个操作：读取 x 的值，进行加 1 操作，写入新的值。
所以下面 4 个语句只有语句 1 的操作具备原子性。
也就是说，只有简略的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的互相赋值不是原子操作）才是原子操作。
不过这里有一点须要留神：在 32 位平台下，对 64 位数据的读取和赋值是须要通过两个操作来实现的，不能保障其原子性。然而如同在最新的 JDK 中，JVM 曾经保障对 64 位数据的读取和赋值也是原子性操作了。
从下面能够看出，Java 内存模型只保障了根本读取和赋值是原子性操作，如果要实现更大范畴操作的原子性，能够通过 synchronized 和 Lock 来实现。因为 synchronized 和 Lock 可能保障任一时刻只有一个线程执行该代码块，那么天然就不存在原子性问题了，从而保障了原子性。
- 可见性
对于可见性，Java 提供了 volatile 关键字来保障可见性。
当一个共享变量被 volatile 润饰时，它会保障批改的值会立刻被更新到主存，当有其余线程须要读取时，它会去内存中读取新值。
而一般的共享变量不能保障可见性，因为一般共享变量被批改之后，什么时候被写入主存是不确定的，当其余线程去读取时，此时内存中可能还是原来的旧值，因而无奈保障可见性。
另外，通过 synchronized 和 Lock 也可能保障可见性，synchronized 和 Lock 能保障同一时刻只有一个线程获取锁而后执行同步代码，并且在开释锁之前会将对变量的批改刷新到主存当中。因而能够保障可见性。 - 有序性
在 Java 内存模型中，容许编译器和处理器对指令进行重排序，然而重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。
在 Java 外面，能够通过 volatile 关键字来保障肯定的“有序性”（具体原理在下一节讲述）。另外能够通过 synchronized 和 Lock 来保障有序性，很显然，synchronized 和 Lock 保障每个时刻是有一个线程执行同步代码，相当于是让线程程序执行同步代码，天然就保障了有序性。
另外，Java 内存模型具备一些先天的“有序性”，即不须要通过任何伎俩就可能失去保障的有序性，这个通常也称为 happens-before 准则。如果两个操作的执行秩序无奈从 happens-before 准则推导进去，那么它们就不能保障它们的有序性，虚拟机能够随便地对它们进行重排序。
上面就来具体介绍下 happens-before 准则（后行产生准则）：
程序秩序规定：一个线程内，依照代码程序，书写在后面的操作后行产生于书写在前面的操作
锁定规定：一个 unLock 操作后行产生于前面对同一个锁额 lock 操作
volatile 变量规定：对一个变量的写操作后行产生于前面对这个变量的读操作
传递规定：如果操作 A 后行产生于操作 B，而操作 B 又后行产生于操作 C，则能够得出操作 A 后行产生于操作 C
线程启动规定：Thread 对象的 start()办法后行产生于此线程的每个一个动作
线程中断规定：对线程 interrupt()办法的调用后行产生于被中断线程的代码检测到中断事件的产生
线程终结规定：线程中所有的操作都后行产生于线程的终止检测，咱们能够通过 Thread.join()办法完结、Thread.isAlive()的返回值伎俩检测到线程曾经终止执行
对象终结规定：一个对象的初始化实现后行产生于他的 finalize()办法的开始
这 8 条准则摘自《深刻了解 Java 虚拟机》。
这 8 条规定中，前 4 条规定是比拟重要的，后 4 条规定都是不言而喻的。
上面咱们来解释一下前 4 条规定：
对于程序秩序规定来说，我的了解就是一段程序代码的执行在单个线程中看起来是有序的。留神，尽管这条规定中提到“书写在后面的操作后行产生于书写在前面的操作”，这个应该是程序看起来执行的程序是依照代码程序执行的，因为虚拟机可能会对程序代码进行指令重排序。尽管进行重排序，然而最终执行的后果是与程序程序执行的后果统一的，它只会对不存在数据依赖性的指令进行重排序。因而，在单个线程中，程序执行看起来是有序执行的，这一点要留神了解。事实上，这个规定是用来保障程序在单线程中执行后果的正确性，但无奈保障程序在多线程中执行的正确性。
第二条规定也比拟容易了解，也就是说无论在单线程中还是多线程中，同一个锁如果出于被锁定的状态，那么必须先对锁进行了开释操作，前面能力持续进行 lock 操作。
第三条规定是一条比拟重要的规定，也是后文将要重点讲述的内容。直观地解释就是，如果一个线程先去写一个变量，而后一个线程去进行读取，那么写入操作必定会后行产生于读操作。
第四条规定实际上就是体现 happens-before 准则具备传递性。
四、volatile 关键字
其实后面说了这么多都是为了讲述 volatile 关键字做铺垫，既然铺垫完了，那么就能够进入主题了。
- volatile 关键字的语义
一旦一个共享变量（类的成员变量、类的动态成员变量）被 volatile 润饰之后，那么就具备了两层语义：
1）保障了不同线程对这个变量进行操作时的可见性，即一个线程批改了某个变量的值，这新值对其余线程来说是立刻可见的。
2）禁止进行指令重排序。
先看一段代码，如果线程 1 先执行，线程 2 后执行：
// 线程 1
boolean stop = false;
while(!stop){
doSomething();}
// 线程 2
stop = true;
这段代码是很典型的一段代码，很多人在中断线程时可能都会采纳这种标记方法。然而事实上，这段代码会齐全运行正确么？即肯定会将线程中断么？不肯定，兴许在大多数时候，这个代码可能把线程中断，然而也有可能会导致无奈中断线程（尽管这个可能性很小，然而只有一旦产生这种状况就会造成死循环了）。
上面解释一下这段代码为何有可能导致无奈中断线程。在后面曾经解释过，每个线程在运行过程中都有本人的工作内存，那么线程 1 在运行的时候，会将 stop 变量的值拷贝一份放在本人的工作内存当中。
那么当线程 2 更改了 stop 变量的值之后，然而还没来得及写入主存当中，线程 2 转去做其余事件了，那么线程 1 因为不晓得线程 2 对 stop 变量的更改，因而还会始终循环上来。
然而用 volatile 润饰之后就变得不一样了：
第一：应用 volatile 关键字会强制将批改的值立刻写入主存；
第二：应用 volatile 关键字的话，当线程 2 进行批改时，会导致线程 1 的工作内存中缓存变量 stop 的缓存行有效（反映到硬件层的话，就是 CPU 的 L1 或者 L2 缓存中对应的缓存行有效）；
第三：因为线程 1 的工作内存中缓存变量 stop 的缓存行有效，所以线程 1 再次读取变量 stop 的值时会去主存读取。
那么在线程 2 批改 stop 值时（当然这里包含 2 个操作，批改线程 2 工作内存中的值，而后将批改后的值写入内存），会使得线程 1 的工作内存中缓存变量 stop 的缓存行有效，而后线程 1 读取时，发现自己的缓存行有效，它会期待缓存行对应的主存地址被更新之后，而后去对应的主存读取最新的值。
那么线程 1 读取到的就是最新的正确的值。
2.volatile 关键字无奈保障原子性
看一个例子
public class Test {
public volatile int inc = 0;
public void increase() {inc++;}
public static void main(String[] args) {final Test test = new Test();
for(int i=0;i<10;i++){new Thread(){public void run() {for(int j=0;j<1000;j++)
test.increase();};
}.start();}
while(Thread.activeCount()>1) // 保障后面的线程都执行完
Thread.yield();
System.out.println(test.inc);
}}
大家想一下这段程序的输入后果是多少？兴许有些敌人认为是 10000。然而事实上运行它会发现每次运行后果都不统一，都是一个小于 10000 的数字。
可能有的敌人就会有疑难，不对啊，下面是对变量 inc 进行自增操作，因为 volatile 保障了可见性，那么在每个线程中对 inc 自增完之后，在其余线程中都能看到批改后的值啊，所以有 10 个线程别离进行了 1000 次操作，那么最终 inc 的值应该是 1000*10=10000。
这外面就有一个误区了，volatile 关键字能保障可见性没有错，然而下面的程序错在没能保障原子性。可见性只能保障每次读取的是最新的值，然而 volatile 没方法保障对变量的操作的原子性。
在后面曾经提到过，自增操作是不具备原子性的，它包含读取变量的原始值、进行加 1 操作、写入工作内存。那么就是说自增操作的三个子操作可能会宰割开执行，就有可能导致上面这种状况呈现：
如果某个时刻变量 inc 的值为 10，
线程 1 对变量进行自增操作，线程 1 先读取了变量 inc 的原始值，而后线程 1 被阻塞了；
而后线程 2 对变量进行自增操作，线程 2 也去读取变量 inc 的原始值，因为线程 1 只是对变量 inc 进行读取操作，而没有对变量进行批改操作，所以不会导致线程 2 的工作内存中缓存变量 inc 的缓存行有效，所以线程 2 会间接去主存读取 inc 的值，发现 inc 的值时 10，而后进行加 1 操作，并把 11 写入工作内存，最初写入主存。
而后线程 1 接着进行加 1 操作，因为曾经读取了 inc 的值，留神此时在线程 1 的工作内存中 inc 的值依然为 10，所以线程 1 对 inc 进行加 1 操作后 inc 的值为 11，而后将 11 写入工作内存，最初写入主存。
那么两个线程别离进行了一次自增操作后，inc 只减少了 1。
解释到这里，可能有敌人会有疑难，不对啊，后面不是保障一个变量在批改 volatile 变量时，会让缓存行有效吗？而后其余线程去读就会读到新的值，对，这个没错。这个就是下面的 happens-before 规定中的 volatile 变量规定，然而要留神，线程 1 对变量进行读取操作之后，被阻塞了的话，并没有对 inc 值进行批改。而后尽管 volatile 能保障线程 2 对变量 inc 的值读取是从内存中读取的，然而线程 1 没有进行批改，所以线程 2 基本就不会看到批改的值。
本源就在这里，自增操作不是原子性操作，而且 volatile 也无奈保障对变量的任何操作都是原子性的。
3.volatile 能保障有序性吗？
在后面提到 volatile 关键字能禁止指令重排序，所以 volatile 能在肯定水平上保障有序性。
volatile 关键字禁止指令重排序有两层意思：
1）当程序执行到 volatile 变量的读操作或者写操作时，在其后面的操作的更改必定全副曾经进行，且后果曾经对前面的操作可见；在其前面的操作必定还没有进行；
2）在进行指令优化时，不能将在对 volatile 变量拜访的语句放在其前面执行，也不能把 volatile 变量前面的语句放到其后面执行。
可能下面说的比拟绕，举个简略的例子：
//x、y 为非 volatile 变量
//flag 为 volatile 变量
x = 2; // 语句 1
y = 0; // 语句 2
flag = true; // 语句 3
x = 4; // 语句 4
y = -1; // 语句 5
因为 flag 变量为 volatile 变量，那么在进行指令重排序的过程的时候，不会将语句 3 放到语句 1、语句 2 后面，也不会讲语句 3 放到语句 4、语句 5 前面。然而要留神语句 1 和语句 2 的程序、语句 4 和语句 5 的程序是不作任何保障的。
并且 volatile 关键字能保障，执行到语句 3 时，语句 1 和语句 2 必然是执行结束了的，且语句 1 和语句 2 的执行后果对语句 3、语句 4、语句 5 是可见的。
那么回到后面的一个例子：
// 线程 1:
context = loadContext(); // 语句 1
inited = true; // 语句 2
// 线程 2:
while(!inited){
sleep()
}
doSomethingwithconfig(context);
后面举这个例子的时候，提到有可能语句 2 会在语句 1 之前执行，那么久可能导致 context 还没被初始化，而线程 2 中就应用未初始化的 context 去进行操作，导致程序出错。
这里如果用 volatile 关键字对 inited 变量进行润饰，就不会呈现这种问题了，因为当执行到语句 2 时，必然能保障 context 曾经初始化结束。
- volatile 的原理和实现机制
后面讲述了源于 volatile 关键字的一些应用，上面咱们来探讨一下 volatile 到底如何保障可见性和禁止指令重排序的。
上面这段话摘自《深刻了解 Java 虚拟机》：
“察看退出 volatile 关键字和没有退出 volatile 关键字时所生成的汇编代码发现，退出 volatile 关键字时，会多出一个 lock 前缀指令”
lock 前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供 3 个性能：
1）它确保指令重排序时不会把其前面的指令排到内存屏障之前的地位，也不会把后面的指令排到内存屏障的前面；即在执行到内存屏障这句指令时，在它后面的操作曾经全副实现；
2）它会强制将对缓存的批改操作立刻写入主存；
3）如果是写操作，它会导致其余 CPU 中对应的缓存行有效。
五、volatile 的一个例子
这边我写了一个单例模式的例子供大家参考，也是单例模式的罕用写法：
最初的总结：
synchronized 关键字是避免多个线程同时执行一段代码，那么就会很影响程序执行效率，而 volatile 关键字在某些状况下性能要优于 synchronized，然而要留神 volatile 关键字是无奈代替 synchronized 关键字的，因为 volatile 关键字无奈保障操作的原子性。通常来说，应用 volatile 必须具备以下 2 个条件：
1）对变量的写操作不依赖于以后值
2）该变量没有蕴含在具备其余变量的不变式中
实际上，这些条件表明，能够被写入 volatile 变量的这些有效值独立于任何程序的状态，包含变量的以后状态。
事实上，我的了解就是下面的 2 个条件须要保障操作是原子性操作，能力保障应用 volatile 关键字的程序在并发时可能正确执行。
参考博客：https://www.cnblogs.com/dolph…