面试官没想到一个Volatile，我都能跟他扯半小时

点赞再看，养成习惯，微信搜索【三太子敖丙】关注这个互联网苟且偷生的工具人。

本文 GitHub github.com/JavaFamily 已收录，有一线大厂面试完整考点、资料以及个人系列文章。

Volatile多是面试里面必问的一个话题吧，对他的认知不少朋友也仅限于会用阶段，今天咱们换个角度去看看。

先来跟着丙丙来看一段demo的代码

你会发现，永远都不会输出有点东西这一段代码，按道理线程改了flag变量，主线程也能访问到的呀？

为会出现这个状况呢？那咱们就须要聊一下另一个东西了。

JMM（JavaMemoryModel）

JMM：Java内存模型，是java虚拟机规范中所定义的一种内存模型，Java内存模型是标准化的，屏蔽掉了底层不一样计算机的区别（注意这个跟JVM彻底不是一个东西，只有还有小伙伴搞错的）。

那正式聊以前，丙丙先大概科普一下现代计算机的内存模型吧。

现代计算机的内存模型

其实早期计算机中cpu和内存的速度是差很少的，但在现代计算机中，cpu的指令速度远超内存的存取速度，因为计算机的存储设备与处理器的运算速度有几个数量级的差距，因此现代计算机系统都不得不加入一层读写速度尽量接近处理器运算速度的高速缓存（Cache）来做为内存与处理器之间的缓冲。

将运算须要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，可是也为计算机系统带来更高的复杂度，由于它引入了一个新的问题：缓存一致性（CacheCoherence）。

在多处理器系统中，每一个处理器都有本身的高速缓存，而它们又共享同一主内存（MainMemory）。

而后咱们能够聊一下JMM了。

JMM

Java内存模型(JavaMemoryModel)描述了Java程序中各类变量(线程共享变量)的访问规则，以及在JVM中将变量，存储到内存和从内存中读取变量这样的底层细节。

JMM有如下规定：

全部的共享变量都存储于主内存，这里所说的变量指的是实例变量和类变量，不包含局部变量，由于局部变量是线程私有的，所以不存在竞争问题。

每个线程还存在本身的工做内存，线程的工做内存，保留了被线程使用的变量的工做副本。

线程对变量的全部的操做(读，取)都必须在工做内存中完成，而不能直接读写主内存中的变量。

不一样线程之间也不能直接访问对方工做内存中的变量，线程间变量的值的传递须要经过主内存中转来完成。

本地内存和主内存的关系：

正是由于这样的机制，才致使了可见性问题的存在，那咱们就讨论下可见性的解决方案。

可见性的解决方案

加锁

为啥加锁能够解决可见性问题呢？

由于某一个线程进入synchronized代码块先后，线程会得到锁，清空工做内存，从主内存拷贝共享变量最新的值到工做内存成为副本，执行代码，将修改后的副本的值刷新回主内存中，线程释放锁。

而获取不到锁的线程会阻塞等待，因此变量的值确定一直都是最新的。

Volatile修饰共享变量

开头的代码优化完以后应该是这样的：

Volatile作了啥？

每一个线程操做数据的时候会把数据从主内存读取到本身的工做内存，若是他操做了数据而且写会了，他其余已经读取的线程的变量副本就会失效了，须要都数据进行操做又要再次去主内存中读取了。

volatile保证不一样线程对共享变量操做的可见性，也就是说一个线程修改了volatile修饰的变量，当修改写回主内存时，另一个线程当即看到最新的值。

是否是看着加一个关键字很简单，但实际上他在背后含辛茹苦默默付出了很多，我从计算机层面的缓存一致性协议解释一下这些名词的意义。

以前咱们说过当多个处理器的运算任务都涉及同一块主内存区域时，将可能致使各自的缓存数据不一致，举例说明变量在多个CPU之间的共享。

若是真的发生这种状况，那同步回到主内存时以谁的缓存数据为准呢？

为了解决一致性的问题，须要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操做，这类协议有MSI、MESI（IllinoisProtocol）、MOSI、Synapse、Firefly及DragonProtocol等。

聊一下Intel的MESI吧

MESI（缓存一致性协议）

当CPU写数据时，若是发现操做的变量是共享变量，即在其余CPU中也存在该变量的副本，会发出信号通知其余CPU将该变量的缓存行置为无效状态，所以当其余CPU须要读取这个变量时，发现本身缓存中缓存该变量的缓存行是无效的，那么它就会从内存从新读取。

至因而怎么发现数据是否失效呢？

嗅探

每一个处理器经过嗅探在总线上传播的数据来检查本身缓存的值是否是过时了，当处理器发现本身缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操做的时候，会从新从系统内存中把数据读处处理器缓存里。

嗅探的缺点不知道你们发现了没有？

总线风暴

因为Volatile的MESI缓存一致性协议，须要不断的从主内存嗅探和cas不断循环，无效交互会致使总线带宽达到峰值。

因此不要大量使用Volatile，至于何时去使用Volatile何时使用锁，根据场景区分。

咱们再来聊一下指令重排序的问题

禁止指令重排序

什么是重排序?

为了提升性能，编译器和处理器经常会对既定的代码执行顺序进行指令重排序。

重排序的类型有哪些呢？源码到最终执行会通过哪些重排序呢？

一个好的内存模型实际上会放松对处理器和编译器规则的束缚，也就是说软件技术和硬件技术都为同一个目标，而进行奋斗：在不改变程序执行结果的前提下，尽量提升执行效率。

JMM对底层尽可能减小约束，使其可以发挥自身优点。

所以，在执行程序时，为了提升性能，编译器和处理器经常会对指令进行重排序。

通常重排序能够分为以下三种：

• 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，能够从新安排语句的执行顺序;

