Java内存模型(Java Memory Model)用来屏蔽各种硬件和操作系统的内存访问差异,这使得Java能够变得非常灵活而不用考虑各系统间的兼容性等问题。定义Java内存模型并非一件容易的事情,从Java出生开始经过长时间的验证和修补,直至JDK5发布后Java内存模型才终于成熟、完善起来了。
Java内存模型的主要目的是定义程序中各种变量的访问规则,即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。
Java内存模型规定了所有变量都存储在主内存(Main Memory)中(此处的内存为Java虚拟机内存的一部分)。每条线程还有自己的工作内存(Working Memory),线程的工作内存中保存了被该线程使用的变量内存副本,线程对变量的所有操作都必须在工作内存中进行,也不能直接读写主内存中数据。不同的线程之间变量值的传递均需要通过主内存来完成。
线程、主内存、工作内存三者的交互关系如下图。
对于主内存和工作内存之间具体的交互协议,Java内存模型中定义了以下8中操作拉完成。
Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的
。
如果想要把一个变量从主内存复制到工作内存,那就要按顺序执行read和load操作,如果要把变量从工作内存同步回主内存,就要按顺执行store和write操作。 除此之外Java内存模型还规定了在执行上述8种基本操作时必须满足如下规则:
上面的8中基本操作,以及这些规则限定了Java程序中哪些内存访问操作在并发下是安全的。虽然繁琐但很严谨,大致操作也可以简化的描述为read、write、lock、unlock四种。我们只需要理解Java内存模型的定义即可。
关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制,但是它并不容易被正确、完整地理解,Java内存模型为volatile专门定义了一些特殊的访问规则。 当一个变量被定义为volatile之后,它将具备两项特性: 第一项是保证此变量对所有线程的“可见性”,可见性是指当一条线程修改了这个变量的值,新值对于其他线程来说是可以立即得知的。
关于volatile变量的可见性,虽然volatile变量对所有线程立即可见,但是基于volatile变量的所有的写操作都能立刻反映到其他线程中的。这句话理论上来说没毛病,但是volatile变量在运算过程中也是存在不一致的情况,因为在Java里面的运算操作符并非原子操作,这导致volatile变量的运算在并发下一样是不安全的。 例如:
/**
* @author jiomer
* @date Create in 2020
* @description volatile变量自增运算测试
*/
public class VolatileOneTest {
public static volatile int race = 0;
public static void increase(){
race++;
}
private static final int THREADS_COUNT = 20;
public static void main(String[] args) {
Thread[] threads = new Thread[THREADS_COUNT];
for (int i = 0;i<THREADS_COUNT;i++){
threads[i] = new Thread(() -> {
for(int i1 = 0; i1 <10000; i1++){
increase();
}
});
threads[i].start();
}
while (Thread.activeCount() > 2){
Thread.yield();
}
System.out.println(race);
}
}
上述代码发起了20个线程,每个线程对race变量进行10000次自增操作,如果能够正确并发的话,运行结果应为20000
,但运行结果并不正确,并且每次输出结果都小于20000
,且都不相同。
由于volatile变量只能保证可见性,在不符合以下两条规则的运行场景中,我们仍然要通过加锁(synchronized、java.util.concurent中的锁或原子类)来保证原子性:
volatile变量的第二项特性是:禁止指令重排序优化。普通的变量金辉保证在该方法的执行过程中所有依赖复制结果的地方都能获取到正确的结果,而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。
上面在介绍Java内存模型的内存交互操作时,介绍了8种操作并明确都是具有原子性的。 但是对于64位的数据类型(long和double),在模型中特别定义了一条宽松的规定:允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行,即允许虚拟机自行选择是否要保证64位数据类型的load、store、read、和write这四个操作的原子性,这就是所谓的“long 和 double的非原子协定”。 从JDK9开始,HotSpot增加了一个实验性的参数-XX:+AlwaysAtomicAccesses 来约束虚拟机堆所有数据类型进行原子性的访问。另外由于现代中央处理器中一般都包含专门用于处理浮点数据的浮点运算器,所以在实际开发中,除非该数据有明确可知的线程竞争,否则一般不用刻意的把long和double类型的变量声明为volatile。
Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这三个特征来建立的。
由Java内存模型来直接保证的原子性变量操作包括read
、load
、assign
、use
、store
和write
这六个,我们大致可以认为,基本数据类型的访问、读写都是具备原子性的。
如果需要一个更大范围的原子性保证,Java内存模型还提供了lock
和unlock
操作来满足这种需求,这两个操作更高层次的字节码指令是monitorenter
和monitorexit
来隐式地使用这两个操作。这两个操作反应到Java代码中就是synchronized
关键字,所以synchronized
代码块之间的操作也具备原子性。
可见性就是指当一个线程修改了共享变量值时,其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存,在变量读取前从主内存刷新变量这种依赖主内存作为传递媒介的方式来实现可见性,无论是普通变量还是volatile变量都是如此。区别就在于volatile的特殊规则保证了新值能立即同步到主内存,以及每次使用前立即从主内存刷新。
除了volatile之外,Java还有两个关键字能实现可见性,他们是synchronized
和final
。synchronized
的可见性是由“对一个变量执行unlock操作之前,必须先把此变量同步回主内存中(执行store、write操作)”这条规则获得的。
final关键字的可见性是指:被final修饰的字段在构造器中一旦被初始化完成,并且构造器没有吧“this”的引用传递出去,那么在其他线程中就能看见final字段值。
Java程序中的有序性可以总结为一句话:如果在本线程内观察,所有的操作都是有序的;如果在一个线程中观察另一个线程,所有的操作都是无序的。
Java语言提供了volatile
和synchronized
两个关键字拉保证线程之间操作的有序性,volatile
关键字本身就包含了禁止指令重排序的语义,而synchronized
则是由“一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则获得的,这个规则决定了持有同一个锁的两个同步块只能串行地进入。
Java语言中有一个“先行发生”(Happens-Before)的原则。这个原则非常重要,它是判断数据是否存在竞争,线程是否安全的非常有用的手段。 先行发生原则是Java内存模型中定义的两项操作之间的偏序关系,例如操作A先行发生于操作B,其实就是说在发生操作B之前,操作A产生的影响能被操作B观察到,“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。
下面几项规则是Java内存模型中“天然的”先行发生关系,可以直接在代码中使用。如果两个操作之间的关系不在此列,并且无法从下列规则推导出来,则它们就没有顺序性保障,虚拟机可以对它们随意地进行重排序。
举个例子说明如何判断操作间是否具备顺序性,对于读写共享变量的操作来说,就是线程是否安全。
public class HappensBeforeTest {
private int item = 1;
public int getItem() {
return item;
}
public void setItem(int item) {
this.item = item;
}
}
上面的代码,假设线程A(时间上的先后)先调用了setItem(2)
,然后线程B调用了同一个对象的getItem()
。
先分析一下,由于两个方法不在一个线程中,所以程序次序规则不适用;没有同步块,所以管程锁定规则也不适用;item没有被volatile关键字修饰,所以volatile变量规则不适用;后面的线程启动、终止、中断规则和对象终结规则也和这没关系。因为之前也没有一个适用的先行发生规则,所以也没有传递性规则;
所以我们判定,尽管线程A操作时间上先于线程B,但是无法确定线程B中getItem()方法的返回结果,也就是这里面的操作不是线程安全的。
修复方式有多种,例如把getter/setter方法都加上synchronized,这样符合管程锁定规则;要么把item设置成volatile变量;要么等setter方法执行完成后再指向getter方法,符合程序次序规则。
既然一个操作在“时间上的先发生”不代表这个操作会是“先行发生”。那么一个操作“先行发生”是否就能推导出这个操作必定是“时间上的先行发生”呢?
还是举例说明吧
// 以下操作在同一个线程中执行
int item = 1;
int value = 2;
根据程序次序规则,int item = 1;
的操作先行发生于int value = 2;
,但是int value = 2;
的代码完全可能先被处理器执行,这并不影响先行发生原则的正确性。
所以经过上面两个论证,得出时间先后顺序与先行发生原则之间基本没有因果关系,在衡量是否线程安全时,一切必须以先行发生原则为准。