volatile什么时候锁缓存行

1. 总线锁、缓存锁

操作系统必须要有一些机制和原语，以保证某些基本操作的原子性的两种机制：
1.总线锁定
2.缓存一致性

总线锁定：
现在的CPU一般都有自己的内部缓存，根据一些规则将内存中的数据读取到内部缓存中来，以加快频繁读取的速度。现在服务器通常是多 CPU，更普遍的是，每块CPU里有多个内核，而每个内核都维护了自己的缓存，那么这时候多线程并发就会存在缓存不一致性，这会导致严重问题。

操作系统提供了总线锁定的机制。前端总线(也叫CPU总线)是所有CPU与芯片组连接的主干道，负责CPU与外界所有部件的通信，包括高速缓存、内存、北桥，其控制总线向各个部件发送控制信号、通过地址总线发送地址信号指定其要访问的部件、通过数据总线双向传输。在CPU1要操作共享变量的时候，其在总线上发出一个LOCK#信号，其他处理器就不能操作缓存了该共享变量内存地址的缓存，也就是阻塞了其他CPU，使该处理器可以独享此共享内存。
总线锁定把CPU和内存的通信给锁住了，使得在锁定期间，其他处理器不能操作其他内存地址的数据，从而开销较大。

缓存一致性：
与volatile的原理一致，也是通过拷贝，侦测共享变量的值，当发现共享变量改变时，重新读取。

2. volatile在i++情况下失效，volatile不是原子的

如果你对volatile不陌生的话，应该会知道volatile能够保证共享变量对线程的可见性。
那为什么volatile无法保证 i++ 操作的线程可见性呢？

假设i的初始值为0，现有两个线程，分别为线程1和线程2进行 i++ 操作，我们来分析一下为什么会出现错误。
首先，i++并不是原子操作，我们可以将这个操作拆分为3个步骤。
1、线程从主内存把遍历加载到缓存。
2、线程执行i++操作。
3、线程将i的新值刷新到主内存。

那么进行如下过程，则会发生线程安全问题。
1、线程1将变量加载到缓存。但是还没有执行 i++ 操作。
2、线程2将变量加载到缓存，然后执行i++操作。
3、由于线程2缓存变量已经发生了变化，使得线程1的缓存行无效。
4、按我们以前的理解，由于线程1缓存行无效，那线程1应该主动去主内存load最新的值。而实际上并不是这样的，volatile的作用并不是在变量改变的时候，让其他线程重新加载主内存的变量值，而是置其他线程缓存内的变量值无效。也就是说，假如线程1的i值已经被加载到了寄存器，参与i++运算，那么此时即便线程1的i值被置为无效，那线程1的计算结果也会把线程1从主内存刷新到的缓存值覆盖，导致数据错误。

那么为了解决volatile++这类复合操作的原子性，有什么方案呢？其实方案也比较多的，这里提供两种典型的：
1、使用synchronized关键字
2、使用AtomicInteger/AtomicLong原子类型

synchronized是比较原始的同步手段。它本质上是一个独占的，可重入的锁。当一个线程尝试获取它的时候，可能会被阻塞住，所以高并发的场景下性能存在一些问题。

在某些场景下，使用synchronized关键字和volatile是等价的：
1、写入变量值时候不依赖变量的当前值，或者能够保证只有一个线程修改变量值。
2、写入的变量值不依赖其他变量的参与。
3、读取变量值时候不能因为其他原因进行加锁。
加锁可以同时保证可见性和原子性，而volatile只保证变量值的可见性。

这类原子类型比锁更加轻巧，比如AtomicInteger/AtomicLong分别就代表了整型变量和长整型变量。
在它们的实现中，实际上分别使用的volatile int/volatile long保存了真正的值。因此，也是通过volatile来保证对于单个变量的读写原子性的。
在此基础之上，它们提供了原子性的自增自减操作。比如incrementAndGet方法， 这类方法相对于synchronized的好处是：它们不会导致线程的挂起和重新调度，因为在其内部使用的是CAS非阻塞算法。

