Java内存模型以及原子性、可见性与有序性

线程安全高频面试题：高并发如何保证线程安全，谈谈你对高并发的理解。

其实java的多线程并发问题最终都会反映在java的内存模型上，高并发情况下需要保证线程安全，所谓线程安全无非是要控制多个线程对某个公共资源的有序访问或修改。在回答高并发的问题时，主要从java内存模型与线程同步两方面回答即可。

线程安全就是说多线程访问同一代码，不会产生不确定的结果。

如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他变量的值也和预期的是一样的，就是线程安全的。

Servlet不是线程安全的。当两个或多个线程同时访问同一个Servlet时，可能会发生多个线程同时访问同一资源的情况，数据可能会变得不一致。线程安全问题主要是由实例变量造成的，因此在Servlet中应避免使用实例变量。尽量将实例变量改为方法中的局部变量，因为局部变量存在于虚拟机栈中，归属于线程所有，不存在多线程共享的问题。

要认识java线程安全，必须了解两个主要的点：java的内存模型与java的线程同步机制。java的线程同步机制主要是依靠加锁实现的，如synchronized锁和ReentrantLock锁，这两种加锁的方式在后续文章中进行分析，此处分析Java的内存模型。

1、计算机的内存模型

“让计算机并发执行若干个运算任务”与“更充分地利用计算机处理器的效能”之间的因果关系，看起来顺理成章，实际上它们之间的关系并没有想象中的那么简单，其中一个重要的复杂性来源是绝大多数的运算任务都不可能只靠处理器“计算”就能完成，处理器至少要与内存交互，如读取运算数据、存储运算结果等，这个I/O操作是很难消除的（无法仅靠寄存器来完成所有运算任务）。由于计算机的存储设备与处理器的运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存（Cache）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为计算机系统带来更高的复杂度，因为它引入了一个新的问题：缓存一致性（Cache Coherence）。在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存（Main Memory），当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为准呢？为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作，这类协议有MSI、MESI（Illinois Protocol）、MOSI、Synapse、Firefly及Dragon Protocol等。在本文中将会多次提到的“内存模型”一词，可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机器可以拥有不一样的内存模型，而Java虚拟机也有自己的内存模型，并且这里介绍的内存访问操作与硬件的缓存访问操作具有很高的可比性。

除了增加高速缓存之外，为了使得处理器内部的运算单元能尽量被充分利用，处理器可能会对输入代码进行乱序执行（Out-Of-Order Execution）优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致，因此，如果存在一个计算任务依赖另外一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类似，Java虚拟机的即时编译器中也有类似的指令重排序（Instruction Reorder）优化。

2、Java内存模型

为了保证并发编程中可以满足原子性、可见性及有序性，有一个重要的概念，那就是内存模型。为了保证共享内存的正确性（可见性、有序性、原子性），内存模型定义了共享内存系统中多线程程序读写操作行为的规范。通过这些对内存读写操作的规范，从而保证指令执行的正确性。它与处理器、缓存、并发和编译器有关。它解决了 CPU 多级缓存、处理器优化、指令重排等导致的内存访问问题，保证了并发场景下的一致性、原子性和有序性。

内存模型解决并发问题主要采用两种方式：限制处理器优化和使用内存屏障。

定义Java内存模型并非一件容易的事情，这个模型必须定义得足够严谨，才能让Java的并发内存访问操作不会产生歧义；但是，也必须定义得足够宽松，使得虚拟机的实现有足够的自由空间去利用硬件的各种特性（寄存器、高速缓存和指令集中某些特有的指令）来获取更好的执行速度。经过长时间的验证和修补，在JDK 1.5（实现了JSR-133：Java Memory Model and Thread Specification Revision（Java内存模型和线程规范修订），Java内存模型已经成熟和完善起来了。

2.1、主内存与工作内存

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

ps:如果局部变量是一个reference类型，它引用的对象在Java堆中可被各个线程共享，但是reference本身在Java栈的局部变量表中，它是线程私有的，不会被共享，自然就不会存在竞争问题。

