什么是java内存模型

缓存一致性问题

在现代计算机中，因为CPU的运算速度远大于内存的读写速度，因此为了不让CPU在计算的时候因为实时读取内存数据而影响运算速度，CPU会加入一层缓存，在运算之前缓存内存的数据，CPU运算的时候操作的是缓存里的数据，运算完成后再同步回内存。这样虽然能够加速程序的运行速度，但是却带来了一个问题：缓存一致性问题。每个处理器都有自己的缓存，而它们又共享同一内存，当有多个处理器的操作涉及同一块内存区域的时候，他们的缓存可能会因为运算而导致不一致，在这种情况下，同步回内存的数据以谁的为准呢？为了解决一致性问题，需要各个处理器访问缓存的时候都遵循一些协议，在读写时要根据协议来进行操作，这类协议有MSI、MESI、MOSI、Synapse、Firefly及Dragon Protocol等。

而Java中的线程在执行的时候，为了提高速度，也会把线程中使用到的公共变量缓存到线程本地备份，线程执行时实际操作的是线程本地备份，运算完成后再同步到公共变量。Java这种机制可以看成是硬件缓存之上的一种抽象，在Java实现于特定硬件的时候，就可以把公共变量保存到内存，把线程本地备份保存到CPU缓存从而提升运行速度。Java的这种缓存机制和硬件的缓存机制一样，存在缓存一致性问题。Java的缓存一致性问题怎么解决，参考处理器缓存一致性的解决方案，我们认为应该也需要某种协议。

重排序问题

编译器在编译的时候，允许重排序指令以优化运行速度。CPU在执行指令的时候，为了使处理器内部运算单元能被充分利用，也可以对指令进行乱序执行。

在编译器和CPU进行重排序的时候，要遵循“as-if-serial”原则，也就是要保证程序单线程执行的时候，重排序之后程序的运行结果必须和重排序前程序的运行结果一致。这里注意“as-if-serial”原则只保证单线程的执行结果不变，不保证多线程执行的结果不变。那么如何保证多线程程序的正确运行？显然需要某种协议来限定多线程执行时要满足的规则。

某种协议

要解决缓存一致性问题需要某种协议，要解决重排序问题也需要某种协议。于是java定义了一种协议，一揽子解决了这两个问题，这个协议就是Java内存模型(JMM)。

java内存模型的定义

既然我们知道了JMM是一个协议，那么就让我们快点给出JMM的定义吧。对不起，笔者在这里无法给出JMM的正式定义。而且笔者目前找到的资料里，给出了JMM正式定义的只有java的官方文档JSR133（JSR133是随jdk1.5发布的新的java内存模型，对之前的java内存模型进行了修正，JSR133中定义的内存模型一直沿用到现在(jdk8)），为什么众多讲JMM的博客、文章都不给出JMM的正式定义呢？因为JMM的正式定义太复杂了。我可以展示JMM正式定义的一部分大家来感受一下：

看不懂的同学先别着急，这个定义确实是难懂，JSR133里面也说JMM的正式定义是一个学术定义，笔者也没有看这个正式定义。那么说了半天，原来笔者自己也搞不懂JMM是什么吗？非也非也~虽然JSR133里这个学术定义晦涩难懂，但是JSR133里提供了一个“通俗版”的JMM定义，“通俗版”的定义和正式版略有歧义，不过作为java开发者来说，以"通俗版"定义为准则开发出来的多线程程序，保证是实现正确的。所谓的“通俗版”定义，就是先行发生原则(happens-before原则)：

程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
监视器锁规则：对一个锁的解锁，happens-before与随后对这个锁的加锁。
volatile变量规则：对一个volatile变量的写，happens-before于任意后续对这个volatile变量的读。
传递性：如果A happens-before B，且 B happens-before C，则A happens-before C。
start()规则：如果线程A执行ThreadB.start()，那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

先行发生原则规定了在一些情况下多线程程序必须表现出来的执行顺序性，当我们判断一个多线程程序是否能正确执行时，可以根据这些原则来判断。

JSR133中定义的并发关键字的内存语义

为了实现JSR133中定义的新的内存模型，JSR133中增强了volatile和final关键字的语义。下面让我们看一下一些并发关键字的内存语义。

volatile的内存语义

volatile在JSR133中增强了内存语义：

当写一个volatile内存变量的时候，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。

当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。

如果把volatile写和读两个步骤综合起来看的话，在读线程B读一个volatile变量后，写线程A在写这个volatile变量之前所有可见的共享变量的值都将立即变得对读线程B可见。

锁的内存语义

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。

当线程获取锁时，JMM会把该线程中对应的本地内存置为无效。从而使被监视器保护的临界区代码必须从主内存中读取共享变量。

可以看出，锁释放与volatile写有相同的内存语义；锁获取与volatile读有相同的内存语义。

final的内存语义

在构造函数中对一个final域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。

初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序。

final的内存语义无非是要保证在多线程的情况下，也让final变量确保在初始化后就不能被修改。

参考资料：

《深入理解Java虚拟机 JVM高级特性与最佳实践》第12、13章

《java并发编程的艺术》第3章

《JSR-133 JavaTM Memory Model and Thread Specification》

http://tutorials.jenkov.com/java-concurrency/java-memory-model.html

https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html