彻底理解Java内存模型,它为什么会引发线程安全问题【吐血总结】

并发编程 同时被 2 个专栏收录
9 篇文章 54 订阅
33 篇文章 81 订阅

近日,有热心市民就 "Java内存模型 " 提出质疑: 线程是否会把所有需要操作的数据全加载到内存
在这里插入图片描述
根据《我是憨包》可以看出,当事人蛋蛋(化名)目前情绪稳定,并且似乎已经意识到问题所在

是的,聪明的蛋蛋已经找到了答案(答案后面再说)


此事件发生后,群内大佬高度重视,立即召开线上会议,成立Java内存模型专家小组作出响应,要求组织迅速,妥善处理,迅速查清问题根源,立即组织开展在线答疑,进一步做好指导工作,防止同样问题再次出现,阻挠兄弟们拿到心仪offer

一想到很多朋友还没搞懂Java内存模型,我就饭吃不饱觉睡不着,就连看到黑丝也无动于衷

于是

又花了几天时间 又花了几根头发,来尝试帮大家理解一波~

关于Java内存模型,能扯好多好多、能聊好远好远,但是不要慌,我们整理下问题先:

  • 什么是Java内存模型?
  • 为什么会有Java内存模型?
  • Java内存模型引发了什么问题?
  • 线程是否会把所有需要操作的数据全加载到内存?

据当事人陈述:

线程在操作数据时,会从主内存中拷贝一份数据副本到自己的工作内存,操作完再写回主内存,那如果这个数据超级大,也会拷贝到工作内存中吗?

要想弄清这个问题,我们必须先研究下什么是Java内存模型


很多同学会把 Java内存模型 和 JVM内存模型 搞混,这是两种截然不同的东西

Java内存模型:全称Java Memory Model,简称JMM,是一种虚拟机规范,下面会详细讲;
JVM内存模型:全称Java Virtual Machine,简称JVM,也是一种虚拟机规范,关于jvm本文不会展开讲;

如果想开发一款能运行Java程序的虚拟机,就必须遵循这两个规范(当然需要遵循的规范远不止这两种),只有这样,java程序才能在你的虚拟机上开开心心的run,我们最最最最常见的hotspot vm就遵循了这些规范;

Java内存模型的由来

在这里插入图片描述

说来话长
在这里插入图片描述
我长话短说吧

问题起源

这牵涉到CPU厂商和内存厂商的发展史。。。

我们鸡道,cpu在执行指令的时候,经常需要操作内存中的数据

为了方便理解,我举个栗子,拿 i = i + 1来讲

cpu先要从内存中读取到 i 当前的值,进行 +1 ,再将计算结果写回内存
在这里插入图片描述

最开始一切安好,但随着技术的发展,cpu执行效率远远超过了内存的读写效率,所以出现了一个现象

cpu执行 +1 操作耗时很短,假设只需要1ms,而从内存中读取 i ,再写回内存,耗时很长,假设是10ms

cpu明明只需要1ms,活生生被内存拖到11ms,这哪儿顶得住啊

于是,机智的cpu厂想了个办法

解决办法

这个办法在《深入理解Java虚拟机》书中也有提到
在这里插入图片描述

简单来说就在cpu和内存中间加一层 高速缓存,也就是我们平时说的L1、L2、L3缓存,这一块缓存一般比较小,但嗷嗷快,你懂我意思吧

注意:知识点来了,一定要把cpu的高速缓存和内存条的内存区分开

这是内存条的内存(系统属性中可以查看)
在这里插入图片描述

这是cpu的高速缓存(任务管理器-性能一栏可以查看到)
在这里插入图片描述

所以现在操作流程变成了:

cpu会事先将需要用到的数据从主内存中复制一份到高速缓存,cpu在执行计算操作时,依次从L1、L2、L3级缓存中查找,如果有需要的数据,直接操作,计算结束后再flush到主内存中;如果没有,再去主内存中查找

在这里插入图片描述

