本博客系列是学习并发编程过程中的记录总结。由于文章比较多，写的时间也比较散，所以我整理了个目录贴（传送门），方便查阅。

并发编程系列博客传送门

前言#

在网上看了很多文章，也看了好几本书中关于JMM的介绍，我发现JMM确实是Java中比较难以理解的概念。网上很多文章中关于JMM的介绍要么是照搬了一些书上的内容，要么就干脆介绍的就是错的。本文试着用比较简洁的语言介绍清楚JMM到底是什么，解决了Java编程中的哪些问题。不求深入，但求让读者看地清楚，看完之后能对JMM有个比较直观的认识。

本文是笔者在总结了网上的多篇文章之后加上自己的理解整理出来的，内容上可能和JMM标准存在偏差，有问题还望留言指出。

什么是JMM#

JMM是一个规范，我从JSR113标准中摘录了一段对JMM的简单介绍：

JavaTM virtual machines support multiple threads of execution. Threads are represented by the Thread class. The only way for a user to create a thread is to create an object of this class; each thread is associated with such an object. A thread will start when the start() method is invoked on the corresponding Thread object. The behavior of threads, particularly when not correctly synchronized, can be confusing and counterintuitive. This specification describes the semantics of multithreaded programs written in the JavaTM programming language; it includes rules for which values may be seen by a read of shared memory that is updated by multiple threads. As the specification is similar to the memory models for different hardware architectures, these semantics are referred to as the JavaTM memory model. These semantics do not describe how a multithreaded program should be executed. Rather, they describe the behaviors that multithreaded programs are allowed to exhibit. Any execution strategy that generates only allowed behaviors is an acceptable execution strategy.

上面的英文简要翻译如下：

Java虚拟机支持多线程执行。在Java中Thread类代表线程，创建一个线程的唯一方法就是创建一个Thread类的实例对象。当调用了对象的start方法后，相应的线程将会执行。

线程的行为有时会令人困惑而且和我们的直觉相左，特别是在线程没有正确同步的情况下。本规范描述了JVM平台上多线程程序的语义（含义），具体包括一个线程对共享变量的写入何时能被其他线程“看到”。由于本规范和不同硬件平台上的内存模型相似，所以将本规范命名为Java内存模型。

从上面这段英文介绍中我们可以得到关于JMM的简要信息：

• JMM是一个和多线程相关的规范；
• JMM描述了JVM平台上多线程程序的语义（含义），具体包括一个线程对共享变量的写入何时能被其他线程“看到”。

但是只看上面对于JMM的简单解释，我相信大多数人还是会很晕，对JMM具体是什么还是很模糊。

不过我在上面的这段介绍中又发现了一段对JMM介绍的关键信息：

As the specification is similar to the memory models for different hardware architectures, these semantics are referred to as the JavaTM memory model. (JMM和硬件平台上的内存模型相似)

上面的介绍中提到JMM和硬件平台上的内存模型相似，那么我们就先看看硬件平台上的内存模型究竟是什么？

内存模型#

有点计算机基础的同学都应该知道，程序执行的时候其实就是一条条指令在CPU上执行的过程，而指令的执行又势必会涉及到数据的读取和写入。说到数据，就又不得不提到一个重要的硬件:内存。在计算机中，内存是数据的“收集站”，数据从键盘、网络、文件也有可能是一些传感器设备进入到内存，然后CPU从内存中读取这些数据并对这些数据进行“加工”后再写回到内存。

上面整个过程看起来很完美，但是就像人与人之间是有差别的一样，硬件和硬件之间也存在差别。CPU的运行速度就和尤塞恩·博尔特的速度一样（飞一样的速度），而内存的运行速度和CPU相比就像我的跑步速度和博尔特比一样，根本不是一个数量级的。CPU和内存运行速度的差距会导致整个系统性能的下降，因为CPU每次读写数据都要等待内存。（木桶理论在计算机中的体现）

但是这个问题根本就难不倒我们伟大的硬件工程师们。“聪明”的工程师们在CPU中加入了一层CPU高速缓存层。这个缓存的运算速度和CPU相当，当指令在CPU上运行的时候，会先将运算需要的数据从内存中复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。（现代CPU其实是有多级缓存的，但是为了简单起见就没介绍了，因为我觉得这里不介绍CPU多级缓存不会影响对JMM的理解）

世界好像又重归于平静，一切又显得那么美好。但是其实问题才刚刚开始。

原子性问题#

上面提到CPU进行运算时需要将共享变量先加载到CPU缓存中，运算结束后再将最新数据写回共享内存。这种看起来完美的工作方式其实存在一个问题，下面我们就以上面的图片为列子，说下这个问题。

假如现在系统环境是 单核CPU+多线程工作模式，共享变量初始值是1，线程1和线程2分别对这个共享变量进行加一操作，理论上这个共享变量最后的值是3。我们看看程序的执行行为是否会和我们预期的一致。

线程对一个共享变量加一的过程需要分三步进行：

Copy
step1: