上星期因为一些起因没有持续写并发编程的内容，这个星期还是持续写并发编程，对于汇合类后续也会持续写，临时先写并发类，一块一块的来。
一、 内存模型
计算机在执行程序的时候，每一条指令都是由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...