Java内存模型
Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。 此处的变量（Variables）与Java编程中所说的变量有所区别，它包括了实例字段、 静态字段和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不会被共享，自然就不会存在竞争问题。 为了获得较好的执行效能，Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器进行调整代码执行顺序这类优化措施。
Java内存模型规定了所有的变量都存储在主内存（Main Memory）中（此处的主内存与介绍物理硬件时的主内存名字一样，两者也可以互相类比，但此处仅是虚拟机内存的一部分）。每条线程还有自己的工作内存（Working Memory，可与前面讲的处理器高速缓存类比），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取、 赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成，线程、 主内存、 工作内存三者的交互关系如下图所示。
这里所讲的主内存、 工作内存与Java内存区域中的Java堆、 栈、 方法区等并不是同一个层次的内存划分，这两者基本上是没有关系的，如果两者一定要勉强对应起来，那从变量、 主内存、 工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。 从更低层次上说，主内存就直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机（甚至是硬件系统本身的优化措施）可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。
但是由于Java版本的不断演变，内存模型也进行了改变。
1. 原子性和实现原理
- 原子性是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其它线程干扰。
一般认为cpu的指令都是原子操作，但是我们写的代码就不一定是原子操作了。
比如说i++这个操作就不是原子操作，基本分为3个操作，读取i，进行+1，赋值给i。
假设有两个线程，当第一个线程读取i=1时，还没进行+1操作，切换到第二个线程，此时第二个线程也读取的是i=1。随后两个线程进行后续+1操作，再赋值回去以后，i不是3，而是2。显然数据出现了不一致性。再比如在32位的JVM上面去读取64位的long型数值，也不是一个原子操作。当然32位JVM读取32位整数是一个原子操作。
在了解原子操作的实现原理前，先要了解一下相关的术语，如下所示：
1.1 处理器如何实现原子操作
32位IA-32处理器使用基于对缓存加锁或总线加锁的方式来实现多处理器之间的原子操作。首先处理器会自动保证基本的内存操作的原子性。处理器保证从系统内存中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址。Pentium 6和最新的处理器能自动保证单处理器对同一个缓存行里进行16/32/64位的操作是原子的，但是复杂的内存操作处理器是不能自动保证其原子性的，比如跨总线宽度、跨多个缓存行和跨页表的访问。但是，处理器提供总线锁定和缓存锁定两个机制来保证复杂内存操作的原子性。
（1）使用总线锁保证原子性
第一个机制是通过总线锁保证原子性。如果多个处理器同时对共享变量进行读改写操作（i++就是经典的读改写操作），那么共享变量就会被多个处理器同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致。举个例子，如果i=1，我们进行两次i++操作，我们期望的结果是3，但是有可能结果是2，如下图所示：
结果是2的原因可能是多个处理器同时从各自的缓存中读取变量i，分别进行加1操作，然后分别写入系统内存中。那么，想要保证读改写共享变量的操作是原子的，就必须保证CPU1读改写共享变量的时候，CPU2不能操作缓存了该共享变量内存地址的缓存。
处理器使用总线锁就是来解决这个问题的。所谓总线锁就是使用处理器提供的一个LOCK＃信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住，那么该处理器可以独占共享内存。
（2）使用缓存锁保证原子性
第二个机制是通过缓存锁定来保证原子性。在同一时刻，我们只需保证对某个内存地址的操作是原子性即可，但总线锁定把CPU和内存之间的通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，目前处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。频繁使用的内存会缓存在处理器的L1、L2和L3高速缓存里，那么原子操作就可以直接在处理器内部缓存中进行，并不需要声明总线锁，在Pentium 6和目前的处理器中可以使用“缓存锁定”的方式来实现复杂的原子性。所谓“缓存锁定”是指内存区域如果被缓存在处理器的缓存行中，并且在Lock操作期间被锁定，那么当它执行锁操作回写到内存时，处理器不在总线上声明LOCK＃信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行的数据时，会使缓存行无效，在如图2-3所示的例子中，当CPU1修改缓存行中的i时使用了缓存锁定，那么CPU2就不能同时缓存i的缓存行。但是有两种情况下处理器不会使用缓存锁定。
第一种情况是：当操作的数据不能被缓存在处理器内部，或操作的数据跨多个缓存行（cache line）时，则处理器会调用总线锁定。
第二种情况是：有些处理器不支持缓存锁定。对于Intel 486和Pentium处理器，就算锁定的内存区域在处理器的缓存行中也会调用总线锁定。
针对以上两个机制，我们通过Intel处理器提供了很多Lock前缀的指令来实现。例如，位测试和修改指令：BTS、BTR、BTC；交换指令XADD、CMPXCHG，以及其他一些操作数和逻辑指令（如ADD、OR）等，被这些指令操作的内存区域就会加锁，导致其他处理器不能同时访问它。
1.2 Java如何实现原子操作
在Java中可以通过锁和循环CAS的方式来实现原子操作。
（1）使用循环CAS实现原子操作
JVM中的CAS操作正是利用了处理器提供的CMPXCHG指令实现的。自旋CAS实现的基本思路就是循环进行CAS操作直到成功为止，以下代码实现了一个基于CAS线程安全的计数器方法safeCount和一个非线程安全的计数器count。
private AtomicInteger atomicI = new AtomicInteger(0);
private int i = 0;
public static void main(String[] args) {
final Counter cas = new Counter();
List<Thread> ts = new ArrayList<Thread>(600);
long start = System.currentTimeMillis();
for (int j = 0; j < 100; j++) {
Thread t = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 10000; i++) {
cas.count();
cas.safeCount();
}
}
});
ts.add(t);
}
for (Thread t : ts) {
t.start();
}
// 等待所有线程执行完成
for (Thread t : ts) {
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println(cas.i);
System.out.println(cas.atomicI.get());
System.out.println(System.currentTimeMillis() - start);
}
/*** 使用CAS实现线程安全计数器 */
private void safeCount() {
for (;;) {
int i = atomicI.get();
boolean suc = atomicI.compareAndSet(i, ++i);
if (suc) {
break;
}
}
}
/*** 非线程安全计数器*/
private void count() {
i++;
}
从Java 1.5开始，JDK的并发包里提供了一些类来支持原子操作，如AtomicBoolean（用原子方式更新的boolean值）、AtomicInteger（用原子方式更新的int值）和AtomicLong（用原子方式更新的long值）。这些原子包装类还提供了有用的工具方法，比如以原子的方式将当前值自增1和自减1。
（2）CAS实现原子操作的三大问题
在Java并发包中有一些并发框架也使用了自旋CAS的方式来实现原子操作，比如LinkedTransferQueue类的Xfer方法。CAS虽然很高效地解决了原子操作，但是CAS仍然存在三大问题。ABA问题，循环时间长开销大，以及只能保证一个共享变量的原子操作。
1）ABA问题。因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A。从Java 1.5开始，JDK的Atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法的作用是首先检查当前引用是否等于预期引用，并且检查当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
public boolean compareAndSet(
V expectedReference, // 预期引用
V newReference, // 更新后的引用
int expectedStamp, // 预期标志
int newStamp, // 更新后的标志
)2）循环时间长开销大。自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令，那么效率会有一定的提升。pause指令有两个作用：第一，它可以延迟流水线执行指令（de-pipeline），使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零；第二，它可以避免在退出循环的时候因内存顺序冲突（Memory Order Violation）而引起CPU流水线被清空（CPU Pipeline Flush），从而提高CPU的执行效率。
3）只能保证一个共享变量的原子操作。当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁。还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i＝2，j=a，合并一下ij=2a，然后用CAS来操作ij。从Java 1.5开始，JDK提供了AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。
（3）使用锁机制实现原子操作
锁机制保证了只有获得锁的线程才能够操作锁定的内存区域。JVM内部实现了很多种锁机制，有偏向锁、轻量级锁和互斥锁。有意思的是除了偏向锁，JVM实现锁的方式都用了循环CAS，即当一个线程想进入同步块的时候使用循环CAS的方式来获取锁，当它退出同步块的时候使用循环CAS释放锁。
2. 有序性
- 在并发时，程序的执行可能就会出现乱序。
计算机在执行代码时，不一定会按照程序的顺序来执行。
class OrderExample {
int a = 0;
boolean flag = false;
public void writer()
{
a = 1;
flag = true;
}
public void reader()
{
if (flag)
{
int i = a +1;
}
}
}比如上述代码，两个方法分别被两个线程调用。按照常理，写线程应该先执行a=1，再执行flag=true。当读线程进行读的时候，i=2；
但是因为a=1和flag=true，并没有逻辑上的关联。所以有可能执行的顺序颠倒，有可能先执行flag=true，再执行a=1。这时当flag=true时，切换到读线程，此时a=1还没有执行，那么读线程将i=1。
当然这个不是绝对的。是有可能会发生乱序，有可能不发生。
那么为什么会发生乱序呢？这个要从cpu指令说起，Java中的代码被编译以后，最后也是转换成汇编码的。
一条指令的执行是可以分为很多步骤的，假设cpu指令分为以下几步
- 取指 IF
- 译码和取寄存器操作数 ID
- 执行或者有效地址计算 EX
- 存储器访问 MEM
- 写回 WB
假设这里有两条指令
一般来说我们会认为指令是串行执行的，先执行指令1，然后再执行指令2。假设每个步骤需要消耗1个cpu时间周期，那么执行这两个指令需要消耗10个cpu时间周期，这样做效率太低。事实上指令都是并行执行的，当然在第一条指令在执行IF的时候，第二条指令是不能进行IF的，因为指令寄存器等不能被同时占用。所以就如上图所示，两条指令是一种相对错开的方式并行执行。当指令1执行ID的时候，指令2执行IF。这样只用6个cpu时间周期就执行了两个指令，效率比较高。
按照这个思路我们来看下A=B+C的指令是如何执行的。
如图所示，ADD操作时有一个空闲（X）操作，因为当想让B和C相加的时候，在图中ADD的X操作时，C还没从内存中读取（当MEM操作完成时，C才从内存中读取。这里会有一个疑问，此时还没有回写（WB）到R2中，怎么会将R1与R1相加。那是因为在硬件电路当中，会使用一种叫“旁路”的技术直接把数据从硬件当中读取出来，所以不需要等待WB执行完才进行ADD）。所以ADD操作中会有一个空闲（X）时间。在SW操作中，因为EX指令不能和ADD的EX指令同时进行，所以也会有一个空闲（X）时间。
接下来举个稍微复杂点的例子
a=b+c
d=e-f对应的指令如下图
原因和上面的类似，这里就不分析了。我们发现，这里的X很多，浪费的时间周期很多，性能也被影响。有没有办法使X的数量减少呢？
我们希望用一些操作把X的空闲时间填充掉，因为ADD与上面的指令有数据依赖，我们希望用一些没有数据依赖的指令去填充掉这些因为数据依赖而产生的空闲时间。
我们将指令的顺序进行了改变
改变了指令顺序以后，X被消除了。总体的运行时间周期也减少了。
指令重排可以使流水线更加顺畅
当然指令重排的原则是不能破坏串行程序的语义，例如a=1,b=a+1，这种指令就不会重排了，因为重排的串行结果和原先的不同。
指令重排只是编译器或者CPU的优化一种方式，而这种优化就造成了本章一开始程序的问题。
如何解决呢？用volatile关键字，这个后面的系列会介绍到。
3. 可见性
- 可见性是指当一个线程修改了某一个共享变量的值，其他线程是否能够立即知道这个修改。
可见性问题可能有各个环节产生。比如刚刚说的指令重排也会产生可见性问题，另外在编译器的优化或者某些硬件的优化都会产生可见性问题。
比如某个线程将一个共享值优化到了内存中，而另一个线程将这个共享值优化到了缓存中，当修改内存中值的时候，缓存中的值是不知道这个修改的。
比如有些硬件优化，程序在对同一个地址进行多次写时，它会认为是没有必要的，只保留最后一次写，那么之前写的数据在其他线程中就不可见了。
总之，可见性的问题大多都源于优化。
接下来看一个Java虚拟机层面产生的可见性问题
package edu.hushi.jvm;
/**
*
* @author -10
*
*/
public class VisibilityTest extends Thread {
private boolean stop;
public void run() {
int i = 0;
while(!stop) {
i++;
}
System.out.println("finish loop,i=" + i);
}
public void stopIt() {
stop = true;
}
public boolean getStop(){
return stop;
}
public static void main(String[] args) throws Exception {
VisibilityTest v = new VisibilityTest();
v.start();
Thread.sleep(1000);
v.stopIt();
Thread.sleep(2000);
System.out.println("finish main");
System.out.println(v.getStop());
}
}代码很简单，v线程一直不断的在while循环中i++，直到主线程调用stop方法，改变了v线程中的stop变量的值使循环停止。
看似简单的代码运行时就会出现问题。这个程序在 client 模式下是能停止线程做自增操作的，但是在 server 模式先将是无限循环。（server模式下JVM优化更多）
64位的系统上面大多都是server模式，在server模式下运行：
finish main
true只会打印出这两句话，而不会打印出finish loop。可是能够发现stop的值已经是true了。
将程序还原为汇编代码
这里只截取了一部分汇编代码，红色部分为循环部分，可以清楚得看到只有在0x0193bf9d才进行了stop的验证，而红色部分并没有取stop的值，所以才进行了无限循环。
这是JVM优化后的结果。如何避免呢？和指令重排一样，用volatile关键字。
如果加入了volatile，再还原为汇编代码就会发现，每次循环都会get一下stop的值。
接下来看一些在“Java语言规范”中的示例
上图说明了指令重排将会导致结果不同。
上图使r5=r2的原因是，r2=r1.x，r5=r1.x，在编译时直接将其优化成r5=r2。最后导致结果不同。
4. Happen-Before
从JDK 5开始，Java使用新的JSR-133内存模型。JSR-133使用happens-before的概念来阐述操作之间的内存可见性。在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须要存在happens-before关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。
happens-before规则有：
- 程序顺序原则：一个线程内保证语义的串行性
- volatile规则：volatile变量的写，先发生于读，这保证了volatile变量的可见性
- 锁规则：解锁（unlock）必然发生在随后的加锁（lock）前
- 传递性：A先于B，B先于C，那么A必然先于C
- 线程的start()方法先于它的每一个动作
- 线程的所有操作先于线程的终结（Thread.join()）
- 线程的中断（interrupt()）先于被中断线程的代码
- 对象的构造函数执行结束先于finalize()方法
这些原则保证了重排的语义是一致的。注意两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visible to and ordered before the second）。