浅谈Java内存模型

       当多个线程访问同一个对象时，如果不考虑这些线程在运行时环境下的调度和交替运行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获取正确的结果，那这个对象是线程安全的。而出现线程安全问题一般是因为主内存和工作内存数据不一致性和重排序导致的，解决线程安全问题最重要的就是理解这两个问题是怎么来的。那么理解它们的核心在于理解java内存模式。

       在多线程条件下，多个线程肯定会相互协作完成一件事。一般来说，就会涉及到多个线程间相互通信告知彼此的状态以及当前的执行结果等。另外，为了性能优化，还会涉及到编译器指令重排序和处理器指令重排序。下面我们来聊聊这些知识。

一、Java内存模型

       在并发编程中，主要解决两个问题：1、线程之间如何通信；2、线程之间如何完成同步。通信是指线程之间以何种机制来交换信息，而线程之间交换信息主要由两种：共享内存和消息传递。Java内存模式是共享内存的并发模型，线程之间主要通过读-写共享变量来完成隐式通信。

        Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的细节。此处的变量与Java编程中所说的变量有所区别，它是共享变量，包括了实例变量、静态字段和构造数组对象的元素，但不包括局部变量、方法参数和异常处理器参数，因为后者是线程私有的，不会被共享，自然不会存在竞争问题。为了获得较好的执行效能，Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器进行调整代码执行顺序这类优化措施。

       我们知道CPU的处理数据和主存的读写数据不是一个量级的，为了平衡这种巨大的差距，每个CPU都会有缓存。因此共享变量会先放在主存中，每个线程都有属于自己的工作内存，并且会把位于主存中的共享变量拷贝到自己的工作内存，之后的读写操作均使用位于工作内存的变量副本，并在某个时刻，将工作内存的变量副本写回主存中去。JMM就从抽象层次定义了这种方式，并且JMM决定了一个线程对共享变量的写入何时对其他线程是可见的。

如图为JMM抽象示意图，线程A和线程B之间要完成通信的话，要经历如下两步：

1）线程A从主内存中将共享变量读入线程A的工作内存后并进行操作，之后将数据重新写回到主内存中

2）线程B从主存中读取最新的共享变量

       从横向看，线程A和线程B就好像通过共享变量进行隐式通信。这其中有一个很有意思的问题，如果线程A更新后的数据并没有及时写回主存，而此时线程B读到的是过期的数据，那就出现了“脏读”现象。可以通过同步机制来解决或通过volatile关键字使得每次volatile变量都能够强制刷新到主存，从而对每个线程都是可见的。

二、线程、主内存、工作内存的关系        

       Java内存模型规定了所有变量都存储在主内存（Main Memory）中。每条线程都有自己的工作内存（Working Memory），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。线程、主内存、工作内存三者的关系如下。

                                       

        这里所讲的主内存、工作内存与Java内存区域中的Java堆、栈、方法区等并不是同一个层次的内存划分，这两者基本上没有什么关系。如果两者一定要勉强对应起来，那么从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。从更低层次上来说，主内存就直接对应于物理硬件的内存，而为了获取更好地运行速度，虚拟机可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问的读写是工作内存。

三、重排序

       一个好的内存模式实际上会放松对处理器和编译器规则的束缚，也就是说软件技术和硬件技术都为同一个目标而奋斗：在不改变程序执行结果的前提下，尽可能提高并行读。JMM对底层尽量减少约束，使其能够发挥自身优势。因此，在执行程序时，为了提高性能，编译器和处理器常常会对指令进行重排序。一般重排序可分为如下三种：

1. 编译器优化重排序：编译器在不改变单线程程序语意的前提下，可以重新安排语句的执行顺序
2. 指令级并发重排序：现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序
3. 内存系统重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是乱序执行的

        如上图所示，1属于编译器重排序，2和3属于处理器重排序，这些重排序会导致线程安全的问题。针对编译器重排序，JMM的编译器重排序规则会禁止一些特定类型的编译器重排序；针对处理器重排序，编译器在生成指令序列的时候，会通过插入内存屏障指令来禁止某些特殊的处理器重排序

      什么是数据依赖？看下面代码：

int a = 3;    //A
int b = 5;    //B
int c = a * b;//C

       由于A、B之间没有任何关系，对最终结果也不会存在关系，它们之间执行顺序可以重排序。因此执行顺序可以是：A->B->C或B->A->C，最终的执行结果都是15，即A和B之间没有数据依赖。

       数据依赖性的具体定义为：如果两个操作访问同一个变量，且这两个操作有一个为写操作，此时这两个操作就存在数据依赖关系。这里存在三种情况：1）读后写；2）写后写；3）写后读，这三种操作都存在数据依赖性。如果重排序对最终执行结果造成影响，那么编译器和处理器在重排序的时候，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行数据。