所谓的CAS全程为CompareAndSet。直译过来就是比较并设置。这个操作需要接受三个参数：
1、内存位置
2、旧的预期值
3、新值
这个操作的做法就是看指定内存位置的值符不符合旧的预期值，如果符合的话就将它替换成新值。它对应的是处理器提供的一个原子性指令 - CMPXCHG。
比如AtomicLong的自增操作：

我们考虑两个线程T1和T2，同时执行到了上述Step 1处，都拿到了current值为1。然后通过Step 2之后，current在两个线程中都被设置为2。

紧接着，来到Step 3。假设线程T1先执行，此时符合CompareAndSet的设置规则，因此内存位置对应的值被设置成2，线程T1设置成功。当线程T2执行的时候，由于它预期current为1，但是实际上已经变成了2，所以CompareAndSet执行不成功，进入到下一轮的for循环中，此时拿到最新的current值为2，如果没有其它线程感染的话，再次执行CompareAndSet的时候就能够通过，current值被更新为3。
所以不难发现，CAS的工作主要依赖于两点：
1、无限循环，需要消耗部分CPU性能
2、CPU原子指令CompareAndSet
虽然它需要耗费一定的CPU Cycle，但是相比锁而言还是有其优势，比如它能够避免线程阻塞引起的上下文切换和调度。这两类操作的量级明显是不一样的，CAS更轻量一些。

我们说对于volatile变量的读/写操作是原子性的。因为从内存屏障的角度来看，对volatile变量的单纯读写操作确实没有任何疑问。
由于其中掺杂了一个自增的CPU内部操作，就造成这个复合操作不再保有原子性。
然后，讨论了如何保证volatile++这类操作的原子性，比如使用synchronized或者AtomicInteger/AtomicLong原子类。

3. 看了这篇文章，你还敢说你了解volatile关键字吗

想要理解volatile为什么能确保可见性，就要先理解java中的内存模型是什么样的。

Java内存模型规定了 所有的变量都存储在主内存中 。 每条线程中还有自己的工作内存，线程的工作内存中保存了被该线程所使用到的变量（这些变量是从主内存中拷贝而来） 。 线程对变量的所有操作（读取，赋值）都必须在工作内存中进行。不同线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成 。

基于此种内存模型，便产生了多线程编程中的数据“脏读”等问题。

举个简单的例子：在java中，执行下面这个语句：

i = 10;

执行线程必须先在自己的工作线程中对变量i所在的缓存行进行赋值操作，然后再写入主存当中。而不是直接将数值10写入主存当中。

比如同时有2个线程执行这段代码，假如初始时i的值为10，那么我们希望两个线程执行完之后i的值变为12。但是事实会是这样吗？

可能存在下面一种情况：初始时，两个线程分别读取i的值存入各自所在的工作内存当中，然后线程1进行加1操作，然后把i的最新值11写入到内存。此时线程2的工作内存当中i的值还是10，进行加1操作之后，i的值为11，然后线程2把i的值写入内存。

最终结果i的值是11，而不是12。这就是着名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。

那么如何确保共享变量在多线程访问时能够正确输出结果呢？

在解决这个问题之前，我们要先了解并发编程的三大概念： 原子性，有序性，可见性 。

1.定义

原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

2.实例

一个很经典的例子就是银行账户转账问题：

比如从账户A向账户B转1000元，那么必然包括2个操作：从账户A减去1000元，往账户B加上1000元。

试想一下，如果这2个操作不具备原子性，会造成什么样的后果。假如从账户A减去1000元之后，操作突然中止。这样就会导致账户A虽然减去了1000元，但是账户B没有收到这个转过来的1000元。

所以这2个操作必须要具备原子性才能保证不出现一些意外的问题。

同样地反映到并发编程中会出现什么结果呢？

举个最简单的例子，大家想一下假如为一个32位的变量赋值过程不具备原子性的话，会发生什么后果？