Java内存模型规定了所有的变量都存储在主内存（Main Memory）中（此处的主内存与上面介绍物理硬件时的主内存名字一样，两者也可以互相类比，但此处仅是虚拟机内存的一部分）。每条线程还有自己的工作内存（Working Memory，可与前面讲的处理器高速缓存类比），线程的工作内存中保存了被该线程使用到的从主内存复制的变量副本，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。

根据Java虚拟机规范的规定，volatile变量也需要从主内存复制到工作内存进行操作，但是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般，因此这里的描述对于volatile也并不存在例外。

线程、主内存、工作内存三者的交互关系如图所示。

主内存、工作内存与Java内存区域中的Java堆、栈、方法区等并不是同一个层次的内存划分，这两者基本上是没有关系的，如果两者一定要勉强对应起来，那从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分，除了实例数据，Java堆还保存了对象的其他信息，对于HotSpot虚拟机来讲，有Mark Word（存储对象哈希码、GC标志、GC年龄、同步锁等信息）、Class Point（指向存储类型元数据的指针）及一些用于字节对齐补白的填充数据（如果实例数据刚好满足8字节对齐的话，则可以不存在补白）。而工作内存则对应于虚拟机栈中的部分区域。从更低层次上说，主内存就直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机（甚至是硬件系统本身的优化措施）可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。

根据JMM的设计，系统存在一个主内存(Main Memory)，Java中所有实例变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存由缓存和堆栈两部分组成，缓存中保存的是主存中变量的拷贝，缓存可能并不总和主存同步，也就是缓存中变量的修改可能没有立刻写到主存中；堆栈中保存的是线程的局部变量(save in stack, not in heap)，线程之间无法相互直接访问堆栈中的变量。

2.2、内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java内存模型中定义了以下8种操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的（对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许有例外）。

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内存模型还规定了在执行上述8种基本操作时必须满足如下规则：

1、不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现。

2、不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。

3、不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。

4、一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说，就是对一个变量实施use、store操作之前，必须先执行过了load和assign操作。

5、一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。

6、如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。

7、如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定住的变量。

8、对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。

这8种内存访问操作及上述规则限定，再加上对volatile的一些特殊规定，就已经完全确定了Java程序中哪些内存访问操作在并发下是安全的。由于这种定义相当严谨但又十分烦琐，实践起来很麻烦，所以将介绍这种定义的一个等效判断原则-先行发生原则(happen-before)，用来确定一个访问在并发环境下是否安全。

2.3、先行发生原则(happen-before)

如果Java内存模型中所有的有序性都仅仅靠volatile和synchronized来完成，那么有一些操作将会变得很烦琐，但是我们在编写Java并发代码的时候并没有感觉到这一点，这是因为Java语言中有一个“先行发生”（happens-before）的原则。这个原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则一揽子地解决并发环境下两个操作之间是否可能存在冲突的所有问题。

下面是Java内存模型下一些“天然的”先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们随意地进行重排序。

1、程序次序规则（Program Order Rule）：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说，应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。

2、管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，而“后面”是指时间上的先后顺序。

3、volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。

4、线程启动规则（Thread Start Rule）：Thread对象的start方法先行发生于此线程的每一个动作。

5、线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。

6、线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。

7、对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始。

8、传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

Java语言无须任何同步手段保障就能成立的先行发生规则就只有上面这些了。

2.4、原子性、可见性与有序性

Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的，我们逐个来看一下哪些操作实现了这3个特性。

原子性（Atomicity）：原子性是指在一个操作中cpu不可以在中途暂停然后再调度，即不能中断操作，要么执行完成，要么就不执行。如果一个操作是原子性的，那么多线程并发的情况下，就不会得到意想不到的结果。由Java内存模型来直接保证的原子性变量操作包括read、load、use、assign、store和write，对基本数据类型的读取和赋值操作是原子性操作，所谓原子性操作就是指这些操作是单一不可分割的，是不可中断的，要么执行，要么不执行（例外就是long和double的非原子性协定，只要知道这件事情就可以了，无须太过在意这些几乎不会发生的例外情况）。如果应用场景需要一个更大范围的原子性保证（经常会遇到），Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

看下面一个例子：

请分析以下哪些操作是原子性操作：

1  x = 10; //语句1

2  y = x; //语句2

3  x++; //语句3

4  x = x + 1; //语句4

