转载请以链接形式标明出处: 本文出自:103style的博客
内存模型基础
volatile的内存语义
锁的内存语义
final域的内存语义
happens-before
双重检查锁定与延迟初始化
Java内存模型综述
小结
Java并发 采用的是 共享内存模型,Java线程之前的通信总是隐式进行的。
在Java中,所有 实例域、静态域 和 数组元素 都储存在堆内存中,堆内存在线程之前共享。 本文用 共享变量 统一描述 实例域、静态域 和 数组元素 。
局部变量 、方法定义参数、异常处理器参数 不会在内存之间共享,他们不会有内存可见性问题,也不受内存模型影响。
Java线程通信由Java内存模型(简称 JMM
)控制,JMM 决定一个线程对共享变量的写入何时对另一个线程可见。
从抽象角度看,JMM定义了 线程 和 主内存 之间的抽象关系:线程之间的共享变量储存在主内存中,每个线程都有一个私有的本地内存,本地内存储存了 该线程 以读写共享变量的副本。
从上图来看,线程A和线程B需要通信的话,需要经历以下步骤: 1、线程A 把 本地内存A 中的 共享变量副本 刷新到 主内存 中。 2、线程B 去读取 主内存 中 线程A 刷新过的 共享变量。
从整体来看,这两个步骤实质上是线程A向线程B发送消息,而通信必须经过主内存。 JMM 通过控制主内存与每个线程的本地内存之间的交互,来提供内存可见性的保证。
执行程序的时候,为了提高性能,编译器 和 处理器 常常会对指令做 重排序。 主要有以下三类:
以下描述了源代码到最终执行的指令序列的示意图:
上图中的 1 属于 编译器重排序,2 和 3 属于 处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。
对于编译器重排序, JMM的编译器重排序规则 会禁止特定类型的编译器重排序。 对于处理器重排序,JMM的处理器重排序规则 会要求编译器在生成指令序列时,插入特定类型的内存屏障指令,通过内存屏障指令来禁止特定类型的处理器重排序。
从 JDK5 开始,Java使用新的 JSR-133 内存模型。 JSR-133 使用 happens-before 的概念来阐述操作之间的内存可见性。在 JMM 中,如果一个操作执行的结果需要对另一个操作可见,则这两个操作必须要存在happen-before关系 。
happen-before 规则如下:
理解volatile
特性的一个好方法是把对volatile
变量的单个读/写,看成是 使用同一个锁 对这些单个读/写操作做了同步。
volatile
变量具有下列特性:
volatile
变量最后的写入。volatile
变量的读/写具有原子性,但类似于volatile++
这种复合操作不具有原子性。volatile
写的内存语义:当写一个volatile
变量时,JMM 会把该线程对应的本地内存中的共享变量值刷新到主内存。
volatile
读的内存语义:当读一个volatile
变量时,JMM 会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。
为了实现volatile
内存语义,JMM 会分别限制这两种类型的重排序类型。
以下是 JMM 针对 编译器 制定的 volatile
重排序规则表:
是否能重排序 | 第二个操作 | 第二个操作 | 第二个操作 |
---|---|---|---|
第一个操作 | 普通读写 | volatile读 | volatile写 |
普通读写 | (1)NO | ||
volatile读 | NO | NO | NO |
volatile写 | NO | NO |
第三行最后一个单元格(1)
的意思是:在程序中,当第一个操作为普通变量的读或写时,如果第二个操作为volatile写,则编译器不能重排序这两个操作。
在上表中,我们可以知道:
volatile 写
时,不管第一个操作是什么,都不能重排序。这个规则确保volatile 写
之前的操作不会被编译器重排序到volatile 写
之后。volatile 读
时,不管第二个操作是什么,都不能重排序。这个规则确保volatile 读
之后的操作不会被编译器重排序到volatile 读
之前。volatile 写
,第二个操作是volatile 读
时,不能重排序。为了实现volatile
的内存语义,编译器在生成字节码时,会在指令序列中插入 内存屏障 来禁止特定类型的 处理器重排序。
对于编译器来说,发现一个最优布置来最小化插入屏障的总数几乎不可能。
为此,JMM采取保守策略。
下面是基于保守策略的JMM内存屏障插入策略。
volatile 写
操作的前面插入一个StoreStore
屏障,后面插入一个StoreLoad
屏障。volatile 读
操作的后面插入一个LoadLoad
屏障,后面插入一个LoadStore
屏障。当读线程的数量大大超过写线程时,选择在
volatile
写之后插入StoreLoad
屏障将带来可观的执行效率的提升。
锁是Java并发编程中最重要的同步机制。锁除了让临界区互斥执行外,还可以让释放锁的线程向获取同一个锁的线程发送消息。
当线程释放锁时,JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。和 volatile 写
类似。
当线程获取锁时,JMM会把该线程对应的本地内存置为无效。和 volatile 读
类似。
锁释放和锁获取的内存语义总结:
类似 Java并发编程基础 介绍的 等待/通知 机制。
锁的介绍
与前面介绍的锁和volatile
相比,对final
域的读和写更像是普通的变量访问。
对于final
域,编译器 和 处理器 要遵守两个 重排序规则。
final
域的写入,与随后把这个被构造对象的引用赋值给一个引用变量,这两个操作之间不能重排序。final
域的对象的引用,与随后初次读这个final
域,这两个操作之间不能重排序。写final域
的重排序规则禁止把final 域
的写重排序到构造函数之外。
读 final域
的重排序规则是,在一个线程中,初次读对象引用与初次读该对象包含的 final域
,JMM禁止处理器重排序这两个操作(注意,这个规则仅仅针对处理器)。
happens-before
是 JMM 最核心的概念。
重排序规则:只要不改变程序的执行结果(指的是单线程程序和正确同步的多线程程序),编译器和处理器怎么优化都行。
happens-before
关系的定义如下:
happens-before
另一个操作,那么第一个操作的执行结果将对第二个操作可见,而且第一个操作的执行顺序排在第二个操作之前。happens-before
关系,并不意味着Java平台的具体实现必须要按照happens-before
关系指定的顺序来执行。如果重排序之后的执行结果,与按happens-before
关系来执行的结果一致,那么这种重排序并不非法(也就是说,JMM允许这种重排序)。《JSR-133:Java Memory Model and Thread Specification》 定义了如下happens-before
规则:
happens-before
于该线程中的任意后续操作。happens-before
于随后对这个锁的加锁。volatile 域
的写,happens-before
于任意后续对这个volatile 域
的读。happens-before
B,且B happens-before
C,那么A happens-before
C。线程A
执行操作ThreadB.start()
(启动线程B
),那么A线程
的ThreadB.start()
操作happens-before
于线程B
中的任意操作。线程A
执行操作ThreadB.join()
并成功返回,那么线程B
中的任意操作happens-before
于线程A
从ThreadB.join()
操作成功返回。双重检查锁定 示例代码:
private static Instance instance; //1
public static Instance getInstance() { //2
if (instance == null) { //3
synchronized (Instance.class) { //4
if (instance == null) { //5
instance = new Instance() //6
}
}
}
return instance;
}
存在的问题:
在线程执行到第3
行if (instance == null)
,代码读取到instance
不为null
时,instance
引用的对象有可能还没有完成初始化。
问题的根源
前面的双重检查锁定示例代码的第6
行instance=new Singleton();
创建了一个对象。
这一行可以分解为:
memory = allocate(); // 1:分配对象的内存空间
ctorInstance(memory); // 2:初始化对象
instance = memory; // 3:设置instance指向刚分配的内存地址
代码中的2
和3
之间,可能会被重排序为:
memory = allocate(); // 1:分配对象的内存空间
instance = memory; // 3:设置instance指向刚分配的内存地址
// 注意,此时对象还没有被初始化!
ctorInstance(memory); // 2:初始化对象
如下图所示,只要保证2排在4的前面,即使2和3之间重排序了,也不会违反intra-thread semantics
。
如果发生重排序,另一个并发执行的线程B就有可能在示例代码第 3
行if (instance == null)
判断instance
不为null
。
解决方法:
2
和 3
重排序。2
和 3
重排序,但不允许其他线程“看到”这个重排序。基于volatile的解决方案
只需要给变量 instance
添加 volatile
修饰符。
private volatile static Instance instance;
public static Instance getInstance() {
if (instance == null) {
synchronized (Instance.class) {
if (instance == null) {
instance = new Instance();
}
}
}
return instance;
}
基于类初始化的解决方案
public static class InstanceFactory {
public static Instance getInstance() {
// 这里将导致InstanceHolder类被初始化
return InstanceHolder.instance;
}
private static class InstanceHolder {
public static Instance instance = new Instance();
}
}
初始化一个类,包括执行这个类的静态初始化和初始化在这个类中声明的静态字段。根据Java语言规范,在首次发生下列任意一种情况时,一个类或接口类型T
将被立即初始化。
T
是一个类,而且一个T
类型的实例被创建。T
是一个类,且T
中声明的一个静态方法被调用。T
中声明的一个静态字段被赋值。T
中声明的一个静态字段被使用,而且这个字段不是一个常量字段。T
是一个顶级类(Top Level Class,见Java语言规范的§7.6
),而且一个断言语句嵌套在T
内部被执行。在InstanceFactory
示例代码中,首次执行getInstance()
方法的线程将导致InstanceHolder
类被初始化(符合第4
条)。
由于Java语言是多线程的,多个线程可能在同一时间尝试去初始化同一个类或接口。 因此,在Java中初始化一个类或者接口时,需要做细致的同步处理。
Java语言规范规定,对于每一个类或接口C
,都有一个唯一的初始化锁LC
与之对应。从C
到LC
的映射,由JVM的具体实现去自由实现。JVM在类初始化期间会获取这个初始化锁,并且每个线程至少获取一次锁来确保这个类已经被初始化过了。
顺序一致性内存模型 是一个 理论参考模型,JMM和处理器内存模型在设计时通常会以顺序一致性内存模型为参照。 在设计时,JMM和处理器内存模型会 对顺序一致性模型做一些放松,因为如果完全按照顺序一致性模型来实现处理器和JMM,那么很多的处理器和编译器优化都要被禁止,这对执行性能将会有很大的影响。
根据对不同类型的读/写操作组合的执行顺序的放松,可以把常见处理器的内存模型划分为如下几种类型:
Total Store Ordering
内存模型(简称为 TSO)。Partial Store Order
内存模型(简称为 PSO)。Relaxed Memory Order
内存模型(简称为 RMO)和 PowerPC 内存模型。从上图中可知:
写-读
重排序,因为都使用了 写缓存区。
由于写缓存区仅对当前处理器可见,这个特性导致当前处理器可以比其他处理器先看到临时保存在自己写缓存区中的写。由于常见的处理器内存模型比JMM要弱,Java编译器在生成字节码时,会在执行指令序列的适当位置插入 内存屏障 来限制处理器的重排序。
JMM 是一个语言级的内存模型。 处理器内存模型 是硬件级的内存模型。 顺序一致性内存模型 是一个理论参考模型。
从下图可以看出:
常见的4
种 处理器内存模型 比常用的3
中 语言内存模型 要 弱,
处理器内存模型 和 语言内存模型 都比 顺序一致性内存模型 要 弱。
同处理器内存模型一样,越是追求执行性能的语言,内存模型设计得会越弱。
按程序类型,Java程序的内存可见性保证可以分为下列3类:
0
、null
、false
)。0
、null
、false
)。JSR-133 对 JDK 5 之前的旧内存模型的修补主要有两个:
volatile
的内存语义:限制volatile
变量与普通变量的重排序,使volatile
的写-读和锁的释放-获取具有相同的内存语义。final
的内存语义:保证final引用不会从构造函数内逸出的情况下,final
具有了初始化安全性。本文我们介绍了:
实例域
、静态域
和数组元素
等才能在线程间共享。以上