• 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。若是不存在数据依赖性，处理器能够改变语句对应机器指令的执行顺序;

• 内存系统的重排序。因为处理器使用缓存和读/写缓冲区，这使得加载和存储操做看上去多是在乱序执行的。

这里还得提一个概念，as-if-serial。

as-if-serial

无论怎么重排序，单线程下的执行结果不能被改变。

编译器、runtime和处理器都必须遵照as-if-serial语义。

那Volatile是怎么保证不会被执行重排序的呢？

内存屏障

java编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。

为了实现volatile的内存语义，JMM会限制特定类型的编译器和处理器重排序，JMM会针对编译器制定volatile重排序规则表：

须要注意的是：volatile写是在前面和后面分别插入内存屏障，而volatile读操做是在后面插入两个内存屏障。

写

读

上面的我提太重排序原则，为了提升处理速度，JVM会对代码进行编译优化，也就是指令重排序优化，并发编程下指令重排序会带来一些安全隐患：如指令重排序致使的多个线程操做之间的不可见性。

若是让程序员再去了解这些底层的实现以及具体规则，那么程序员的负担就过重了，严重影响了并发编程的效率。

从JDK5开始，提出了happens-before的概念，经过这个概念来阐述操做之间的内存可见性。

happens-before

若是一个操做执行的结果须要对另外一个操做可见，那么这两个操做之间必须存在happens-before关系。

volatile域规则：对一个volatile域的写操做，happens-before于任意线程后续对这个volatile域的读。

若是如今个人变了falg变成了false，那么后面的那个操做，必定要知道我变了。

聊了这么多，咱们要知道Volatile是没办法保证原子性的，必定要保证原子性，可使用其余方法。

没法保证原子性

就是一次操做，要么彻底成功，要么彻底失败。

假设如今有N个线程对同一个变量进行累加也是没办法保证结果是对的，由于读写这个过程并非原子性的。

要解决也简单，要么用原子类，好比AtomicInteger，要么加锁(记得关注Atomic的底层)。

应用

单例有8种写法，我说一下里面比较特殊的一种，涉及Volatile的。

你们可能好奇为啥要双重检查？若是不用Volatile会怎么样？

我先讲一下禁止指令重排序的好处。

对象实际上建立对象要进过以下几个步骤：

• 分配内存空间。
• 调用构造器，初始化实例。
• 返回地址给引用

上面我不是说了嘛，是可能发生指令重排序的，那有可能构造函数在对象初始化完成前就赋值完成了，在内存里面开辟了一片存储区域后直接返回内存的引用，这个时候还没真正的初始化完对象。

可是别的线程去判断instance！=null，直接拿去用了，其实这个对象是个半成品，那就有空指针异常了。

可见性怎么保证的？

由于可见性，线程A在本身的内存初始化了对象，还没来得及写回主内存，B线程也这么作了，那就建立了多个对象，不是真正意义上的单例了。

上面提到了volatile与synchronized，那我聊一下他们的区别。

volatile与synchronized的区别

volatile只能修饰实例变量和类变量，而synchronized能够修饰方法，以及代码块。

volatile保证数据的可见性，可是不保证原子性(多线程进行写操做，不保证线程安全);而synchronized是一种排他(互斥)的机制。 volatile用于禁止指令重排序：能够解决单例双重检查对象初始化代码执行乱序问题。

volatile能够看作是轻量版的synchronized，volatile不保证原子性，可是若是是对一个共享变量进行多个线程的赋值，而没有其余的操做，那么就能够用volatile来代替synchronized，由于赋值自己是有原子性的，而volatile又保证了可见性，因此就能够保证线程安全了。

总结

1. volatile修饰符适用于如下场景：某个属性被多个线程共享，其中有一个线程修改了此属性，其余线程能够当即获得修改后的值，好比booleanflag;或者做为触发器，实现轻量级同步。
2. volatile属性的读写操做都是无锁的，它不能替代synchronized，由于它没有提供原子性和互斥性。由于无锁，不须要花费时间在获取锁和释放锁_上，因此说它是低成本的。
3. volatile只能做用于属性，咱们用volatile修饰属性，这样compilers就不会对这个属性作指令重排序。
4. volatile提供了可见性，任何一个线程对其的修改将立马对其余线程可见，volatile属性不会被线程缓存，始终从主 存中读取。
5. volatile提供了happens-before保证，对volatile变量v的写入happens-before全部其余线程后续对v的读操做。
6. volatile可使得long和double的赋值是原子的。
7. volatile能够在单例双重检查中实现可见性和禁止指令重排序，从而保证安全性。

注：以上全部的内容若是能所有掌握我想Volatile在面试官那是很加分了，可是我还没讲到不少关于计算机内存那一块的底层，那你们就须要后面去补课了，若是等得及，也能够等到我写计算机基础章节。

絮叨

img

由于更新文章和视频，丙丙已经半年多的周末没休息了，都是在公司那个工位冲冲冲，一直想找时间出去玩，想着年假一天没用，就请了两天出去玩一下。

这样五一就能够早点回来，准备恢复视频的更新，你在看的时候呢，敖丙应该在出游的列车上了，是的我就背了这个包，到写完的时候，我还没肯定去哪里，提早祝你们节日愉快。

我是敖丙，一个在互联网苟且偷生的工具人。

你知道的越多，你不知道的越多，人才们的 【三连】 就是丙丙创做的最大动力，咱们下期见！

注：若是本篇博客有任何错误和建议，欢迎人才们留言，你快说句话啊！

---

文章持续更新，能够微信搜索「 三太子敖丙 」第一时间阅读，回复【资料】【面试】【简历】有我准备的一线大厂面试资料和简历模板，本文 GitHub github.com/JavaFamily 已经收录，有大厂面试完整考点，欢迎Star。