乍一看，有些朋友可能会说上面的4个语句中的操作都是原子性操作。其实只有语句1是原子性操作，其他三个语句都不是原子性操作。

通过反编译，看一下这四条语句在底层对应的指令：

x = 10;
mov dword ptr [x],10

y = x;
mov eax,dword ptr [x]
mov dword ptr [y],eax
 
x++;
mov eax,dword ptr [x]
add eax,1
mov dword ptr [x],eax
 
X=x+1;
mov eax,dword ptr [x]
add eax,1
mov dword ptr [x],eax

语句1是直接将数值10赋值给x，也就是说线程执行这个语句时会直接将数值10写入到工作内存中。

语句2实际上包含2个操作：CPU先去内存中读取x的值到寄存器中，再把该值写入内存中y变量。虽然“读取x的值”以及“将x的值写入内存”这2个操作都是原子性操作，但是合起来就不是原子性操作了。但是它需不需要同步呢？其实问题的关键在于程序的上下文。

例如有两个线程，线程1要执行{x = 1; y = x;}，线程2要执行{x = 2; x = 3;}，假设它们按如下时间顺序执行：

time	Thread 1	Thread 2
0	store x, 1
1		store x, 2
2	load eax, x
3		store x, 3
4	store y, eax

那么最终线程1中y的值为2，而不是它原本想要的1。我们需要加上相应的同步语句确保x = 2不会在线程1的两条语句之间发生。x = 3那条语句尽管在load x和store y之间执行，但是却不影响y=x这条语句本身的语义。所以你可以说y=x需要同步，也可以说y=x不需要同步，看你怎么理解题意了。但是在多线程中，为了确保y的值一定是想要的结果，就必须使用同步。

x++和 x = x+1包括3个操作：CPU从内存中读x的值到寄存器中，对寄存器中的x加1，再把新值写回x所处的内存地址(见上面的反编译代码)。

例如有两个线程，同时执行x++这段代码，它们在底层可能会按照如下指令顺序执行（注意读x和写回x是原子操作，两个线程不能同时执行）：

time	Thread 1	Thread 2
0	load eax, x
1		load eax, x
2	add eax, 1	add eax, 1
3	store x, eax
4		store x, eax

我们会发现最终x的值会是1而不是2，因为Thread 1的结果被覆盖掉了。这种情况下我们就需要对x++这样的操作加锁以保证同步。

所以上面4个语句只有语句1的操作具备原子性。

也就是说，只有基本数据类型的读取、赋值（而且必须是将字面量赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。

从上面可以看出，Java内存模型只保证了基本数据类型的读取和赋值是原子性操作，如果要实现更大范围操作的原子性，可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

对于long和double型变量的特殊规则

Java内存模型要求lock、read、load、use、assign、store、write、unlock这8个操作都具有原子性，但是对于64位的数据类型（long和double），在模型中特别定义了一条相对宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的read、load、store和write这4个操作的原子性，这点就是所谓的long和double的非原子性协定（Nonatomic Treatment ofdouble and long Variables）。

如果有多个线程共享一个并未声明为volatile的long或double类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了“半个变量”的数值。不过这种读取到“半个变量”的情况非常罕见（在目前商用Java虚拟机中不会出现），因为Java内存模型虽然允许虚拟机不把long和double变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为具有原子性的操作，而且还“强烈建议”虚拟机这样实现。在实际开发中，目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待，因此我们在编写代码时一般不需要把用到的long和double变量专门声明为volatile。

可见性（Visibility）：可见性是指当一个线程修改了共享变量的值，其他线程在使用该变量时能够得知这个修改。

volatile可见性的底层原理是通过缓存锁或总线锁(对于跨越多个缓存行的数据需要使用总线锁)和缓存一致性协议实现的。对于声明了volatile的变量进行写操作时，JVM就会向处理器发送一条lock前缀的指令(lock; addl $0,0(%%esp))，该指令会触发缓存锁或总线锁，把这个变量所在缓存行的数据写回到系统内存，再根据MESI的缓存一致性协议，来保证多核CPU下的各个高速缓存中的数据的一致性，从而解决了多个线程共享volatile变量的可见性问题。