cpu被内存拉低效率的问题得以解决

时间又过了很久。。。

cpu厂商推出了多核处理器,又引出了另一个问题: 线程安全

多核处理器的每个核心都有自己的高速缓存(每个cpu架构都不同,要具体看cpu厂商怎么做,目前市面上的cpu一般都是L1、L2独立,L3共享)

上面可以看到我cpu的L1缓存是384k,这384k并不是六个核共享,而是 6 * 32 * 2,如下图
在这里插入图片描述

现在,架构变成了
在这里插入图片描述
(这个图是简化版,实际的架构图比这复杂得多,那些细节我懒的画了)

所以,现在问题来了,如果不同核心上的线程同时操作同一个数据,会出现什么问题?

我们假设一下

核心a有个线程t1,核心b有个线程t2
开始计算前,内存中 i 的值是0,两线程对应高速缓存中 i 的值也都是0
某一时刻,两线程同时执行 i + 1
t1执行完 i = 1,吭呲吭呲写回内存,此时内存中 i 的值已经由0变为了1
t2执行完 i 也 = 1,也吭呲吭呲把i = 1写回内存,这就把t1写回的新 i 值覆盖了

本来 i 经过两次+1应该等于2,实际结果却等于1,懂我意思吗,大多数并发编程中的数据异常问题都是这么来的

所以,并发编程中,只要涉及到写的操作,我们都应该保证同步,从而得到可靠的最终数据

到这里,我们可以总结下什么内存模型

什么是Java内存模型

由上面的架构图可见,线程需要

上面说了,Java内存模型就是一种协议;线程要操作数据,需要先从主内存中读取到工作内存,操作完再写回主内存,看起来简单,但这之间有很多底层技术细节,比如:
什么时候读取?
又什么时候写入?
多个线程共同读写时又该如何调配?
所以问题来了,一台服务器上的cpu和内存可能是由不同厂商提供的,如果它们的底层实现细节对不上,那怎么保证程序能够正常运行?不可能每次设计产品时都把所有厂商拉一起开个会吧,所以,为了方便,为了统一,有了Java内存模型,它被用来 规范不同硬件和操作系统在内存读写底层实现上的差异
只有屏蔽这些差异,Java才能实现 一次编译、处处运行


又回到最初的起点、记忆中你青涩的脸~
现在公布答案
在这里插入图片描述

说到这儿,再扯一嘴cpu更底层的冷知识

指令重排

并发编程中,除了Java内存模型带来的线程安全问题,cpu、虚拟机自身也存在类似问题

  • 关于cpu:为了从分利用cpu,实际执行指令时会做优化
  • 关于虚拟机:在HotSpot vm中,为了提升执行效率,JIT(即时编译)模式也会做指令优化

指令重排在大部分场景下确实能提升效率,但有些操作对代码执行顺序是强依赖的,此时我们需要关闭指令重排,相信很多朋友已经猜到了

没错,就是volatile

关于volatile,想要彻底理解,也得扯很多很多,此处就不扯了,改天单独写一篇

举个例来说明什么指令重排,及如何防范:
在这里插入图片描述
这个伪代码取自《深入理解Java虚拟机》:
其中描述的场景是开发中常见配置读取过程,只是我们在处理配置文件时一般不会出现并发,所以没有察觉这会有问题。
试想一下,如果定义initialized变量时没有使用volatile修饰,就可能会由于指令重排序的优化,导致位于线程A中最后一条代码“initialized=true”被提前执行(这里虽然使用Java作为伪代码,但所指的重排序优化是机器级的优化操作,提前执行是指这条语句对应的汇编代码被提前执行),这样在线程B中使用配置信息的代码就可能出现错误,而volatile关键字则可以避免此类情况的发生


ok我话说完

评论62
请先登录 后发表评论~
©️2021 CSDN 皮肤主题: 终极编程指南 设计师:CSDN官方博客 返回首页

打赏作者

负债程序猿

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值