假若一个线程执行到这个语句时，我暂且假设为一个32位的变量赋值包括两个过程：为低16位赋值，为高16位赋值。

那么就可能发生一种情况：当将低16位数值写入之后，突然被中断，而此时又有一个线程去读取i的值，那么读取到的就是错误的数据。

3.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的操作具备原子性。

也就是说， 只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。

从上面可以看出，Java内存模型只保证了基本读取和赋值是原子性操作， 如果要实现更大范围操作的原子性，可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

1.定义

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

2.实例

举个简单的例子，看下面这段代码：

//线程1执行的代码

int i = 0;

i = 10;

//线程2执行的代码

j = i;

由上面的分析可知，当线程1执行 i =10这句时，会先把i的初始值加载到工作内存中，然后赋值为10，那么在线程1的工作内存当中i的值变为10了，却没有立即写入到主存当中。

此时线程2执行 j = i，它会先去主存读取i的值并加载到线程2的工作内存当中，注意此时内存当中i的值还是0，那么就会使得j的值为0，而不是10.

这就是可见性问题，线程1对变量i修改了之后，线程2没有立即看到线程1修改的值。

3.Java中的可见性

对于可见性，Java提供了volatile关键字来保证可见性。

当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。

而普通的共享变量不能保证可见性， 因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。

另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且 在释放锁之前会将对变量的修改刷新到主存当中 。因此可以保证可见性。

1.定义

有序性：即程序执行的顺序按照代码的先后顺序执行。

2.实例

举个简单的例子，看下面这段代码：

int i = 0;

boolean flag = false;

i = 1; //语句1

flag = true; //语句2

上面代码定义了一个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

这段代码有4个语句，那么可能的一个执行顺序是：

那么可不可能是这个执行顺序呢： 语句2 语句1 语句4 语句3

不可能，因为处理器在进行重排序时是会考虑指令之间的数据依赖性，如果一个指令Instruction 2必须用到Instruction 1的结果，那么处理器会保证Instruction 1会在Instruction 2之前执行。

虽然重排序不会影响单个线程内程序执行的结果，但是多线程呢？下面看一个例子：

上面代码中，由于语句1和语句2没有数据依赖性，因此可能会被重排序。假如发生了重排序，在线程1执行过程中先执行语句2，而此是线程2会以为初始化工作已经完成，那么就会跳出while循环，去执行doSomethingwithconfig(context)方法，而此时context并没有被初始化，就会导致程序出错。

从上面可以看出， 指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。

也就是说， 要想并发程序正确地执行，必须要保证原子性、可见性以及有序性。只要有一个没有被保证，就有可能会导致程序运行不正确。

3.Java中的有序性

在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条规则中，前4条规则是比较重要的，后4条规则都是显而易见的。

下面我们来解释一下前4条规则：

对于程序次序规则来说，就是一段程序代码的执行 在单个线程中看起来是有序的 。注意，虽然这条规则中提到“书写在前面的操作先行发生于书写在后面的操作”，这个应该是程序看起来执行的顺序是按照代码顺序执行的， 但是虚拟机可能会对程序代码进行指令重排序 。虽然进行重排序，但是最终执行的结果是与程序顺序执行的结果一致的，它只会对不存在数据依赖性的指令进行重排序。因此， 在单个线程中，程序执行看起来是有序执行的 ，这一点要注意理解。事实上， 这个规则是用来保证程序在单线程中执行结果的正确性，但无法保证程序在多线程中执行的正确性。

第二条规则也比较容易理解，也就是说无论在单线程中还是多线程中， 同一个锁如果处于被锁定的状态，那么必须先对锁进行了释放操作，后面才能继续进行lock操作。

第三条规则是一条比较重要的规则。直观地解释就是， 如果一个线程先去写一个变量，然后一个线程去进行读取，那么写入操作肯定会先行发生于读操作。

第四条规则实际上就是体现happens-before原则 具备传递性 。

1.volatile保证可见性

一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：

1）保证了 不同线程对这个变量进行操作时的可见性 ，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。