四、as-if-serial规则

       as-if-serial语义的意思是：不管怎么重排序，（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。as-if-serial语义把单线程程序保护了起来，遵守as-if-serial语义的编译器，runtime和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。比如上面计算两个数的乘积的代码，在单线程中，会让人感觉代码时一行一行顺序的执行，实际上A、B两行不存在数据依赖性，可能会进行重排序，即A、B不是顺序执行的。as-if-serial语义使程序员不必担心单线程中重排序的问题干扰他们，也无需担心内存可见性问题。

五、happens-before规则

        happens-before的概念最初由Leslie Lamport在其一篇影响深远的论文（《Time，Clocks and the Ordering of Events in a Distributed System》）中提出。JSR-133使用happens-before的概念来指定两个操作之间的执行顺序。由于这两个操作可以在一个线程之内，也可以是在不同线程之间。因此，JMM可以通过happens-before关系向程序员提供跨线程的内存可见性保证（如果A线程的写操作a与B线程的读操作b之间存在happens-before关系，尽管a操作和b操作在不同的线程中执行，但JMM向程序员保证a操作将对b操作可见）。

5.1happens-before定义

happens-before具体的定义为：

1）如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。

2）两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。

      上面的1）是JMM对程序员的承诺。从程序员的角度来说，可以这样理解happens-before关系：如果A happens-before B，那么Java内存模型将向程序员保证——A操作的结果将对B可见，且A的执行顺序排在B之前。注意，这只是Java内存模型向程序员做出的保证！2）是JMM对编译器和处理器重排序的约束原则。正如前面所言，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。JMM这么做的原因是：程序员对于这两个操作是否真的被重排序并不关心，程序员关心的是程序执行时的语义不能被改变（即执行结果不能被改变）。因此，happens-before关系本质上和as-if-serial语义是一回事。

5.2happens-before具体规则

    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()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
• join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
• 程序中断规则：对线程interrupted()方法的调用先行于被中断线程的代码检测到中断时间的发生。
• 对象finalize规则：一个对象的初始化完成（构造函数执行结束）先行于发生它的finalize()方法的开始。

      依旧以上面计算两个数乘积进行描述。利用程序顺序规则（规则1）存在三个happens-before关系：1. A happens-before B；2. B happens-before C；3. A happens-before C。这里的第三个关系是利用传递性进行推论的。A happens-before B，定义1要求A执行结果对B可见，并且A操作的执行顺序在B操作之前，但与此同时利用定义中的第二条，A、B操作彼此不存在数据依赖性，两个操作的执行顺序对最终结果都不会产生影响，在不改变最终结果的前提下，允许A、B两个操作重排序，即happens-before关系并不代表了最终的执行顺序。

六、as-if-serial 和 happens-before 比较

• as-if-serial语义保证单线程内程序的执行结果不被改变，happens-before关系保证正确同步的多线程程序的执行结果不被改变。
• as-if-serial语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。happens-before关系给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按happens-before指定的顺序来执行的。
• as-if-serial语义和happens-before这么做的目的，都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

七、总结

7.1JMM的设计

       JMM是语言级的内存模型，在我的理解中JMM处于中间层，包含了两个方面：（1）内存模型；（2）重排序以及happens-before规则。同时，为了禁止特定类型的重排序会对编译器和处理器指令序列加以控制。而上层会有基于JMM的关键字和J.U.C包下的一些具体类用来方便程序员能够迅速高效率的进行并发编程。

       另外还要一个特别有意思的事情就是关于重排序问题，更简单的说，重排序可以分为两类：1）会改变程序执行结果的重排序；2）不会改变程序执行结果的重排序。JMM对这两种不同性质的重排序，采取了不同的策略：1）对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序；2）对于不会改变程序执行结果的重排序，JMM对编译器和处理器不做要求（JMM允许这种重排序）。

       JMM的设计图如下：

       从图可以看出：JMM向程序员提供的happens-before规则能满足程序员的需求。JMM的happens-before规则不但简单易懂，而且也向程序员提供了足够强的内存可见性保证（有些内存可见性保证其实并不一定真实存在，比如上面的A happens-before B）。

      JMM对编译器和处理器的束缚已经尽可能少。从上面的分析可以看出，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。例如，如果编译器经过细致的分析后，认定一个锁只会被单个线程访问，那么这个锁可以被消除。再如，如果编译器经过细致的分析后，认定一个volatile变量只会被单个线程访问，那么编译器可以把这个volatile变量当作一个普通变量来对待。这些优化既不会改变程序的执行结果，又能提高程序的执行效率。

7.2happens-before与JMM的关系

       一个happens-before规则对应于一个或多个编译器和处理器重排序规则。对于Java程序员来说，happens-before规则简单易懂，它避免Java程序员为了理解JMM提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现方法。