并发编程模型的分类
在并发编程中，我们需要处理两个关键问题：线程之间如何通信及线程之间如何同步（这里的线程是指并发执行的活动实体）。通信是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。
在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。
同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。
Java内存模型的抽象Java的并发采用的是共享内存模型，Java线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。如果编写多线程程序的Java程序员不理解隐式进行的线程之间通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。
在java中，所有实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共享（本文使用“共享变量”这个术语代指实例域，静态域和数组元素）。局部变量（Local variables），方法定义参数（java语言规范称之为formal method parameters）和异常处理器参数（exception handler parameters）不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。
Java线程之间的通信由Java内存模型（本文简称为JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。Java内存模型的抽象示意图如下：
从上图来看，线程A与线程B之间如要通信的话，必须要经历下面2个步骤：
- 首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
- 然后，线程B到主内存中去读取线程A之前已更新过的共享变量。
下面通过示意图来说明这两个步骤：
如上图所示，本地内存A和B有主内存*享变量x的副本。假设初始时，这三个内存中的x值都为0。线程A在执行时，把更新后的x值（假设值为1）临时存放在自己的本地内存A中。当线程A和线程B需要通信时，线程A首先会把自己本地内存中修改后的x值刷新到主内存中，此时主内存中的x值变为了1。随后，线程B到主内存中去读取线程A更新后的x值，此时线程B的本地内存的x值也变为了1。
从整体来看，这两个步骤实质上是线程A在向线程B发送消息，而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供内存可见性保证。
重排序
在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。重排序分三种类型：
- 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
- 指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
- 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
从java源代码到最终实际执行的指令序列，会分别经历下面三种重排序：
上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel称之为memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。
JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。
处理器重排序与内存屏障指令
现代的处理器使用写缓冲区来临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，可以减少对内存总线的占用。虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响：处理器对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致！为了具体说明，请看下面示例：
| Processor A | Processor B |
|---|---|
| a = 1; //A1 x = b; //A2 |
b = 2; //B1 y = a; //B2 |
| 初始状态：a = b = 0 处理器允许执行后得到结果：x = y = 0 |
|
假设处理器A和处理器B按程序的顺序并行执行内存访问，最终却可能得到x = y = 0的结果。具体的原因如下图所示：
这里处理器A和处理器B可以同时把共享变量写入自己的写缓冲区（A1，B1），然后从内存中读取另一个共享变量（A2，B2），最后才把自己写缓存区中保存的脏数据刷新到内存中（A3，B3）。当以这种时序执行时，程序就可以得到x = y = 0的结果。
从内存操作实际发生的顺序来看，直到处理器A执行A3来刷新自己的写缓存区，写操作A1才算真正执行了。虽然处理器A执行内存操作的顺序为：A1->A2，但内存操作实际发生的顺序却是：A2->A1。此时，处理器A的内存操作顺序被重排序了（处理器B的情况和处理器A一样，这里就不赘述了）。
这里的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。由于现代的处理器都会使用写缓冲区，因此现代的处理器都会允许对写-读操做重排序。
下面是常见处理器允许的重排序类型的列表：
| Load-Load | Load-Store | Store-Store | Store-Load | 数据依赖 | |
| sparc-TSO | N | N | N | Y | N |
| x86 | N | N | N | Y | N |
| ia64 | Y | Y | Y | Y | N |
| PowerPC | Y | Y | Y | Y | N |
上表单元格中的“N”表示处理器不允许两个操作重排序，“Y”表示允许重排序。
从上表我们可以看出：常见的处理器都允许Store-Load重排序；常见的处理器都不允许对存在数据依赖的操作做重排序。sparc-TSO和x86拥有相对较强的处理器内存模型，它们仅允许对写-读操作做重排序（因为它们都使用了写缓冲区）。
※注1：sparc-TSO是指以TSO(Total Store Order)内存模型运行时，sparc处理器的特性。
※注2：上表中的x86包括x64及AMD64。
※注3：由于ARM处理器的内存模型与PowerPC处理器的内存模型非常类似，本文将忽略它。
※注4：数据依赖性后文会专门说明。
为了保证内存可见性，java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM把内存屏障指令分为下列四类：
| 屏障类型 | 指令示例 | 说明 |
| LoadLoad Barriers | Load1; LoadLoad; Load2 | 确保Load1数据的装载，之前于Load2及所有后续装载指令的装载。 |
| StoreStore Barriers | Store1; StoreStore; Store2 | 确保Store1数据对其他处理器可见（刷新到内存），之前于Store2及所有后续存储指令的存储。 |
| LoadStore Barriers | Load1; LoadStore; Store2 | 确保Load1数据装载，之前于Store2及所有后续的存储指令刷新到内存。 |
| StoreLoad Barriers | Store1; StoreLoad; Load2 | 确保Store1数据对其他处理器变得可见（指刷新到内存），之前于Load2及所有后续装载指令的装载。StoreLoad Barriers会使该屏障之前的所有内存访问指令（存储和装载指令）完成之后，才执行该屏障之后的内存访问指令。 |
StoreLoad Barriers是一个“全能型”的屏障，它同时具有其他三个屏障的效果。现代的多处理器大都支持该屏障（其他类型的屏障不一定被所有处理器支持）。执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（buffer fully flush）。
happens-before
从JDK5开始，java使用新的JSR -133内存模型（本文除非特别说明，针对的都是JSR- 133内存模型）。JSR-133提出了happens-before的概念，通过这个概念来阐述操作之间的内存可见性。如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。 与程序员密切相关的happens-before规则如下：
- 程序顺序规则：一个线程中的每个操作，happens- before 于该线程中的任意后续操作。
- 监视器锁规则：对一个监视器锁的解锁，happens- before 于随后对这个监视器锁的加锁。
- volatile变量规则：对一个volatile域的写，happens- before 于任意后续对这个volatile域的读。
- 传递性：如果A happens- before B，且B happens- before C，那么A happens- before C。
注意，两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visible to and ordered before the second）。happens- before的定义很微妙，后文会具体说明happens-before为什么要这么定义。
happens-before与JMM的关系如下图所示：
如上图所示，一个happens-before规则通常对应于多个编译器重排序规则和处理器重排序规则。对于java程序员来说，happens-before规则简单易懂，它避免程序员为了理解JMM提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现。
几个不解的地方2013年1月23日 11:02 by 丁 佳砙
A更新了本地副本x的值，不会主动刷新到主存中吗，必须等到和B通信时？另外，为什么是A和B通信，而不是B和A通信？这个时候A已经执行完了操作呀。
是指令级还是指令集？
Re: 几个不解的地方2013年1月23日 03:28 by 傅 晗
Re: 几个不解的地方2013年1月23日 09:05 by 程 晓明
--A线程迟早会把更新过的X值刷新到主内存中，但具体会在什么时候刷新到主内存是不确定的。如果我们使用同步原语（synchronized，volatile和final），那么刷新的时机是确定的。比如，如果A线程释放了锁，它就会刷新本地内存A；接下来如果B线程获取同一个锁，B线程就会到主内存中去读取共享变量的值。此时，B线程就可以读取到A线程对共享变量所做的修改了（即“A线程释放锁--B线程获取锁”可以实现A，B线程之间的通信）。
另外，为什么是A和B通信，而不是B和A通信？
--这里的通信是指线程之间通过共享变量来沟通。由于共享变量在所有线程之间共享，如果A，B线程之间需要沟通，只需要A线程把写过的共享变量的值刷新到主内存，随后B线程到到主内存中去读取这些共享变量即可。这个过程可以让B线程看到A线程对共享变量锁做的修改，这种线程之间的沟通方式在本文中称之为通信。
Re: 几个不解的地方2013年1月23日 09:33 by 程 晓明
--是指令级。
指令级并行（Instruction-Level Parallelism， ILP）是指处理器将多条指令重叠执行以提高性能，这种重叠称之为指令级并行。
一个处理器支持的指令和指令的字节级编码称之为指令集体系结构（Instruction Set Architecture, ISA）
Re: 几个不解的地方2013年1月23日 09:36 by 程 晓明
即：这个过程可以让B线程看到A线程对共享变量所做的修改，这种线程之间的沟通方式在本文中称之为通信。
Re: 几个不解的地方2013年1月23日 10:10 by 丁 佳砙
我忘了本文的大前提，理解成A和B的通信有主动方和被动方了。
关于配图2013年1月24日 12:07 by Chen reniaL
Re: 关于配图2013年1月24日 10:11 by Shui Arthur
一个描述问题2013年1月28日 01:48 by Dong Pengfei
Java的并发采用的是共享内存模型，Java线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。
这表述为什么前后不一致？
Re: 一个描述问题2013年1月28日 09:24 by 程 晓明
并发编程要处理两个关键问题：通信和同步。
共享内存模型：显式同步，隐式通信。
消息传递模型：显式通信，隐式同步。
由于java的并发采用共享内存模型，所以java线程之间的通信是隐式进行的。
结合聊聊并发系列文章，好好补补知识结构，感谢作者的分享2013年2月3日 11:23 by rao aaron
Re: 一个描述问题2013年2月4日 10:03 by Guo Gem
Re: 关于配图2013年2月10日 01:37 by Neo Tan
谢谢分享2013年3月15日 01:42 by tian jason
并发语言erlang相比2013年3月23日 09:29 by zehe chen
楼主，我一直有个问题：请教，希望不吝赐教2013年3月26日 09:44 by 增发 li
Re: 楼主，我一直有个问题：请教，希望不吝赐教2013年3月31日 11:36 by 程 晓明
《Computer Architecture: A Quantitative Approach, 4th Edition》的4.2章，对缓存一致性有详细的说明。
我举的第一个例子（关于写缓冲区），来自于参考文献8的8.2.3.5。在这一章节的最后，有下面这段话：
In practice, the reordering in this example can arise as a result of store-buffer forwarding. While a store is temporarily held in a processor's store buffer, it can satisfy the processor's own loads but is not visible to (and cannot satisfy) loads by other processors.
上面这段话的大意是说：
事实上，这个例子能够出现这样的结果，是因为store-buffer forwarding。当一个写操作被临时保存在一个处理器的写缓存区时，这个写操作能被该处理器自己读取到；但这个写操作对其他处理器不可见，也不能被其他处理器读取到。
不错2013年4月9日 10:40 by wuya wuya
简单的说是 说是 java线程通信 是隐式的 是怎么分析过来的
关于在线程之间共享的元素2013年4月9日 03:08 by 黄 春
文中提到“实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共享”。 那如果是方法里面定义的一个局部数组，也是线程间共享的么？
Re: 不错2013年4月15日 12:32 by 程 晓明
JSR-133: Java Memory Model and Thread Specification
The JSR-133 Cookbook for Compiler Writers
JSR 133 (Java Memory Model) FAQ
Java的并发采用的是共享内存模型，共享内存模型的线程间通信是隐式进行的。
如果对于这个主题感兴趣的话，可以参阅Michael L. Scott的《Programming Language Pragmatics, Third Edition 》的第12章。
Re: 关于在线程之间共享的元素2013年4月16日 06:08 by 程 晓明
Re: 关于在线程之间共享的元素2013年5月4日 02:26 by he haibo
Re: 关于在线程之间共享的元素2013年5月4日 02:26 by he haibo
在java中，静态变量保存在堆还是栈里面？2013年11月4日 10:23 by 刘 杰
部分建议和探讨2013年12月29日 12:55 by 孟 衡
好了，建议就提到这里，讨论个问题。
文章开头提到“本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化”，针对这里本地内存是不真实存在，我有些疑问。虚拟机会为每个线程开辟一块虚拟机栈，默认大小1M，这是实实在在占用java进程内存的，这不就是每个线程专属的本地内存吗？它应该是实实在在存在的。缓存、写缓冲区的概念比较模糊，不清楚是CPU的还是内存的，不讨论，但寄存器和Java的内存模型是两个概念，是属于CPU级别的缓存，已经不是虚拟机所能控制的范围，任何内存发起的访问都会使用到寄存器，而不限于线程，我觉得不应该把它划为线程的本地内存。
Re: 在java中，静态变量保存在堆还是栈里面？2014年1月18日 12:01 by 程 晓明
--这句话是《The Java™ Language Specification Java SE 7 Edition》的17.4.1的原文(※1)：
Memory that can be shared between threads is called shared memory or heap
memory.
All instance fields, static fields, and array elements are stored in heap memory.
上面这段话的大意是说：
内存能在线程之间共享，它被称为共享内存或堆内存。
所有实例域、静态域和数组元素存储在堆内存中。
从上面这段话来看，这里的堆内存指的是在线程之间共享的内存区域。
______________________________________
我们再来看《The Java™ Virtual Machine Specification Java SE 7 Edition》的描述。
在2.5.3中有如下说明(※2)：
The Java virtual machine has a heap that is shared among all Java virtual machine
threads. The heap is the runtime data area from which memory for all class
instances and arrays is allocated.
上面这段话的大意是说：
java虚拟机有一个堆内存，它在所有java虚拟机线程之间共享。堆是存放运行时数据的内存区域，所有类的实例和数组都在堆上分配。
2.5.4章的第一段话(※3)：
The Java virtual machine has a method area that is shared among all Java virtual
machine threads... It stores per-class structures such as the runtime constant pool, field and method data, and the code for methods and constructors...
上面这段话的大意是说：
java虚拟机有一个在所有线程之间共享的方法区。。。它存储每一个类的结构信息，比如运行时常量池，域和方法数据，以及方法和构造函数的字节码。。。
2.5.4章的第二段话(※4)：
The method area is created on virtual machine start-up. Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it.
这段话的大意是说：
方法区在虚拟机启动的时候创建。尽管方法区是堆的逻辑部分，但简单的jvm实现可以选择不对其进行垃圾收集或压缩。
**************************************
这里把※2中描述的堆，称之为“java堆”。
在※4中指出，方法区隶属于堆的逻辑部分，这里把这个包含了方法区的堆称之为“广义上的堆”。
由于java堆和方法区在所有java虚拟机线程之间共享，
所以※1中所说的“在线程之间共享的共享内存或堆内存”，指的是“广义上的堆”而非“java堆”。
Re: 部分建议和探讨2014年1月18日 12:35 by 程 晓明
--这个建议很好，谢谢。
在涉及JSR-133的几个规范中，都不存在本地内存的概念：
《JSR-133: Java Memory Model and Thread Specification》，
《The Java™ Language Specification Third Edition》
《The Java™ Language Specification Java SE 7 Edition》，
《The Java™ Virtual Machine Specification Java SE 7 Edition》
本地内存以及这段话的描述，是从Brian Goetz写的一篇关于JSR-133内存模型的非常著名的文章中借鉴而来：
《Java theory and practice: Fixing the Java Memory Model, Part 2》
URL：www.ibm.com/developerworks/library/j-jtp03304/i...
Brian Goetz通过使用本地内存这个概念来抽象CPU，内存系统和编译器的优化。