2） 禁止进行指令重排序。

先看一段代码，假如线程1先执行，线程2后执行：

这段代码是很典型的一段代码，很多人在中断线程时可能都会采用这种标记办法。但是事实上，这段代码会完全运行正确么？即一定会将线程中断么？不一定，也许在大多数时候，这个代码能够把线程中断，但是也有可能会导致无法中断线程（虽然这个可能性很小，但是只要一旦发生这种情况就会造成死循环了）。

下面解释一下这段代码为何有可能导致无法中断线程。在前面已经解释过，每个线程在运行过程中都有自己的工作内存，那么线程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不能确保原子性

下面看一个例子：

大家想一下这段程序的输出结果是多少？也许有些朋友认为是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也无法保证对变量的任何操作都是原子性的。

解决方案：可以通过synchronized或lock，进行加锁，来保证操作的原子性。也可以通过AtomicInteger。

在java 1.5的java.util.concurrent.atomic包下提供了一些 原子操作类 ，即对基本数据类型的 自增（加1操作），自减（减1操作）、以及加法操作（加一个数），减法操作（减一个数）进行了封装，保证这些操作是原子性操作。 atomic是利用CAS来实现原子性操作的（Compare And Swap） ，CAS实际上是 利用处理器提供的CMPXCHG指令实现的，而处理器执行CMPXCHG指令是一个原子性操作。

3.volatile保证有序性

在前面提到volatile关键字能禁止指令重排序，所以volatile能在一定程度上保证有序性。

volatile关键字禁止指令重排序有两层意思：

1）当程序执行到volatile变量的读操作或者写操作时， 在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行 ；

2）在进行指令优化时， 不能将在对volatile变量的读操作或者写操作的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

可能上面说的比较绕，举个简单的例子：

由于 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已经初始化完毕。

1.可见性

处理器为了提高处理速度，不直接和内存进行通讯，而是将系统内存的数据独到内部缓存后再进行操作，但操作完后不知什么时候会写到内存。

2.有序性

Lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），它确保 指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面； 即在执行到内存屏障这句指令时，在它前面的操作已经全部完成。

synchronized关键字是防止多个线程同时执行一段代码，那么就会很影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized，但是要注意volatile关键字是无法替代synchronized关键字的，因为volatile关键字无法保证操作的原子性。通常来说，使用volatile必须具备以下2个条件：

1）对变量的写操作不依赖于当前值

2）该变量没有包含在具有其他变量的不变式中

下面列举几个Java中使用volatile的几个场景。

①.状态标记量

volatile boolean flag = false;

//线程1

while(!flag){

doSomething();

}

//线程2

public void setFlag() {

flag = true;

}

根据状态标记，终止线程。

②.单例模式中的double check

为什么要使用volatile 修饰instance？

主要在于instance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情:

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。

自己是从事了七年开发的Android工程师，不少人私下问我，2019年Android进阶该怎么学，方法有没有？

没错，年初我花了一个多月的时间整理出来的学习资料，希望能帮助那些想进阶提升Android开发，却又不知道怎么进阶学习的朋友。【 包括高级UI、性能优化、架构师课程、NDK、Kotlin、混合式开发（ReactNative+Weex）、Flutter等架构技术资料 】，希望能帮助到您面试前的复习且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。

4. volitate 原理