在Intel X86的CPU中使用的缓存一致性协议是MESI，MESI是Modified(修改)、Exclusive(互斥)、Shared(共享)、Invalid(无效)四个单词首字母的缩写。CPU是以缓存行(大小是64byte)为单位先将内存中的数据读取到缓存中，进而读取到寄存器中，并放到ALU(Arithmetic Logic Unit，算术逻辑运算单元)中执行。缓存行具有四种状态Modified(修改)、Exclusive(互斥)、Shared(共享)、Invalid(无效)，可用两个二进制位表示。

Modified表示缓存行数据在CPU的缓存中被修改了，与主存中的数据不一致，只存在自己的缓存中，该状态表示缓存行有效。Modified状态的缓存行必须时刻监听所有其他CPU试图读该缓存行相对旧主存的操作，其他CPU的这种操作必须在本CPU缓存将该缓存行写回主存并将状态变成S（共享）状态之前被延迟执行。

Exclusive表示缓存行数据是CPU独占的，与主存中数据是一致的，只存在自己的缓存中，该状态表示缓存行有效。Exclusive状态的缓存行也必须监听其它CPU缓存读主存中该缓存行的操作，一旦有这种操作，该缓存行需要变成S（共享）状态。也就是说如果有其他CPU想要读取主存中相同的缓存行到缓存中，这个CPU中缓存行的状态就要从Exclusive修改为Shared。

Shared表示缓存行数据是多个CPU共享的，与主存中的数据是一致的，数据存在多个CPU缓存中，该状态表示缓存行有效。Shared状态的缓存行也必须监听其它CPU缓存使该缓存行无效(例如其他CPU修改该缓存行数据)或者独享该缓存行的请求，并将该缓存行变成无效（Invalid）。

Invalid表示缓存行数据在CPU中已经失效了，如果要使用该缓存行中的数据，需要重新从主存中读取，该状态表示缓存行无效。

状态	描述	监听任务
M 修改 (Modified)	该Cache line有效，数据被修改了，和内存中的数据不一致，数据只存在于本Cache中。	缓存行必须时刻监听所有试图读该缓存行相对旧主存的操作，这种操作必须在缓存将该缓存行写回主存并将状态变成S（共享）状态之前被延迟执行。
E 独享、互斥 (Exclusive)	该Cache line有效，数据和内存中的数据一致，数据只存在于本Cache中。	缓存行也必须监听其它缓存读主存中该缓存行的操作，一旦有这种操作，该缓存行需要变成S（共享）状态。
S 共享 (Shared)	该Cache line有效，数据和内存中的数据一致，数据存在于很多Cache中。	缓存行也必须监听其它缓存使该缓存行无效或者独享该缓存行的请求，并将该缓存行变成无效（Invalid）。
I 无效 (Invalid)	该Cache line无效。	无

另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

有序性（Ordering）：有序性是指CPU按照代码被编译后的指令顺序执行。但是CPU为了提高效率和利用率，可能会对指令进行重排序优化，在不影响最终结果的情况下，可能会对一些语句的执行顺序进行调整（乱序优化：CPU与其等待阻塞指令（如等待缓存刷入）完成，不如先去执行其他指令）。重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。指令重排序必须要遵循的原则是：不影响代码执行的最终结果。编译器和处理器不会改变存在数据依赖关系（仅仅是针对单个处理器中执行的指令和操作）的两个操作的执行顺序，不管怎么重排序，单线程程序的执行结果不会改变，编译器、处理器都必须遵守这个原则。

volatile通过内存屏障来禁止指令重排序，底层原理依然是通过lock addl前缀的指令实现的。在java代码中使用volatile修饰变量，在ByteCode字节码层面就是加了一个ACC_VOLATILE指令，在JVM规范层面通过使用内存屏障实现(在volatile写操作前后分别使用StoreStoreBarrier指令和StoreLoadBarrier指令，在volatile读操作前后分别使用LoadLoadBarrier和LoadStoreBarrier指令)，在具体JVM(Hotspot是一种JVM)实现层面是通过lock; addl $0,0(%%esp)汇编指令实现的。StoreLoadBarrier指令表示立即将缓存数据保存到内存中的store操作完成之后，才能执行该指令之后的将数据从内存装载到缓存中的load操作。也就是说StoreLoadBarrier指令保证了对volatile变量的写操作完成之后才能进行读操作。

