目录
•写在前面
在正式讲解之前呢，我们先来讨论讨论硬件的效率与一致性。这里我们讲讲物理机对并发的处理方案，因为物理机遇到的并发问题与虚拟机中的情况有不少相似之处，所以它的方案对于虚拟机的实现也有相当大的参考意义。如何让计算机并发执行若干个运算任务以及如何更加充分的利用计算机处理器的效能之间，并没有想象的那么简单，其中一个重要的复杂性来源是绝大多数的运算任务都不可能只靠处理器计算就能完成的，处理器至少要与内存交互，如读取运算数据、储存运算结果等，这个I/O操作是很难消除的（无法仅靠寄存器来完成所有运算任务）。由于计算机的存储设备与处理器的运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写。虽然基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为计算机系统带来更高的复杂度，因为它引入了一个新的问题：缓存一致性。在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存，看如下图：
当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为准呢？为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作。在后面我们将要提到的“内存模型”一词，可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。
除了增加高速缓存之外，为了使得处理器内部的运算单元能尽量被充分利用，处理器可能会对输入代码进行乱序执行优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致，因此，如果存在一个计算任务依赖另一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类似，java虚拟机的即时编译器中也有类似的指令重排序优化。
•物理机三级缓存
- 1) 三级缓存（L1一级缓存、L2二级缓存、L3三级缓存）都是集成在CPU内的缓存
- 2) 它们的作用都是作为CPU与主内存之间的高速数据缓冲区
- 3) L1最靠近CPU核心，L2其次，L3再次 运行速度方面：L1最快、L2次快、L3最慢容量大小方面：L1最小、L2较大、L3最大
- 4) CPU会先在最快的L1中寻找需要的数据，找不到再去找次快的L2，还找不到再去找L3，L3都没有那就只能去内存找了。
- 5) 单核CPU只含有一套L1，L2，L3缓存；如果CPU含有多个核心，即多核CPU，则每个核心都含有一套L1（甚至和L2）缓存，而共享L3（或者和L2）缓存。
单CPU双核的缓存结构
在单线程环境下，cpu核心的缓存只被一个线程访问。缓存独占，不会出现访问冲突等问题 在多线程场景下，在CPU和主存之间增加缓存，就可能存在缓存一致性问题，也就是说，在多核CPU中，每个核的自己的缓存中，关于同一个数据的缓存内容可能不一致，这也就是我们上面提到的缓存一致性的问题
•乱序执行优化
这里再说说乱序执行优化，从java源码到最终实际执行的指令序列，会经历下面3种重排序：
重排序的现象：
-
a=10,b=a 这一组 b依赖a，不会重排序
-
a=10,b=50 这一组 a和b 没有关系，那么就有可能被重排序执行 b=50,a=10
-
cpu和编译器为了提高程序的执行效率会按照一定的规则允许指令优化，不影响单线程程序执行结果，但是多线程就会影响程序结果
•Java内存模型
Java虚拟机规范中试图定义一种Java内存模型（也就是我们说的JMM）来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量与Java编程中所说的变量有所区别它包括了实例字段。静态字段和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不会被共享。值得一提的是，注意JMM与JVM内存区域划分的区别，JMM描述的是一组规则，围绕原子性、有序性和可见性展开，相似点是都存在共享区域和私有区域。
Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存的变量。不同的线程之间也无法直接访问对方的工作内存中的变量，线程间变量值的传递均需要通过主内存来完成，交互图看下面。
图所示，本地内存A和B有主内存中共享变量z的副本。假设初始时，这三个内存中的z值都为0。线程A在执行时，把更新后的z值（假设值为1）临时存放在自己的本地内存A中。当线程A和线程B需要通信时，线程A首先会把自己本地内存中修改后的z值刷新到主内存中，此时主内存中的z值变为了1。随后，线程B到主内存中去读取线程A更新后的z值，此时线程B的本地内存的z值也变为了1。从整体来看，这两个步骤实质上是线程A在向线程B发送消息，而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供内存可见性保证。
•内存间交互操作
关于内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，java内存模型中定义了以下8种操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子的，不可再分的。
Java 内存模型对主内存与工作内存之间的具体交互协议定义了八种操作，具体如下：
- lock（锁定）：作用于主内存变量，把一个变量标识为一条线程独占状态。
- unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
- read（读取）：作用于主内存变量，把一个变量从主内存传输到线程的工作内存中，以便随后的 load 动作使用。
- load（载入）：作用于工作内存变量，把 read 操作从主内存中得到的变量值放入工作内存的变量副本中。
- use（使用）：作用于工作内存变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量值的字节码指令时执行此操作。
- assign（赋值）：作用于工作内存变量，把一个从执行引擎接收的值赋值给工作内存的变量，每当虚拟机遇到一个需要给变量进行赋值的字节码指令时执行此操作。
- store（存储）：作用于工作内存变量，把工作内存中一个变量的值传递到主内存中，以便后续 write 操作。
- write（写入）：作用于主内存变量，把 store 操作从工作内存中得到的值放入主内存变量中。
如果要把一个变量从主内存复制到工作内存就必须按顺序执行 read 和 load 操作，从工作内存同步回主内存就必须顺序执行 store 和 write 操作，但是 JVM 只要求了操作的顺序而没有要求上述操作必须保证连续性，所以实质执行中 read 和 load 间及 store 和 write 间是可以插入其他指令的。除此之外，java内存模型还规定了在执行上述8种基本操作时必须满足如下规则：
- 如果要把一个变量从主内存中复制到工作内存，就需要按顺序地执行read和load操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。但Java内存模型只要求上诉操作必须按顺序执行，而没有保证必须是连续执行
- 不允许read和load、store和write操作之一单独出现
- 不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中
- 不允许一个线程无原因的（没有发生过任何assign操作）把数据从工作内存同步回主内存中
- 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作
- 一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会解锁。lock和unlock必须成对出现
- 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
- 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量
- 对一个变量执行unlock操作之前，必须先把此变量同步到主内存中(执行store和write操作)
•volatile型变量
关键词volatile可以说是Java虚拟机提供的最轻量级的同步机制，但是它并不容易完全被正确、完整的理解，所以很多时候都习惯不去用它，而遇到需要处理出现成数据竞争问题的时候，一律使用synchronized来进行同步，不过这里还是需要了解volatile的。当一个变量定义为volatile之后，它将具备两种特性，第一是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的，而普通变量不能做到这一点，普通变量的值在线程间传递均需要通过主内存来完成，例如，线程A修改一个普通变量的值，然后向主内存进行回写，另外一个线程B在线程A回写完成了之后再从主内存进行读取操作，新变量值才会对线程B可见。
换个更简单的理解，关于volatile变量的可见性，经常会被开发人员误解，认为以下描述成立：“volatile变量对所有线程是立即可见的，对volatile变量所有的写操作都能立刻反应到其他线程之中，换句话说，volatile变量在各个线程中是一致的，所以基于volatile变量的运算在并发下是安全的”，这句话，论据部分并没有错，但是其论据并不能得出“基于volatile变量的运算在并发下是安全的”这个结论。volatile变量在各个线程的工作内存中不存在一致性问题（在各个线程的工作内存中，volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题），但是java里面的运算并非原子性操作，导致volatile变量的运算在并发下一样是不安全的，即volatile只保证可见性，需要保证原子性就仍然要通过加锁完成。
其实 Java JMM 内存模型是围绕并发编程中原子性、可见性、有序性三个特征来建立的，关于原子性、可见性、有序性的理解如下：
- 原子性：就是说一个操作不能被打断，要么执行完要么不执行，类似事务操作，Java 基本类型数据的访问大都是原子操作，long 和 double 类型是 64 位，在 32 位 JVM 中会将 64 位数据的读写操作分成两次 32 位来处理，所以 long 和 double 在 32 位 JVM 中是非原子操作，也就是说在并发访问时是线程非安全的，要想保证原子性就得对访问该数据的地方进行同步操作，譬如 synchronized 等。
- 可见性：就是说当一个线程对共享变量做了修改后其他线程可以立即感知到该共享变量的改变，从 Java 内存模型我们就能看出来多线程访问共享变量都要经过线程工作内存到主存的复制和主存到线程工作内存的复制操作，所以普通共享变量就无法保证可见性了；Java 提供了 volatile 修饰符来保证变量的可见性，每次使用 volatile 变量都会主动从主存中刷新，除此之外 synchronized、Lock、final 都可以保证变量的可见性。
- 有序性：就是说 Java 内存模型中的指令重排不会影响单线程的执行顺序，但是会影响多线程并发执行的正确性，所以在并发中我们必须要想办法保证并发代码的有序性；在 Java 里可以通过 volatile 关键字保证一定的有序性，还可以通过 synchronized、Lock 来保证有序性，因为 synchronized、Lock 保证了每一时刻只有一个线程执行同步代码相当于单线程执行，所以自然不会有有序性的问题；除此之外 Java 内存模型通过 happens-before 原则如果能推导出来两个操作的执行顺序就能先天保证有序性，否则无法保证，关于 happens-before 原则可以查阅相关资料。
在众多保障并发安全的工作中选用volatile的意义，是它能让我们的代码比使用其他的同步工具更快吗？在某些情况下，volatile的同步机制的性能确实要优于锁（这里的锁指的是synchronized关键字或java.util.concurrent包里面的锁），但是由于虚拟机对锁实行的许多消除和优化，使得我们很难量化地认为volatile就会比synchronized快多少，如果让volatile自己与自己比较，那可以确定一个原则：volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会，慢一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行，不过即便如此，大多数场景下volatile的总开销仍然要比锁低，我们在volatile与锁之中选择的唯一依据仅仅是volatile的语义能否满足使用场景的需求。
•先行发生原则
如果Java内存模型中所有的有序性都仅仅靠volatile和synchronized来完成，那么有一些操作将会变得很繁琐，但是我们编写java并发代码的时候并没有感觉到这一点，这是因为java语言中有一个先行发生的原则。这个原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则一揽子地解决并发环境下两个操作之间是否可能存在冲突的所有问题。那“先行发生”原则指的是什么。先行发生时java内存模型中定义的亮相操作之间的偏序关系，如果说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。以下规则是Java语言“天然”存在的规则，无需同步手段（例：加synchronized）就能保证先行发生。
- 程序次序规则：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。
- 管程锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，这里的“后面”指的是时间上的先后顺序。
- volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”指的是时间上的先后顺序。
- 线程启动规则：Thread对象的start()方法先行发生于此线程的每一个动作。
- 线程终止规则：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。
- 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生（即先中断，后发现被中断），可以通过Thread.interrupted()方法检测到是否有中断发生。
- 对象终结规则：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始。
- 传递性：若操作A先行发生于操作B，操作B先行发生于操作C，那么就可以得出操作A先行发生于操作C。