volatile保证多线程可见性，volatile修饰的变量不会引起上下文切换和调度
cpu缓存，cpu运算速度与内存读写不匹配，因为cpu运算速度比内存读写快的多
从主内存中获取或者写入数据会花费很长时间，现在大多数cpu都不会直接访问内存，而是访问cpu缓存，cpu缓存是cpu与主内存之间的临时存储器，容量小，交换速度快，缓存中的数据是内存中的一小部分数据，是cpu即将访问的。当cpu调用大量数据时候，就先从缓存中读取从而加快读取速度
按照读取顺序与cpu结合的紧密程度，cpu缓存分为
一级缓存：L1位于cpu内核旁边，是与cpu结合最为紧密的cpu缓存
二级缓存：L2分为内部和外部两种芯片，内部芯片二级缓存运行速度与主频相同，外部芯片二级缓存运行速度则只有主频的一半
三级缓存，只有高端的cpu才有
每一级缓存中所存储的数据都是下一级缓存中存储的数据的一部分
cpu要读取一个数据的时候，首先从一级缓存中查找，如果没有就从二级中查找，如果还没有就从三级缓存中或者是内存总进行查找，一般来说，每级缓存的命中率大概有0.8左右，也就是全部数据量的0.8可以在一级缓存中查到，只有剩下的0.2总数据量从二级缓存中或者是三级缓存或者是内存中读取

缓存行：缓存是分line的，一个段对应一个缓存行，是cpu缓存种可分配的最小存储单元，通常是64字节：当cpu看到一条读取内存的指令的时候，会把内存地址传递给一级缓存，一级缓存会检查它是否有这个内存地址对应的缓存段，如果没有就把整个缓存段从内存共或者更高级的缓存种加载进来。
cpu执行计算的过程为：程序和数据被加载到主内存中，指令和数据被加载到cpu缓存中，cpu执行指令将结果写入cpu缓存中，cpu缓存中的数据写回到主内存中，但是这种方式仅限于单核cpu的时候
如果服务器是多核cpu呢，
多核处理器中主内存核处理器一样是分开的，这时候，L3作为统一的高速缓存共享，处理器1拥有自己的L1 L2

这个时候当核0读取了一个字节根据局部性原理，与他相邻的字节同样会被读入核0的缓存中
核3也读取了同样的一个字节，根据局部性原理，与他相邻的字节同样会被读入到核3的数据中
此时，核0和核3的缓存中拥有同样的数据
核0修改了那个字节之后，被修改后那个字节被回写到了核0的缓存中，但是该信息并没有回写到主内存
当核3访问该数据的时候，造成该数据不同步
为了解决这个问题**，当一个cpu修改缓存中的字节的时候，**服务器中其他cpu的会被通知他们的缓存将是为无效，这样核1在修改缓存中的数据的时候，核3会发现自己的缓存中的数据已经无效，核0将自己的写回到主内存中，然后核3将重新读取该数据
将代码转化为汇编指令的时候发现在汇编指令add之前有一个lock指令，lock指令就是关键。
lock指令的作用：在修改内存的时候使用lock前缀指令调用加锁的读修改写操作，保证多处理器系统总处理器之间进行可靠的通讯
1.锁总线，其他cpu对内存的读写请求会被阻塞，直到锁释放，不过实际候来的处理器都采用了缓存缓存代替锁总线，因为总线开销过大，锁总线的时候其他cpu没办法访问内存
2.lock后的写操作会回写已经修改的数据，同时让其他cpu相关缓存行失效，从而重新从内存中加载最新的数据
3.不是内存屏障却能完成内存屏障的功能，阻止屏障两边的指令重排序

