Java并发编程底层原理篇1-Java内存模型之JMM
欢迎大家关注 github.com/hsfxuebao ,希望对大家有所帮助,要是觉得可以的话麻烦给点一下Star哈
0. 常见面试题
- 你知道什么是Java内存模型JMM吗?
- JMM与volatile 他们两个之间的关系吗?
- JMM有哪些特性or 它的三大特性是什么?
- 为什么要有JMM,它为什么出现?作用和功能是什么?
happens-bsfore先行先发生原则
你有了解过吗?
1. 计算机硬件存储体系
计算机存储结构,从本地磁盘到主存到CPU缓存,也就是从硬盘到内存,到CPU。一般对应的程序的操作就是从数据库查数据到内存然后到CPU进行计算。
因为有这么多级的缓存(cpu和物理主内存的速度不一致的),CPU的运行并不是直接操作内存而是先把内存里边的数据读到缓存
,而内存的读和写操作的时候就会造成不一致的问题。
Java虚拟机规范中试图定义一种Java内存模型(java Memory Model)简称JMM) 来屏蔽掉各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台下都能达到一致的内存访问效果。推导出我们需要知道JMM。
2. 内存模型抽象结构
线程间协作通信可以类比人与人之间的协作的方式,在现实生活中,之前网上有个流行语“你妈喊你回家吃饭了”,就以这个生活场景为例,小明在外面玩耍,小明妈妈在家里做饭,做晚饭后准备叫小明回家吃饭,那么就存在两种方式:
小明妈妈要去上班了十分紧急这个时候手机又没有电了,于是就在桌子上贴了一张纸条“饭做好了,放在...”小明回家后看到纸条如愿吃到妈妈做的饭菜,那么,如果将小明妈妈和小明作为两个线程,那么这张纸条就是这两个线程间通信的共享变量,通过读写共享变量实现两个线程间协作;
还有一种方式就是,妈妈的手机还有电,妈妈在赶去坐公交的路上给小明打了个电话,这种方式就是通知机制来完成协作。同样,可以引申到线程间通信机制。
通过上面这个例子,应该有些认识。在并发编程中主要需要解决两个问题:1. 线程之间如何通信;2.线程之间如何完成同步(这里的线程指的是并发执行的活动实体)。通信是指线程之间以何种机制来交换信息,主要有两种:共享内存和消息传递。这里,可以分别类比上面的两个举例。java内存模型是共享内存的并发模型,线程之间主要通过读-写共享变量来完成隐式通信。如果程序员不能理解Java的共享内存模型在编写并发程序时一定会遇到各种各样关于内存可见性的问题。
1.哪些是共享变量
在java程序中所有实例域,静态域和数组元素都是放在堆内存中(所有线程均可访问到,是可以共享的),而局部变量,方法定义参数和异常处理器参数不会在线程间共享。共享数据会出现线程安全的问题,而非共享数据不会出现线程安全的问题。关于JVM运行时内存区域在后面的文章会讲到。
2.JMM抽象结构模型
我们知道CPU的处理速度和主存的读写速度不是一个量级的,为了平衡这种巨大的差距,每个CPU都会有缓存。因此,共享变量会先放在主存中,每个线程都有属于自己的工作内存,并且会把位于主存中的共享变量拷贝到自己的工作内存,之后的读写操作均使用位于工作内存的变量副本,并在某个时刻将工作内存的变量副本写回到主存中去。JMM就从抽象层次定义了这种方式,并且JMM决定了一个线程对共享变量的写入何时对其他线程是可见的。
如图为JMM抽象示意图,线程A和线程B之间要完成通信的话,要经历如下两步:
- 线程A从主内存中将共享变量读入线程A的工作内存后并进行操作,之后将数据重新写回到主内存中;
- 线程B从主存中读取最新的共享变量
从横向去看看,线程A和线程B就好像通过共享变量在进行隐式通信。这其中有很有意思的问题,如果线程A更新后数据并没有及时写回到主存,而此时线程B读到的是过期的数据,这就出现了“脏读”现象。可以通过同步机制(控制不同线程间操作发生的相对顺序)来解决或者通过volatile关键字使得每次volatile变量都能够强制刷新到主存,从而对每个线程都是可见的。
3. 重排序
一个好的内存模型实际上会放松对处理器和编译器规则的束缚,也就是说软件技术和硬件技术都为同一个目标而进行奋斗:在不改变程序执行结果的前提下,尽可能提高并行度。JMM对底层尽量减少约束,使其能够发挥自身优势。因此,在执行程序时,为了提高性能,编译器和处理器常常会对指令进行重排序。一般重排序可以分为如下三种:
- 编译器优化的重排序。编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序;
- 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序;
- 内存系统的重排序。由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行的。
如图,1属于编译器重排序,而2和3统称为处理器重排序。这些重排序会导致线程安全的问题,一个很经典的例子就是DCL问题,这个在以后的文章中会具体去聊。针对编译器重排序,JMM的编译器重排序规则会禁止一些特定类型的编译器重排序;针对处理器重排序,编译器在生成指令序列的时候会通过插入内存屏障指令来禁止某些特殊的处理器重排序。
那么什么情况下,不能进行重排序了?下面就来说说数据依赖性。有如下代码:
double pi = 3.14 //A
double r = 1.0 //B
double area = pi * r * r //C
这是一个计算圆面积的代码,由于A,B之间没有任何关系,对最终结果也不会存在关系,它们之间执行顺序可以重排序。因此可以执行顺序可以是A->B->C或者B->A->C执行最终结果都是3.14,即A和B之间没有数据依赖性。具体的定义为:如果两个操作访问同一个变量,且这两个操作有一个为写操作,此时这两个操作就存在数据依赖性这里就存在三种情况:1. 读后写;2.写后写;3. 写后读,者三种操作都是存在数据依赖性的,如果重排序会对最终执行结果会存在影响。编译器和处理器在重排序时,会遵守数据依赖性,编译器和处理器不会改变存在数据依赖性关系的两个操作的执行顺序
另外,还有一个比较有意思的就是as-if-serial语义。
as-if-serial
as-if-serial语义的意思是:不管怎么重排序(编译器和处理器为了提供并行度),(单线程)程序的执行结果不能被改变。编译器,runtime和处理器都必须遵守as-if-serial语义。as-if-serial语义把单线程程序保护了起来,遵守as-if-serial语义的编译器,runtime和处理器共同为编写单线程程序的程序员创建了一个幻觉:单线程程序是按程序的顺序来执行的。比如上面计算圆面积的代码,在单线程中,会让人感觉代码是一行一行顺序执行上,实际上A,B两行不存在数据依赖性可能会进行重排序,即A,B不是顺序执行的。as-if-serial语义使程序员不必担心单线程中重排序的问题干扰他们,也无需担心内存可见性问题。
4. Java内存模型JMM
JMM(Java内存模型Java Memory Model
,简称JMM
)本身是一种抽象的概念
并不真实存在它仅仅描述的是一组约定或规范
,通过这组规范定义了程序中(尤其是多线程)各个变量的读写访问方式并决定一个线程对共享变量的写入何时以及如何变成对另一个线程可见,关键技术点都是围绕多线程的原子性、可见性和有序性
展开的。
原则:JMM的关键技术点都是围绕多线程的原子性、可见性和有序性
展开的
能干嘛?
- 通过JMM来实现
线程和主内存之间的抽象关系
。 屏蔽各个硬件平台和操作系统的内存访问差异
以实现让Java程序在各种平台下都能达到一致的内存访问效果。
4.1 三大特性
4.1.1 可见性
是指当一个线程修改了某一个共享变量的值,其他线程是否能够立即知道该变更
,JMM规定了所有的变量都存储在主内存
中。
Java中普通的共享变量不保证可见性
,因为数据修改被写入内存的时机是不确定的,多线程并发下很可能出现"脏读",所以每个线程都有自己的工作内存
,线程自己的工作内存中保存了该线程使用到的变量的主内存副本拷贝
,线程对变量的所有操作(读取,赋值等 )都必需在线程自己的工作内存中进行,而不能够直接读写主内存中的变量。不同线程之间也无法直接访问对方工作内存中的变量,线程间变量值的传递均需要通过主内存来完成。
线程脏读:如果没有可见性保证
4.1.2 原子性
指一个操作是不可中断的,即多线程环境下,操作不能被其他线程干扰。
4.1.3 有序性
对于一个线程的执行代码而言,我们总是习惯性认为代码的执行总是从上到下,有序执行。但为了提供性能,编译器和处理器通常会对指令序列进行重新排序。
指令重排可以保证串行语义一致
,但没有义务保证多线程间的语义也一致
,即可能产生"脏读",简单说,两行以上不相干的代码在执行的时候有可能先执行的不是第一条,不见得是从上到下顺序执行,执行顺序会被优化
。
单线程环境里面确保程序最终执行结果和代码顺序执行的结果一致。处理器在进行重排序时必须要考虑
指令之间的数据依赖性
。
多线程环境中线程交替执行,由于编译器优化重排的存在,两个线程中使用的变量能否保证一致性是无法确定的,结果无法预测。
简单案例先过个眼熟
public void mySort()
{
int x = 11; //语句1
int y = 12; //语句2
x = x + 5; //语句3
y = x * x; //语句4
}
执行结果:
1234
2134
1324
问题:请问语句4可以重排后变成第一条吗?肯定不行,因为存在数据依赖性
4.2 JMM规范下,多线程对变量的读写过程
4.2.1 读取过程
由于JVM运行程序的实体是线程,而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间),工作内存是每个线程的私有数据区域,而Java内存模型中规定所有变量都存储在主内存
,主内存是共享内存区域,所有线程都可以访问,但线程对变量的操作(读取赋值等)必须在工作内存中进行,首先要将变量从主内存拷贝到的线程自己的工作内存空间,然后对变量进行操作,操作完成后再将变量写回主内存
,不能直接操作主内存中的变量,各个线程中的工作内存中存储着主内存中的变量副本拷贝
,因此不同的线程间无法访问对方的工作内存,线程间的通信(传值)必须通过主内存来完成,其简要访问过程如下图:

