目录
简介
.Java虚拟机规范中试图定义一种Java内存模型 (Java Memory Model, JMM)来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到 一致的并发效果。在此之前，主流程序语言（如CIC++等）直接使用物理硬件（或者说 操作系统的内存模型），因此，会由于不同平台上内存模型的差异，导致程序在一套平 台上并发完全正常，而在另外一套平台上并发访问却经常出错，因此经常需要针对不同 的平台来编写程序。
定义Java内存模型并非一件容易的事情，这个模型必须定义得足够严谨，才能让Java的并发操作不会产生歧义；但是，也必须定义得足够宽松，使得虚拟机的实现能 有足够的自由空间去利用硬件的各种特性（寄存器、高速缓存等）来获取更好的执行速 度。经过长时间的验证和修补，在JDK 1.5 (实现了JSR-133 co)发布后，Java的内存模 型就已经成熟和完善起来了。
主内存与工作内存
Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量(Variable)与Java 编程中所说的变量略有区别，它包括了实例字段、静态字段和构成数组对象的元素， 但是不包括局部变量与方法参数，因为后者是线程私有的，不会被共享，自然就不存 在竞争问题。为了获得较好的执行效能，Java内存模型并没有限制执行引擎使用处理 器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器调整代码执行顺 序这类权利。
Java内存模型规定了所有的变量都存储在主内存(Main Memory)中（此处的主内存与介绍物理硬件时的主内存名字一样，两者也可以互相类比，但此处仅是虚拟机内存 的一部分）。每条线程还有自己的工作内存(Working Memory, 可与前面所讲的处理器 高速缓存类比），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝， 线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主 内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量 值的传递均需要通过主内存来完成，线程、主内存、工作内存三者的交互关系如图
这里所讲的主内存、工作内存与Java内存区域中的Java堆、栈、 方法区等并不是同一个层次的内存划分。如果两者一定要勉强对应起来，那从变量、主 内存、工作内存的定义来看，主内存主要对应于Java堆中对象的实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。从更低的层次来说，主内存就是硬件的内存， 而为了获取更好的运行速度，虚拟机及硬件系统可能会让工作内存优先存储于寄存器和高速缓存中。
硬件的关系图：
内存间交互操作（8种及其规则）
关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作 内存、如何从工作内存同步回主内存之类的实现细节，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操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作， 才会被解锁。（锁的规则）
如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使 用这个变量前，需要重新执行load或assign操作初始化变量的值。（锁的前后，为什么能够保证主内存是最新的，的规则）
如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不 允许去unlock一个被其他线程锁定住的变量。（锁的规则）
对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store 和write操作）。（锁的前后，为什么能够保证主内存是最新的，的规则）
对于volatile型变量的特殊规则
关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制，但是它并不容易被正确地、完整地理解，以至于许多程序员都习惯不去使用它，遇到需要处理多线程 数据竞争的问题时一律使用synchronized来进行同步。了解volatile变量的语义对后面 解多线程操作的其他特性有很重要的意义。
Java内存模型对volatile专门定义了一些特殊的访问规则，在介绍这些比较拗口的规则定义之前，先用不那么正式，但通俗易懂一些的语言来介绍一下这个关键字的 作用。
volatile的可见性
一个变量被定义成volatile之后，它将具备两种特性，第一是保证此变量对所有 线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他 线程来说是可以立即得知的。而普通变量不能做到这一点，变量值在线程间传递均需通过主内存来完成，如：线程A修改一个普通变量的值，然后向主内存进行回写，另外 一条线程B在线程A回写完成了之后再从主内存进行读取操作，新变量的值才会对线程 B可见。
关于volatile变量的可见性，经常会被开发人员误解，认为以下描述成立： "volatile 变量对所有线程是立即可见的，对volatile变量所有的写操作都能立刻反应到其他线程 中，换句话说，volatile变量在各个线程中是一致的，所以基于volatile变量的运算在是安全的＂。这句话的论据部分并没有错，但是其论据并不能得出“基于volatile 变量的运算在并发下是安全的“这个结论。volatile变量在各个线程的工作内存中不存在 一致性问题（在各个线程的工作内存中volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性 问题），但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的。
我们可以通过一段简单的演示来说明原因：20个线程，对一个类的静态的volatile字段num，进行num++，每个线程执行100次，但是最终结果却不是2000。
原因就是num++，是先得到最新的num，放入工作内存，得到num=10，然后计算num+1，得到11，然后11赋值给工作内存 的num，然后将工作内存的num=11返回到主内存。
但是得到num=10，和赋值num=11，之间可能不是连续的，可能别的线程也执行了num++，最后执行了2次num++，但是num=11。
由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍 然要通过加锁（使用synchronized或java.util.concurrent中的原子类）来保证原子性。（即下面两条都满足时，使用volatile变量）
运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。（其实就是多线程，不能同时执行这样的操作：对变量赋值的同时，需要依赖变量的当前值）
变量不需要与其他的状态变量共同参与不变约束。
这类场景就很适合使用volatile变量来控制并发：
下面 的的这个变量是volatile变量，首先它没有与其他的状态变量共同参与不变约束。
然后只有一个线程对变量进行修改，其他 线程 都是 只对它读取 。（其实，也满足变量的赋值不依赖于变量的当前值）
volatile的禁止指令重排序优化
使用volatile变量的第二个语义是禁止指令重排序优化，普通的变量仅仅会保证在 该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中 无法感知到这点，这也就是Java内存模型中描述的所谓的“线程内表现为串行的语义” (Within-Thread As-If-Serial Semantics)。
上面的描述仍然比较拗口难明，我们还是继续通过一个例子来 会干扰程序的并发执行吧，
其中描述的场景十分常见，只是我们在处 理配置文件时一般不会出现并发而已。如果定义initialized变量时没有使用volatile修 饰，就可能会由于指令重排序的优化，导致位于线程A中最后一句的代码"initialized = true"被提前执行，这样在线程B中使用配笠信息的代码就可能出现错误，而volatile 键字则可以避免此类情况的发生。
解决了volatile的语义问题，再来看看在众多保障并发安全的工具中选用volatile的意义一一它能让我们的代码比使用其他的同步工具更快吗？确实在某些情况下，volatile 同步机制的性能要优于锁（使用synchronized关键字或j ava. util. concurrentb包里面的 锁），但是由于虚拟机对锁实行的许多消除和优化，使得我们很难量化地说volatile就 比synchronized快上多少。如果让volatile自己与自己比较，则可以确定一个原则： volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢 一些，因为它要在本地代码中插入许多内存屏障(Memory Barrier或Memory Fence) 指令。来保证处理器不发生乱序执行。不过即便如此，大多数场景下volatile的总开销仍比锁来得低，我们在volatile与锁中选择的唯一判断依据仅仅是volatile的语义能 满足使用场景的需求。
volatile变量的特殊规则
Java内存模型中对volatile变量定义的特殊规则。
假定T表示一个线程，V和W分别表示两个volatile型变量，那么在进行read、load、 use、assign、store和write操作时需要满足如下的规则：
只有当线程T对变量V执行的前一个动作是load的时候，线程T才能对变量V 执行use动作；并且，只有当线程T对变量V执行的后一个动作是use的时候 线程T才能对变量V执行load动作。线程T对变量V的use动作可以认为是：线程T对变量V的load和read动作相关联的，必须一起连续出现。（这条规则要 求在工作内存中，每次使用V前都必须先从主内存刷新最新的值，用于保证能看 见其他线程对变量V所做的修改后的值）。（即read，load，use操作必须连续）
只有当线程T对变量V执行的前一个动作是assign的时候，线程T才能对变量 V执行store动作；并且，只有当线程T对变量V执行的后一个动作是store的时 候，线程T才能对变量V执行assign动作。线程T对变量V的assign动作可以 认为是与线程T对变量V的store和write动作相关联的，必须一起连续出现（这 条规则要求在工作内存中，每次修改V后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量V所做的修改）。（即assign，store，write操作必须连续）
假定动作A是线程T对变量V实施的use或assign动作，假定动作F是与动作 A相关联的load或store动作，假定动作P是与动作F相应的对变量V的read~ write动作；类似地，假定动作B是线程T对变量W实施的use或assign动作， 假定动作G是与动作B相关联的load或store动作，假定动作Q是与动作G相应的对变量W的read或write动作。如果A先于B, 那么P先于Q (这条规则要求volatile修饰的变量不会被指令重排序优化，保证代码的执行顺序与程序的顺序相同）。
对于long和double型变量的特殊规则
Java内存模型要求lock、unlock、read、load、assign、use、store和write这八个 操作都具有原子性，但是对于64位的数据类型(long和double), 在模型中特别定义了 一条宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的load、store、 read和write这四个操作的原子性，这点就是所谓的long和double的非原子性协定 (Nonatomic Treatment of double and long Variables)。
如果有多个进程共享一个并未声明为volatile的long或double类型的变量，并且同 时对它们进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他 线程修改值的代表了“半个变量”的数值。
不过这种读取到“半个变量”的情况非常罕见，因为Java内存模型虽然允许虚拟机 不把long和double变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为 有原子性的操作，而且还“强烈建议“虚拟机这样实现。在实际开发中，目前各种的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待，因此我们 在编写代码时一般不需要将用到的long和double变量专门声明为volatile。
原子性、可见性与有序性
Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这三个特征来建立的。
原子性(Atomicity) :
由Java内存模型来直接保证的原子性变量操作包括read、 load、assign、use、store和write这六个，我们大致可以认为基本数据类型的访问读写 是具备原子性的(long和double的非原子性协定例外，知道这件事情就可 以了，无须太过在意这些儿乎不会发生的例外情况）。
如果应用场景需要一个更大范围的原子性保证（经常会遇到），Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放 给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地 使用这两个操作，这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。
可见性(Visibility) :
可见性就是指当一个线程修改了共享变量的值，其他线程能够 立即得知这个修改。讲解volatile时候我们已详细讨论过这一点。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这 种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量
如此，普通变量与volatile变量的区别是volatile的特殊规则保证了新值能立即同步 到主内存，以及每次使用前立即从主内存刷新。因此我们可以说volatile保证了多线程 操作时变量的可见性，而普通变量则不能保证这点。
除了volatile之外，Java还有两个关键字能实现可见性，它们是synchronized和 final。
同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回 内存中（执行sotre和write操作）”这条规则获得的。
而final关键字的可见性是指： 被final修饰的字段在构造器中一且被初始化完成，并且构造器没有把"this"的引用传 递出去(this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初 始化了一半＂的对象），那么在其他线程中就能看见final字段的值。它们无须同步就能被其他线程正确地访问。
有序性(Ordering): Java内存模型的有序性在前面讲解volatile时也详细地讨论过 了，Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作 都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指 “线程内表现为串行的语义''(Within-Thread As-If-Serial Semantics), 后半句是指“指令 重排序“现象和“工作内存与主内存同步延迟“现象。
Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性。
volatile关键字本身就包含了禁止指令重排序的语义。
而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作“这条规则获得的，这个规则决定了持同一个锁的两个同步块只能串行地进入。
synchronized关键字在需要这三种特 性的时候都可以作为其中一种的解决方案。大部分的并发 控制操作都能使用synchronized来完成。synchronized的“万能”也间接造就了它被程 序员滥用的局面，越“万能”的并发控制，通常会伴随着越大的性能影响。
先行发生原则
如果Java内存模型中所有的有序性都只靠volatile和synchronized来完成，那么有 一些操作将会变得很啰嗦，但是我们在编写Java并发代码的时候并没有感觉到这一点， 因为Java语言中有一个“先行发生" (happens-before)的原则。这个原则非常重 要，它是判断数据是否存在竞争，线程是否安全的主要依据，依赖这个原则，我们可以 通过几条规则一揽子解决并发环境下两个操作之间是否可能存在冲突的所有问题。
先行发生是Java内存模型中定义的两 项操作之间的偏序关系，如果说操作A先行发生于操作B, 其实就是说在发生操作B之 前，操作A产生的影响能被操作B观察到，“影响“包括修改了内存中共享变量的值，发送了消息，调用了方法等。我们可以举个例子 来说明一下：
假设线程A中的操作"i=l"先行发生于线程B的操作"j = i", 那我们就可以确定 在线程B的操作执行后，变量j的值一定是等于1。
得出这个结论的依据有两个，一是 先行发生原则，"i=l"的结果可以被观察到；二是线程C登场之前，线程A操作 结束之后没有其他线程会修改变量i的值。
现在再来考虑线程C, 我们依然保持线程A 和B之间的先行发生关系，而C出现在线程A和B的操作之间，但是C与B没有先行 发生关系，那j的值会是多少呢？答案是不确定! 1和2都有可能，因为线程C对变量i 的影响可能会被线程B观察到，也可能不会，这时候线程B就存在读取到过期数据的风 险，不具备多线程安全性。
下面是Java内存模型下一些“天然的“先行发生关系，这些先行发生关系无须任何 同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列， 井且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们进行随 意地重排序。
程序次序规则(Program Order Rule) : 在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说应该是控制流顺序而不定 程序代码顺序，因为要考虑分支、循环等结构。 ．
管程锁定规则(Monitor Lock Rule) : 一个unlock操作先行发生于后面对同一个锁 的lock操作。这里必须强调的是同一个锁，而“后面”是指时间上的先后顺序。
volatile变量规则(Volatile Variable Rule) : 对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。
线程启动规则(Thread Start Rule) : Thread对象的start()方法先行发生于此线程 的每一个动作。
线程终止规则(Thread Termination Rule) : 线程中的所有操作都先行发生于对此 线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返 值等手段检测到线程已经终止执行。
线程中断规则(Thread Interruption Rule) : 对线程interrupt()方法的调用先行发 生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方 法检测到是否有中断发生。
对象终结规则(Finalizer Rule) : 一个对象的初始化完成（构造函数执行结束）先 行发生于它的finalize()方法的开始。
传递性(Transitivity) : 如果操作A先行发生于操作B, 操作B先行发生于操作 C, 那就可以得出操作A先行发生于操作C的结论。
Java语言无须任何同步手段保障就能成立的先行发生规则就只有上面这些了，使用这些规则去判定操作间是否具备顺序性，对于读写共享变量的操作来说，就是线程是否安全，可以从下面这个例子中感受一下”时间上的先后顺序” 与“先行发生”之间有什么不同。
显示的是一组再普通不过的getter/ setter方法，假设存在线程A和 B, 线程A先（时间上的先后）调用了"set Value(1) ", 然后线程B调用了同一个对象的 , get Value()", 那么线程B收到的返回值是什么？
我们依次分析一下先行发生原则中的各项规则，由于两个方法分别由线程A和B调 用，不在一个线程中，所以程序次序规则在这里不适用：由于没有同步块，自然就不会 发生lock和unlock操作，所以管程锁定规则不适用；由于value变量没有被volatile 键字修饰，所以volatile变批规则不适用；后面的线程启动、终止、中断规则和对象终 结规则也和这里完全扯不上关系。因为没有一个适用的先行发生规则，所以最后一条传递性也无从谈起，因此我们可以判定尽管线程A在操作时间上先于线程B, 但是无法确 定B中"get Value()"方法的返回结果，换句话说，这里面的操作不是线程安全的。
那怎么修复这个问题呢？我们至少有两种比较简单的方案可以选择：要么把getter/ setter方法都定义为synchronized方法，这样就可以套用管程锁定规则；要么把value定 义为volatile变量，由于setter方法对value的修改不依赖value的原值，满足了volatile关键字使用场景，这样就可以套用volatile变量规则来实现先行发生关系。
得出结论：一个操作“时间上的先发生”不代表这个 操作会是“先行发生“，那如果一个操作“先行发生”是否就能推导出这个操作必定是"时间上的先发生”呢？很遗憾，这个推论也是不成立的，一个典型的例子就是多次提指令重排序＂
两条复制语句在同一个线程之中，根据程序次序规则，int i =1 的操作先行发生于int j = 2, 但是"int j = 2"的代码完全可能先被处理器执行，这并 不影响先行发生原则的正确性，因为我们在这条线程之中没有办法感知到这点。
（即如果能感知到了，那么先行的就时间优先了，例如int i=1 i=i+2; 后一句一定在前一句的发生时间之后）
上面两个例子综合起来证明了一个结论：时间上的先后顺序与先行发生原则之间基 本没有太大的关系，所以我们衡量并发安全问题的时候不要受到时间顺序的干扰，一切 必须以先行发生原则为准。
2112
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