嗅探式的缓存一致性协议：所有内存的传输都发生在一条共享的总线上，而所有的处理器都能看到这条总线，缓存本身是独立的，但是内存是共享的。所有的内存访问都要进行仲裁，即同一个指令周期种只有一个cpu缓存可以读写数据。cpu缓存不仅在内存传输的时候与总线打交道，还会不断的在嗅探总线上发生数据交换跟踪其他缓存在做什么，所以当一个cpu缓存代表它所属的处理器读写内存的时候，其他的处理器都会得到通知（主动通知），他们以此使自己的缓存保存同步。只要某个处理器写内存，其他处理器就马上直到这块内存在他们的缓存段种已经失效。。
MESI协议是缓存一致性协议，在MESI协议中每个缓存行有四个状态，Modified修改的，表示这行数据有效，数据被修改了和内存中的数据不一致，数据只存在当前cache中，Exclusive独有的，这行数据有效，数据和内存中的数据一致，数据只存在在本cache中，Shared共享的，这行数据有效，数据和内存中的数据一致，数据存在很多cache中，Invalid这行数据无效，这里的Invalid shared modified都符合我们的嗅探式的缓存一致性协议，但是Exclusive表示独占的，当前数据有效并且和内存中的数据一致，但是只在当前缓存中，Exclusive状态解决了一个cpu缓存在读写内存的之前我们要通知其他处理器这个问题，只有当缓存行处于Exclusive和modified的时候处理器才能写，也就是说只有在这两种状态之下，处理器是独占这个缓存行的，当处理器想写某个缓存行的时候，如果没有独占权就必须先发送一条我要独占权的请求给总线，这个时候会通知处理器把他们拥有同一缓存段的拷贝失效，只要在获得独占权的时候处理器才能修改数据并且此时这个处理器直到这个缓存行只有一份拷贝并且只在它的缓存里，不会有任何冲突，反之如果其他处理器一直想读取这个缓存行（马上就能直到，因为一直在嗅探总线），独占或已修改的缓存行必须要先回到共享状态，如果是已经修改的缓存行，还要先将内容回写到内存中。

volatile变量的读写
工作内存其实就是cpu缓存，当两条线程同时操作主内存中的一个volatile变量时候，A线程写了变量i，此时A线程发出lock指令，发出的lock指令锁总线或者锁缓存行，同时线程b的高速缓存中的缓存行内容失效，线程A想内存中回写最新的i。当线程B读取变量的时候，线程发现对应地址的缓存行被锁了等待锁释放，锁的一致性协议会保证它读取到最新的值。

5. volatile关键字的使用场景

1.使用volatile白能量作为状态标志。在该场景中，应用程序的某个状态由一个线程设置，其他线程会读取该状态并作为下一步计算依据。这是适用volatile变量作为同步机制的好处是一个线程能够“通知”另外一个线程某个事件的发生，而这些线程有无需因此而使用锁，避免了锁的开销和相关问题。

2.使用volatile保障可见性。

3.使用volatile代替锁。当多个线程共享一个变量（而非一组变量）时，通常需要使用锁来保障对这些变量的更新操作的原子性，以避免数据不一致。利用volatile关键字写的原子性，将这一组状态变量封装成一个对象，将更新操作通过新建对象并将该对象赋值给volatile变量来实现。

4.实现简易版读写锁。通过volatile变量和锁的混合使用实现；锁保障写操作的原子性，volatile保证读操作的可见性。但这种读写锁允许线程可以读取到共享变量的非最新值。
public class Counter{
private volatile long count = 0;
public long value(){
return count;
}

public void increment{
synchorized(this){
count++;
}
}
}

6. voliate怎么保证可见性

上次我们学习了volatile是如何解决多线程环境下共享变量的内存可见性问题，并且简单介绍了基于多核CPU并发缓存架构模型的Java内存模型。
详情见文章：

volatile很难？由浅入深怼到CPU汇编，彻底搞清楚它的底层原理

在并发编程中，有三个重要的特性：

内存可见性
原子性
有序性
volatile解决了并发编程中的可见性和有序性，解决不了原子性的问题，原子性的问题需要依赖synchronized关键字来解决。

关于并发编程三大特性的详细介绍，大家可以点击下方卡片搜索查看：

搜更多精彩内容

并发编程三大特性

内存可见性在上一篇文章中已经验证，本文我们继续通过代码学习如下内容：1、volatile为什么解决不了原子性问题？2、缓存行、缓存行填充3、CPU优化导致的乱序执行4、经典面试题：DCL必须要有volatile关键字吗？5、valatile关键字是如何禁止指令重排序的？

以上每一步都会有一段代码来验证，话不多说，开始输出干货！

1、volatile为什么解决不了原子性问题？

如果你对volatile了解的还可以，那么咱们继续往下看，如果不是太熟悉，请先行阅读上一篇文章。

老规矩，先来一段代码：

volatile原子性问题代码验证

这段代码的输出结果是多少？10000？大于10000？小于10000？

