Java内存模型基础
并发编程模型的两个关键问题
- 1.线程之间如何通信
- 2.线程之间如何同步
线程之间的通信
通信是指线程之间以何种机制来交换信息,在命令式编程中,线程之间的通信机制有两种,共享内存和消息投递
- 在共享内存的并发模型里,线程之间共享程序的公共状态,通过读-写内存中的公共状态进行隐式通信.
- 在消息传递的并发模型里,线程之间没有公共状态,线程之间必须通过发送消息来显式进行通信
线程之间的同步
同步是指程序中用于控制不同线程间操作发生相对顺序的机制.
- 在共享内存的并发模型中,同步是显式进行的,必须显式指定某个方法或某段代码需要在线程之间互斥进行.
- 在消息传递的并发模型里,由于消息的发送必须在消息接收前.所以同步是隐式进行的.
Java的并发采用的是共享内存模型,Java之间的通信总是隐式进行,整个通信过程对程序员完全透明.
Java内存模型的抽象结构
线程A与线程B之间要通信的话,需要进行如下的步骤
- 1.线程A把本地内存中更新过来的共享内存变量刷新到主内存去.
- 2.线程B到主内存去读线程A之前已更新过得共享内存.
线程A->将本地副本写入主存->线程B读取主存中的对应部分(线程B的共享变量副本更新)
JMM通过控制主内存与每个线程的本地内存之间的交互，来为Java程序员提供内存可见性保证。
从源代码到指令序列的重排序
在执行程序时,为了提高性能.编译器和处理器常常会对指令进行重排序
重排序的三种类型:
- 编译器优化的重排序
编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序. - 指令级并行的重排序
如果不存在数据依赖性,处理器可以改变语句对应机器指令的指令顺序. - 内存系统的重排序.
由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。
重排序的执行顺序
从源码到最终执行的指令序列的示意图
上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特定类型的内存屏障（Memory Barriers，Intel称之为Memory Fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序``。(可以联想一下volatile关键字`)
JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。
Happen-Before简介
在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须要存在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与JMM的关系
一个happens-before规则对应于一个或多个编译器和处理器重排序规则。
重排序
重排序是指编译器和处理器为了优化程序性能而能对序列指令进行重新排序的一种手段.
数据依赖性
如果两个操作访问同一个变量,且这两个操作有一个为写操作,此时这两个操作之间就会存在数据依赖性.数据依赖的三种形式如下:
上面3种情况，只要重排序两个操作的执行顺序，程序的执行结果就会被改变。
这里所说的数据依赖性性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，
不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。
as-if-serial语义
as-if-serial语义的意思是：
不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。
为了遵守as-if-serial语义,编译器和处理器不会对存在数据依赖关系的操作做重排序,这种重排序会改变执行结果.不存在数据依赖关系的操作可能就会被编译器和处理器进行重排序操作.
示例
double pi = 3.14; // A
double r = 1.0; // B
double area = pi * r * r; //
3个操作之间的依赖关系
如上图所示,A和C,B和C存在依赖关系,因此在最终执行的指令序列当中,C不能重排序到A和B前面,但是A,B之间不存在数据依赖关系,编译器和处理器可以重排序A和B之间的执行顺序.
程序的两种执行顺序
程序顺序规则
根据happens-before的程序顺序规则，上面计算圆的面积的示例代码存在3个happens-before关系。
1）A happens-before B。
2）B happens-before C。
3）A happens-before C。
第3个happens-before关系，是根据happens-before的传递性推导出来的
这里A happens-before B，但实际执行时B却可以排在A之前执行（看上面的重排序后的执
行顺序）。如果A happens-before B，JMM并不要求A一定要在B之前执行。JMM仅仅要求前一个 操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前。这里操作A
的执行结果不需要对操作B可见；而且重排序操作A和操作B后的执行结果，与操作A和操作B
按happens-before顺序执行的结果一致。在这种情况下，JMM会认为这种重排序并不非法（not
illegal），JMM允许这种重排序。
软件技术和硬件技术有一个共同的目标：在不改变程序执行结果的前提下，尽可能提高并行度。编译器和处理器遵从这一目标，从happens-before的定义我们可以看出，JMM同样遵从这一目标。
重排序对多线程的影响
class ReorderExample {
int a = 0;
boolean flag = false;
public void writer() {
a = 1; // 1
flag = true; // 2
}
public void reader() {
if (flag) { // 3
int i = a * a; // 4
……
}
}
}
操作1和操作2之间没有数据依赖的关系,编译器和处理器会对这两个操作重排序;同样,操作4和操作3没有数据依赖关系(是数据依赖关系),编译器和处理器也可以对这两个操作进行重排序.
操作1和操作2做了重排序.程序执行时,线程A首先写标记变量flag，随后线程B读这个变量。由于条件判断为真，线程B将读取变量a。此时，变量a还没有被线程A写入，在这里多线程程序的语义被重排序破坏了！
在程序中,操作3和操作4控制存在依赖关系.当代码存在依赖性时,会影响指令序列执行的并行度.为此,编译器和处理器会采用猜测测（Speculation）执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例，执行线程B的处理器可以提前读取并计算a*a，然后把计算结果临时保存到一个名为重排序缓冲（Reorder Buffer，ROB）的硬件缓存中。当操作3的条件判断为真时，就把该计算结果写入变量i中。
从上面的图片可以看出,猜测执行实质上对操作3和4做了重排序.重排序在这里破坏了多线程程序的语义.
在单线程程序中,对存在控制依赖的操作重排序,不会改变执行结果这也是as-if-serial语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。
顺序一致性
顺序一致性内存模型是一个理论参考模型，在设计的时候，处理器的内存模型和编程语言的内存模型都会以顺序一致性内存模型作为参照。
数据竞争顺序一致性
当程序未正确同步时,就可能存在数据竞争.Java内存模型规范对数据竞争的定义如下.
- 在一个线程中写一个变量
- 在另一个线程读同一个变量
- 而且读和写没有通过同步来排序
当代码中包含数据竞争时，程序的执行往往产生违反直觉的结果。如果一个多线程程序能正确同步，这个程序将是一个没有数据竞争的程序。
JMM对正确同步的多线程的内存一致性做了如下保证.
如果程序是同步的,程序的执行将具有顺序一致性(Sequentially Consistent)--即线程的执行结果与该程序在顺序一致性的内存模型中的执行结果相同.
顺序一致性内存模型
顺序一致性内存模型是一个理论模型,它为程序员提供了极强的内存可见性保证.顺序一致性内存模型有两大特性.
- 1)一个线程中的所有操作必须按照程序的顺序来执行.
- 2)(不管程序是否同步)所有线程都只能看到一个单一的操作执行顺序.在顺序一致性内存模型中,每个操作都必须原子执行,且立刻对所有线程可见.
顺序一致性模型为程序员提供的视图如下.
顺序一致性内存模型的视图
在概念上,顺序一致性模型有一个单一的全局内存,这个内存通过一个左右摆动的开关可以连接到任意一个线程,同时每一个线程必须按照程序的顺序来执行读\写操作.从上面的示意图可以看出,在任意时间点最多只有一个线程可以连接到内存.当多个线程并发执行时,图中的开关装置能把所有内存读/写操作串行化(即在顺序一致性模型中,所有操作之间具有全序关系).
示例
假设有两个线程A和B并发执行。其中A线程有3个操作，它们在程序中的顺序是：A1→A2→A3。B线程也有3个操作，它们在程序中的顺序是：B1→B2→B3.
假设这两个线程使用监视器锁来正确同步：A线程的3个操作执行后释放监视器锁，随后B线程获取同一个监视器锁。
顺序一致性模型的一种执行效果
再假设这两个线程没有做同步，下面是这个未同步程序在顺序一致性模型中的
执行示意图
顺序一致性模型中的另一种执行效果
未同步程序在顺序一致性模型中虽然整体执行顺序是无序的，但所有线程都只能看到一个一致的整体执行顺序。以上图为例，线程A和B看到的执行顺序都是：
B1→A1→A2→B2→A3→B3。之所以能得到这个保证是因为顺序一致性内存模型中的每个操作必须立即对任意线程可见
但是，在JMM中就没有这个保证。未同步程序在JMM中不但整体的执行顺序是无序的，而 且所有线程看到的操作执行顺序也可能不一致。
比如，在当前线程把写过的数据缓存在本地内存中，在没有刷新到主内存之前，这个写操作仅对当前线程可见；从其他线程的角度来观察，会认为这个写操作根本没有被当前线程执行。只有当前线程把本地内存中写过的数据刷新到主内存之后，这个写操作才能对其他线程可见。在这种情况下，当前线程和其他线程看到的操作执行顺序将不一致。
同步程序的顺序一致性效果
对前面的示例程序ReorderExample用锁来同步
class SynchronizedExample {
int a = 0;
boolean flag = false;
public synchronized void writer() { // 获取锁
a = 1;
flag = true;
} // 释放锁
public synchronized void reader() { // 获取锁
if (flag) {
int i = a;
……
} // 释放锁
}
}
假设A线程执行writer()方法后，B线程执行reader()方法。这是一个正确同步的多线程程序。根据JMM规范，该程序的执行结果将与该程序在顺序一致性模型中的执行结果相同。
顺序一致性模型中,所有操作完全按照程序的顺序串行执行.而在JMM中,临界区内的代码可以重排序(但JMM不允许临界区内的代码“逸出”到临界区之外，那样会破坏监视器的语义）。
JMM会在退出临界区和进入临界区这两个关键时间点做一些特别处理，使得线程在这两个时间点具有与顺序一致性模型相同的内存视图.虽然线程A在临界区内做了重排序，但由于监视器互斥执行的特性，这里的线程B根本无法“观察”到线程A在临界区内的重排序。这种重排序既提高了执行效率，又没有改变程序的执行结果。
两个内存模型中的执行时序对比图
JMM在具体实现上的基本方针为：在不改变（正确同步的）程序执行结果的前提下，尽可能地为编译器和处理器的优化打开方便之门。
未同步程序的执行特征
对于未同步或未正确同步的多线程程序，JMM只提供最小安全性：线程执行时读取到值,要么是之前某个线程写入的值,要么是默认值（0，Null，False），JMM保证线程读操作读取到的值不会无中生有（Out Of Thin Air）的冒出来。
为了实现最小安全性,JVM在堆上分配对象时，首先会对内存空间进行清零，然后才会在上面分配对象（JVM内部会同步这两个操作）。因此，在已清零的内存空间（Pre-zeroed Memory）分配对象时，域的默认初始化已经完成了。
JMM不保证未同步程序的执行结果与该程序在顺序一致性模型中的执行结果一致。(考虑到性能消耗)
未同步程序在JMM中的执行时，整体上是无序的，其执行结果无法预知。未同步程序在两个模型中的执行特性有如下几个差异。
- 顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的操作会按程序的顺序执行（比如上面正确同步的多线程程序在临界区内的重排序）。
-
顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程能看到一致的操作执行顺序。 - JMM不保证对64位的long型和double型变量的写操作具有原子性，而顺序一致性模型保证对所有的内存读/写操作都具有原子性。
参考书籍:<<Java并发编程的艺术>>
网友评论