观察加入volatile和未加入volatile关键字时所生成汇编代码的差别，通过对比就会发现，关键变化在于有volatile修饰的变量，赋值后（mov%eax，0x150（%esi）这句便是赋值操作）多执行了一个“lock addl ＄0x0，（%esp）”操作，这个操作相当于一个内存屏障（Memory Barrier或Memory Fence，指令重排序时不能把后面的指令重排序到内存屏障之前的位置），只有一个CPU访问内存时，并不需要内存屏障；但如果有两个或更多CPU访问同一块内存，且其中有一个在观测另一个，就需要内存屏障来保证一致性了。这句指令中的“addl ＄0x0，（%esp）”（把ESP寄存器的值加0）显然是一个空操作（采用这个空操作而不是空操作指令nop是因为IA32手册规定lock前缀不允许配合nop指令使用），关键在于lock前缀，查询IA32手册，它的作用是使得本CPU的Cache写入了内存，该写入动作也会引起别的CPU或者别的内核无效化（Invalidate）其Cache，这种操作相当于对Cache中的变量做了一次前面“store和write”操作。所以通过这样一个空操作，可让前面volatile变量的修改对其他CPU立即可见。因此，lock addl＄0x0，（%esp）指令把修改同步到内存时，意味着所有之前的操作都已经执行完成，后续其他线程可以从内存中读写该变量的值，这样便形成了“指令重排序无法越过内存屏障”的效果。

内存屏障：

通过volatile标记，可以解决编译器层面的可见性与重排序问题。而内存屏障则解决了硬件层面的可见性与重排序问题。

内存屏障其实就是一条CPU指令，内存屏障保证在该指令之前的指令执行完之后，才能执行该指令之后的指令。

先简单了解两个指令：

Store：将处理器缓存的数据刷新到内存中。

Load：将内存存储的数据拷贝到处理器的缓存中。

StoreLoad Barriers同时具备其他三个屏障的效果，因此也称之为全能屏障（mfence），是目前大多数处理器所支持的；但是相对其他屏障，该屏障的开销相对昂贵。

·  当CPU收到屏障指令时，不将屏障指令放入序列缓冲区，而将屏障指令及后续所有指令放入一个FIFO队列中（指令是按批发送的，不然没有乱序的必要）

·  允许乱序执行完序列缓冲区中的所有指令

·  从FIFO队列中取出屏障指令，执行（并刷新缓存等，实现内存可见性的语义）

·  将FIFO队列中的剩余指令放入序列缓冲区

·  恢复正常的乱序执行

Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”（Within-Thread As-If-Serial Semantics），后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

synchronized和Lock不能保证有序性，被synchronized和Lock锁定的同步代码，CPU还是可以乱序执行指令的。

我们回头看一下Java内存模型中对volatile变量定义的特殊规则。

假定T表示一个线程，V和W分别表示两个volatile型变量，那么在进行read、load、use、assign、store和write操作时需要满足如下规则：

1、只有当线程T对变量V执行的前一个动作是load的时候，线程T才能对变量V执行use动作；并且，只有当线程T对变量V执行的后一个动作是use的时候，线程T才能对变量V执行load动作。线程T对变量V的use动作可以认为是和线程T对变量V的read、load动作相关联，必须连续一起出现（这条规则要求在工作内存中，每次使用V前都必须先从主内存刷新最新的值，用于保证能看见其他线程对变量V所做的修改后的值）。

2、只有当线程T对变量V执行的前一个动作是assign的时候，线程T才能对变量V执行store动作；并且，只有当线程T对变量V执行的后一个动作是store的时候，线程T才能对变量V执行assign动作。线程T对变量V的assign动作可以认为是和线程T对变量V的store、write动作相关联，必须连续一起出现（这条规则要求在工作内存中，每次修改V后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量V所做的修改）。

3、假定动作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修饰的变量不会被指令重排序优化，保证指令执行顺序与代码被编译后的指令顺序相同）。

因此，被volatile修饰的变量具有可见性和有序性。可见性是通过缓存锁和缓存一致性协议实现的，有序性是通过内存屏障实现的。