程序执行10次输出的结果如下：

join：10000
join：10000
join：10000
join：9819
join：10000
join：10000
join：10000
join：9898
join：10000
join：10000
会有小几率的出现小于10000的情况，因此volatile是无法保证原子性的，那么到底在什么地方出问题了呢？
还是用上篇文章的图来说明一下程序的整体流程：

当线程1从内存读取num的值到工作内存，同时线程2也从内存读取num的值到工作内存了，他俩各自操作自己的num++操作，但是关键点来了：

当线程1、2都执行完num++，线程1执行第五步store操作，通过总线将新的num值写回内存，刷新了内存中的num值，同时触发了总线嗅探机制，告知线程2其工作内存中的num不可用，因此线程2的num++得到的值被抛弃了，但是线程2的num++操作却是执行了。

2、CPU缓存行

写上篇文章的时候，有朋友问到了CPU的三级缓存以及缓存行相关的问题，然后我就找了一些资料学习，形成了下面的一张图：

CPU缓存行

CPU和主内存RAM之间会有三级缓存，因为CPU的速度要比内存的速度要快的多，大概是100:1，也就是CPU的速度比内存要快100倍，因此有了CPU三级缓存，那为什么是三级缓存呢？不是四级、五级呢？四个大字送给你：工业实践！相关概念：

ALU：CPU计算单元，加减乘除都在这里算
PC：寄存器，ALU从寄存器读取一次数据为一个周期，需要时间小于1ns
L1：1级缓存，当ALU从寄存器拿不到数据的时候，会从L1缓存去拿，耗时约1ns
L2：2级缓存，当L1缓存里没有数据的时候，会从L2缓存去拿，耗时约3ns
L3：3级缓存，一颗CPU里的双核共用，L2没有，则去L3去拿，耗时约15ns
RAM内存：当缓存都没有数据的时候，会从内存读取数据
缓存行：CPU从内存读取数据到缓存行的时候，是一行一行的缓存，每行是64字节（现代处理器）
问题来了：

1、缓存行存在的意义？好处是什么？

空间的考虑：一个地址被访问，相连的地址很大可能也被访问；

时间的考虑：最近访问的会被频繁访问好处：比如相连的地址，典型的就是数组，连续内存访问，很快！

2、缓存行会带来什么问题？

缓存行会导致缓存失效的问题，从而导致程序运行效率低下。例如下图：

当x,y两个变量在一个缓存行的时候：

1、线程1执行x++操作，将x和y所在的缓存行缓存到cpu core1里面去，

2、线程2执行y++操作，也将x和y所在的缓存行缓存到cpu core2里面去，

3、线程1执行了x++操作，写入到内存，同时为了保证cpu的缓存一致性协议，需要使其他内核x,y所在的缓存行失效，意味着线程2去执行y++操作的时候，无法从自己的cpu缓存拿到数据，必须从内存获取。

这就是缓存行失效！

一段代码来验证缓存行失效的问题：

缓存行失效例程

耗时：2079ms
这个时候我们做一个程序的改动，在x变量的前面和后面各加上7个long类型变量，如下：

再次运行，看耗时输出：

耗时：671ms
大约三倍的速度差距！

关于缓存行的更多概念，大家也可以点击下方卡片直接搜索更多信息：

搜更多精彩内容

缓存行

3、CPU优化导致的乱序执行

上文在说缓存行的时候，主要是因为CPU的速度大约是内存的速度的100倍，因此CPU在执行指令的时候，为了不等待内存数据的读取，会存在CPU指令优化而导致乱序执行的情况。

看下面这段代码：

cpu乱序执行例程

执行后输出(我执行了900多万次才遇到x=0,y=0的情况，可以试试你的运气哦～)：

因为CPU的速度比内存要快100倍，所以当有两行不相关的代码在执行的时候，CPU为了优化执行速度，是会乱序执行的，所以上面的程序会输出：x=0,y=0的情况,也就是两个线程的执行顺序变成了：