JMM定义了线程和主内存之间的抽象关系:
- 线程之间的共享变量存储在主内存中(从硬件角度来说就是内存条)
- 每个线程都有一个私有的本地工作内存,本地工作内存中存储了该线程用来读/写共享变量的副本(从硬件角度来说就是CPU的缓存,比如寄存器、L1、L2、L3缓存等)
4.2.2 小总结
- 我们定义的所有共享变量都储存在
物理主内存
中 - 每个线程都有自己独立的工作内存,里面保存该线程使用到的变量的副本(主内存中该变量的一份拷贝)
- 线程对共享变量所有的操作都必须先在线程自己的工作内存中进行后写回主内存,不能直接从主内存中读写(不能越级)
- 不同线程之间也无法直接访问其他线程的工作内存中的变量,线程间变量值的传递需要通过主内存来进行(同级不能相互访问)
5. 多线程先行发生原则之happens-before
在JMM中,如果一个操作执行的结果需要对另一个操作可见性或者代码重排序
,那么这两个操作之间必须存在happens-before
关系。
x 、y案例说明如下:
x=5 | 线程A执行 |
y=x | 线程B执行 |
上述称为:写后读 |
存在的问题:
- y是否等于5呢?
- 如果线程A的操作(x= 5)happens-before(先行发生)线程B的操作(y = x),那么可以确定线程B执行后y = 5 一定成立;
- 如果他们不存在happens-before原则,那么y = 5 不一定成立。
- 这就是happens-before原则的威力。---->>
包含可见性和有序性的约束
先行发生原则说明:
- 如果Java内存模型中所有的有序性都仅靠
volatile
和synchronized
来完成,那么有很多操作都将会变得非常啰嗦,但是我们在编写Java并发代码的时候并没有察觉到这一点。 - 我们没有
时时、处处、次次,添加volatile和synchronized来完成程序,这是因为Java语言中JMM原则下有一个“先行发生”(Happens-Before)的原则限制和规矩
这个原则非常重要
,它是判断数据是否存在竞争,线程是否安全的非常有用的手段。依赖这个原则,我们可以通过几条简单规则一揽子解决并发环境下两个操作之间是否可能存在冲突的所有问题
,而不需要陷入Java内存模型苦涩难懂的底层编译原理之中。
happens-before总原则
- 如果一个操作
happens-before
另一个操作,那么第一个操作的执行结果将对第二个操作可见,而且第一个操作的执行顺序排在第二个操作之前。 - 两个操作之间存在
happens-before
关系,并不意味着一定要按照happens-before
原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before
关系来执行的结果一致
,那么这种重排序并不非法
。
下面我们来看这8条原则:
5.1 次序规则
一个线程内
,按照代码顺序,写在前面的操作先行发生于写在后面的操作;
加深说明:前一个操作的结果可以被后续的操作获取。讲白点就是前面一个操作把变量X赋值为1,那后面一个操作肯定能知道X已经变成了1。
5.2 锁定规则
一个unLock操作先行发生于后面((这里的“后面”是指时间上的先后))对同一个锁的lock操作;
public class HappenBeforeDemo
{
static Object objectLock = new Object();
public static void main(String[] args) throws InterruptedException
{
//对于同一把锁objectLock,threadA一定先unlock同一把锁后B才能获得该锁, A 先行发生于B
synchronized (objectLock)
{
}
}
}
5.3 volatile变量规则
对一个volatile变量的写操作先行发生于后面对这个变量的读操作,前面的写对后面的读是可见的
,这里的“后面”同样是指时间上的先后。
5.4 传递规则
如果操作A先行发生于操作B,而操作B又先行发生于操作C,则可以得出操作A先行发生于操作C;
5.5 线程启动规则(Thread Start Rule)
Thread对象的start()
方法先行发生于此线程的每一个动作
5.6 线程中断规则(Thread Interruption Rule)
对线程interrupt()
方法的调用先行发生于被中断线程的代码检测到中断事件的发生;对线程interrupt()
方法的调用先行发生于被中断线程的代码检测到中断事件的发生;
5.7 线程终止规则(Thread Termination Rule)
线程中的所有操作都先行发生于对此线程的终止检测,我们可以通过Thread::join()
方法是否结束、Thread::isAlive()
的返回值等手段检测线程是否已经终止执行。
5.8 对象终结规则(Finalizer Rule)
一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()
方法的开始,即对象没有完成初始化之前,是不能调用finalized()
方法的
5.9 案例说明
private int value = 0;
public void setValue(int value){
this.value = value;
}
public int getValue(){
return value;
}
假设存在线程A和B,线程A先(时间上的先后)调用了setValue(1),然后线程B调用了同一个对象的getValue(),那么线程B收到的返回值是什么?
我们就这段简单的代码一次分析happens-before的规则
(规则5、6、7、8 可以忽略,因为他们和这段代码毫无关系):
- 由于两个方法是由不同的线程调用,不在同一个线程中,所以肯定不满足程序次序规则;
- 两个方法都没有使用锁,所以不满足锁定规则;
- 变量不是用volatile修饰的,所以volatile变量规则不满足;
- 传递规则肯定不满足;
所以我们无法通过happens-before原则
推导出线程A happens-before线程B
,虽然可以确认在时间上线程A优先于线程B指定,但就是无法确认线程B获得的结果是什么
,所以这段代码不是线程安全的。那么怎么修复这段代码
呢?
- 把
getter/setter
方法都定义为synchronized
方法 - 把value定义为
volatile
变量,由于setter方法对value的修改不依赖value的原值,满足volatile
关键字使用场景
参考资料
Java并发编程知识体系 Java并发编程的艺术 Java多线程编程核心技术 Java并发实现原理 JDK源码剖析
转载自:https://juejin.cn/post/7074933850215809061