一 概述
多任务和高并发是衡量一台计算机处理器的能力重要指标之一。一般衡量一台服务器性能的高低好坏，使用每秒事务处理数（Transactions Per Second, TPS）这个指标比较能说明，它代表着一秒内服务器平均能响应的请求数，而TPS值与程序的并发能力有着密切的关系。在讨论java内存模型之前，先简单介绍一下硬件的效率和一致性。
二 硬件的效率和一致性
由于计算机的存储设备的读写能力和处理器的运算能力之间有几个数量级的差距，所以现代计算机系统不得不加入一层读写速度尽可能接近处理器运算速度的告诉缓存（Cache）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无需等待缓慢的内存读写了。
基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是引入了新的问题：缓存一致性。在多处理器系统中，每个处理器都有自己的高速缓存，而他们又共享一个主存，如下图所示：多个处理器运算任务都涉及同一块主存，需要一种协议可以保障数据的一致性。Java虚拟机内存模型中定义的内存访问操作与硬件的缓存访问操作是具有可比性的，后续将介绍Java内存模型。
三 Java内存模型（基本概念）
定义Java内存模型不是一件容易的事情，这个模型必须定义得足够严谨，才能让Java的并发操作不会产生歧义，但是也必须得足够宽松，使得虚拟机的实现由足够的自由空间去利用硬件的各种特性（寄存器、高速缓存等）来获取过更好的执行速度。
3.1 并发
定义：即，并发(同时)发生。在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任一个时刻点上只有一个程序在处理机上运行。
并发需要处理两个关键问题：线程之间如何通信及线程之间如何同步。
(01) 通信 —— 是指线程之间如何交换信息。在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。
(02) 同步—— 是指程序用于控制不同线程之间操作发生相对顺序的机制。在Java中，可以通过volatile，synchronized, 锁等方式实现同步。
在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。
同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。
Java的并发采用的是共享内存模型，Java线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。如果编写多线程程序的Java程序员不理解隐式进行的线程之间通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。
3.2 主内存与工作内存
主内存 —— 即main memory。在java中，实例域、静态域和数组元素是线程之间共享的数据，它们存储在主内存中。
本地内存 —— 即local memory。 局部变量，方法定义参数 和 异常处理器参数是不会在线程之间共享的，它们存储在线程的本地内存中。
Java内存模型的主要目标是定义程序各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量指 实例字段、静态字段和构成数组的元素，但不包括局部变量和方法参数，后者是线程私有。
从抽象的角度来看，JMM（Java内存模型）定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每条线程还有自己的本地内存（可以与前面将的处理器的高速缓存类比），线程的本地内存中保存了该线程使用到的变量到主内存副本拷贝，线程对变量的所有操作（读取、赋值）都必须在本地内存中进行，而不能直接读写主内存中的变量。不同线程之间无法直接访问对方本地内存中的变量，线程间变量值的传递均需要在主内存来完成。Java内存模型的抽象示意图如下：
从上图来看，线程A与线程B之间如要通信的话，必须要经历下面2个步骤：
1. 首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
2. 然后，线程B到主内存中去读取线程A之前已更新过的共享变量。
下面通过示意图来说明这两个步骤：
如上图所示，本地内存A和B有主内存中共享变量x的副本。假设初始时，这三个内存中的x值都为0。线程A在执行时，把更新后的x值（假设值为1）临时存放在自己的本地内存A中。当线程A和线程B需要通信时，线程A首先会把自己本地内存中修改后的x值刷新到主内存中，此时主内存中的x值变为了1。随后，线程B到主内存中去读取线程A更新后的x值，此时线程B的本地内存的x值也变为了1。
从整体来看，这两个步骤实质上是线程A在向线程B发送消息，而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供内存可见性保证。
3.3 内存间交互操作
关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成：
- lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
- unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
- read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
- load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
- use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
- assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
- store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
- write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。
如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。也就是read和load之间，store和write之间是可以插入其他指令的，如对主内存中的变量a、b进行访问时，可能的顺序是read a，read b，load b， load a。Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：
- 不允许read和load、store和write操作之一单独出现
- 不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。
- 不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
- 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
- 一个变量在同一时刻只允许一条线程对其进行lock操作，lock和unlock必须成对出现
- 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
- 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
- 对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。
3.4 重排序
定义：重排序是指“编译器和处理器”为了提高性能，而在程序执行时会对程序进行的重排序。
说明：重排序分为——“编译器”和“处理器”两个方面，而“处理器”重排序又包括“指令级重排序”和“内存的重排序”。
关于重排序，我们需要理解它的思想：为了提高程序的并发度，从而提高性能！但是对于多线程程序，重排序可能会导致程序执行的结果不是我们需要的结果！因此，就需要我们通过“volatile，synchronize，锁等方式”作出正确的实现同步。
重排序分为三种类型：
1 编译器优化的重排序。编译器再不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
2 指令级并行的重排序。现代处理器采用了指令级并行技术（（Instruction-Level Parallelism， ILP））来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
3 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
从java源代码到最终实际执行的指令序列，会分别经历下面三种重排序：
3.5 内存屏障
为了保证内存的可见性，Java编译器再生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。Java内存模型把内存屏障分为LoadLoad、LoadStore、StoreLoad、StoreStore四种：
LoadLoad屏障：对于这样的语句 Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
StoreStore屏障：对于这样的语句 Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个“全能型”屏障，兼具其它三种内存屏障的功能。
3.6 happens - before
定义：JDK5(JSR-133)提供的概念，用于描述多线程操作之间的内存可见性。如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。
作用：描述多线程操作之间的内存可见性。
[程序顺序规则]：一个线程中的每个操作，happens- before 于该线程中的任意后续操作。
[监视器锁规则]：对一个监视器锁的解锁，happens- before 于随后对这个监视器锁的加锁。
[volatile变量规则]：对一个volatile域的写，happens- before 于任意后续对这个volatile域的读。
[传递性]：如果A happens- before B，且B happens- before C，那么A happens- before C。
如上图所示，一个happens-before规则通常对应于多个编译器和处理器重排序规则。对于java程序员来说，happens-before规则简单易懂，它避免java程序员为了理解JMM提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现。
3.7 数据依赖性
定义：如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。
作用：编译器和处理器不会对“存在数据依赖关系的两个操作”执行重排序。
3.8 as-if-serial
定义：不管怎么重排序（编译器和处理器为了提高并行度），（单线程程序）程序的执行结果不能被改变。
为了遵守as-if-serial，编译器和处理器不会对“存在数据依赖关系的两个操作”执行重排序。遵守as-if-serial语义的编译器和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。
3.9 顺序一致性内存模型
定义：它是理想化的内存模型。有以下规则：
(01) 一个线程中的所有操作必须按照程序的顺序来执行。
(02) 所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。
3.10 JMM
定义：Java Memory Mode，即Java内存模型。它是Java线程之间通信的控制机制。
说明：JMM对Java程序作出保证——如果程序是正确同步的，程序的执行将具有顺序一致性。即，程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同。
3.11 可见性
可见性一般用于指不同线程之间的数据是否可见。
在java中， 实例域、静态域和数组元素这些数据是线程之间共享的数据，它们存储在主内存中；主内存中的所有数据对该内存中的线程都是可见的。而局部变量，方法定义参数 和 异常处理器参数这些数据是不会在线程之间共享的，它们存储在线程的本地内存中；它们对其它线程是不可见的。
此外，对于主内存中的数据，在本地内存中会对应的创建该数据的副本(相当于缓冲)；这些副本对于其它线程也是不可见的。
3.12 原子性
是指一个操作是按原子的方式执行的。要么该操作不被执行；要么以原子方式执行，即执行过程中不会被其它线程中断。
四 同步机制
4.1.volatile
4.1.1 作用
如果一个变量是volatile类型，则对该变量的读写就将具有原子性。如果是多个volatile操作或类似于volatile++这种复合操作，这些操作整体上不具有原子性。volatile变量自身具有下列特性：
[可见性]：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
【禁止指令重排序】
valotile并不保证原子性。
4.1.2 volatile的内存语义
volatile写：当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存。
volatile读：当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。
- 线程A写一个volatile变量，实质上是线程A向接下来要读这个volatile变量的某个线程发出了（其对共享变量所做修改）消息
- 线程B读一个volatile变量，实质上是线程B接收了之前某个线程发出的（在写这个volatile变量之前对共享变量所做的修改）
- 线程A写一个volatile变量，随后线程B读这个volatile变量，这个过程实质上是线程A通过主内存向线程B发送消息。
4.1.3 JMM中的实现方式
JMM针对编译器制定的volatile重排序规则表：
|
是否能重排序 |
第二个操作 |
||
|
第一个操作 |
普通读/写 |
volatile读 |
volatile写 |
|
普通读/写 |
|
|
NO |
|
volatile读 |
NO |
NO |
NO |
|
volatile写 |
|
NO |
NO |
下面是基于保守策略的JMM内存屏障插入策略：
在每个volatile写操作的前面插入一个StoreStore屏障。 在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障和一个LoadStore屏障。
严格限制编译器和处理器对volatile变量与普通变量之间的重排序，确保volatile的写-读和锁的释放-获取具有相同的内存语义。
4.1.4 volatile和 synchronize对比
在功能上，监视器锁比volatile更强大；在可伸缩性和执行性能上，volatile更有优势。
volatile仅仅保证对单个volatile变量的读/写具有原子性；而synchronize锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。
4.2 锁
4.2.1 作用
锁是java并发编程中最重要的同步机制。
4.2.2 锁的释放和获取的内存语义
(01) 线程A释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息。
(02) 线程B获取一个锁，实质上是线程B接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息。
(03) 线程A释放锁，随后线程B获取这个锁，这个过程实质上是线程A通过主内存向线程B发送消息。
4.2.3 JMM如何实现锁的内存语义
公平锁
公平锁（Fair）：加锁前检查是否有排队等待的线程，优先排队等待的线程，先来先得
公平锁是通过“volatile”实现同步的。公平锁在释放锁的最后写volatile变量state；在获取锁时首先读这个volatile变量。根据volatile的happens-before规则，释放锁的线程在写volatile变量之前可见的共享变量，在获取锁的线程读取同一个volatile变量后将立即变的对获取锁的线程可见。
非公平锁
非公平锁（Nonfair）：加锁时不考虑排队等待问题，直接尝试获取锁，获取不到自动到队尾等待
通过CAS实现的，CAS就是compare and swap。CAS实际上调用的JNI函数，也就是CAS依赖于本地实现。以Intel来说，对于CAS的JNI实现函数，它保证：(01)禁止该CAS之前和之后的读和写指令重排序。(02)把写缓冲区中的所有数据刷新到内存中。
4.3 final
4.3.1 特性
对于基本类型的final域，编译器和处理器要遵守两个重排序规则：
final写：“构造函数内对一个final域的写入”，与“随后把这个被构造对象的引用赋值给一个引用变量”，这两个操作之间不能重排序。
final读：“初次读一个包含final域的对象的引用”，与“随后初次读对象的final域”，这两个操作之间不能重排序。
对于引用类型的final域，除上面两条之外，还有一条规则：
final写：在“构造函数内对一个final引用的对象的成员域的写入”，与“随后在构造函数外把这个被构造对象的引用赋值给一个引用变量”，这两个操作之间不能重排序。
注意：
写final域的重排序规则可以确保：在引用变量为任意线程可见之前，该引用变量指向的对象的final域已经在构造函数中被正确初始化过了。其实要得到这个效果，还需要一个保证：在构造函数内部，不能让这个被构造对象的引用为其他线程可见，也就是对象引用不能在构造函数中“逸出”。
4.3.2 JMM如何实现final
通过“内存屏障”实现。
在final域的写之后，构造函数return之前，插入一个StoreStore障屏。在读final域的操作前面插入一个LoadLoad屏障。
五 JMM 总结
JMM保证：如果程序是正确同步的，程序的执行将具有顺序一致性 。
从JMM设计者的角度来说，在设计JMM时，需要考虑两个关键因素：
(01) 程序员对内存模型的使用。程序员希望内存模型易于理解，易于编程。程序员希望基于一个强内存模型(程序尽可能的顺序执行)来编写代码。
(02) 编译器和处理器对内存模型的实现。编译器和处理器希望内存模型对它们的束缚越少越好，这样它们就可以做尽可能多的优化(对程序重排序，做尽可能多的并发)来提高性能。编译器和处理器希望实现一个弱内存模型。
JMM设计就需要在这两者之间作出协调。JMM对程序采取了不同的策略：
(01) 对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序。
(02) 对于不会改变程序执行结果的重排序，JMM对编译器和处理器不作要求（JMM允许这种重排序）。
JMM的内存可见性保证
Java的内存可见性保证按程序类型可以分为下列三类：
1 单线程程序。单线程程序不会出现内存可见性问题。编译器、runtime和处理器会共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
2 正确同步的多线程程序。正确同步的多线程程序的执行顺序将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM的重点，JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。
3 未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0， null， false）
参考自
1 http://www.cnblogs.com/skywang12345/p/3447546.html?utm_source=tuicool