x = b;
y = a;
a = 1;
b = 1;
这个时候我们就需要加volatile关键字了，来禁止CPU的指令重排序！

4、DCL单例模式需要加volatile吗？

一道经典的面试题：DCL单例模式需要加volatile字段吗？先来看DCL单例模式的一段代码：

DCL单例模式

DCL全称叫做Double Check Lock，就是双重检查锁来保证一个对象是单例的。

核心的问题就是这个INSTANCE变量是否需要加volatile关键字修饰？答案肯定是需要的。

首先我们来看new一个对象的字节码指令：

查看其字节码指令：

NEW java/lang/Object
DUP
INVOKESPECIAL java/lang/Object.<init> ()V
ASTORE 1
即：

1、创建并默认初始化Object对象；

2、复制操作数栈对该对象的引用；

3、调用Object对象的初始化方法；

4、将变量Object o指向创建的这个对象，此时变量o不再为null；

根据上文描述我们知道因为CPU和内存速度不匹配的问题，CPU在执行命令的时候是乱序执行的，即CPU在执行第3步初始化方法时候如果需要很长的时间，CPU是不会等待第3步执行完了才去执行第4步，所以执行顺序可能是1、2、4、3。

那么继续看DCL单例程序,当线程1执行new DCLStudy()的顺序是先astore再invokespecial，但是invokespecial方法还没有执行的时候，线程2进来了，这个时候线程2拿到的就是一个半初始化的对象。

因此，DCL单例模式需要加volatile关键字，来禁止上述new对象的过程的指令重排序！

valatile关键字是如何禁止指令重排序的

JVM规范中规定：凡是被volatile修饰的变量，在进行其操作时候，需要加内存屏障！

JVM规范中定义的JSR内存屏障定义：

LoadLoad屏障：
对于语句Load1;LoadLoad;Load2;Load1和Load2语句不允许重排序。
StoreStore屏障：
对于语句Store1;StoreStore;Store2;Store1和Store2语句不允许重排序。
LoadStore屏障：
对于语句Load1;StoreStore;Store2;Load1和Store2语句不允许重排序。
StoreLoad屏障：
对于语句Store1;StoreStore;Load2;Store1和Load2语句不允许重排序。
JVM层面volatile的实现要求：

如果对一个volatile修饰的变量进行写操作：

前面加StoreStoreBarrier屏障，保证前面所有的store操作都执行完了才能对当前volatile修饰的变量进行写操作；

后面要加StoreLoadBarrier，保证后面所有的Load操作必须等volatile修饰的变量写操作完成。

如果对一个volatile修饰的变量进行读操作：

后面的读操作LoadLoadBarrier必须等当前volatile修饰变量读操作完成才能读；

后面的写操作LoadStoreBarrier必须等当前的volatile修饰变量读操作完成才能写。

上篇文章我们通过一定的方式看到了程序执行的volatile修饰的变量底层汇编码：

0x000000010d3f3203: lock addl $0x0,(%rsp) ;*putstatic flag
; - com.java.study.VolatileStudy::lambda$main$1@9 (line 31)
也就是到CPU的底层执行的命令其实就是这个lock，这个lock指令既完成了变量的可见性还保证了禁止指令充排序：

LOCK用于在多处理器中执行指令时对共享内存的独占使用。它的作用是能够将当前处理器对应缓存的内容刷新到内存，并使其他处理器对应的缓存失效；另外还提供了有序的指令无法越过这个内存屏障的作用。
end

至此，对volatile的学习就到这里了，通过两篇文章来对volatile这个关键字有了一个系统的学习。

学无止境，对volatile的学习还只是一个基础学习，还有更多的知识等待我们去探索学习，例如：

什么是as-if-serial？什么是happens-before？
Java的哪些指令可以重排序呢？重排序的规则是什么？
我们下期再见！

1372阅读
搜索
java自学一般要学多久
volatile底层原理
汇编111条指令详解
java必背100源代码
volatile架构图
嵌入式volatile详解