进程与线程
进程是程序执行的最小单位
线程是cpu调度的最小单位
多线程硬件模型
读与返回的过程比较缓慢,通过总线
L1、L2、L3三级缓存,速度依次减,容量依次加
计算单元要读取数据顺序为L1、L2、L3、内存
可见性问题
内存有数据count=1,cpu0、cpu1把内存中的count缓存到本地,都要做count++,此时都返回给内存,两遍count++最终结果却是count=2
方案:
- 总线上锁:变成串行,多线程没意义了
- 数据一致性的缓存锁
缓存锁
MESI协议(修改、独占、共享、失效)
- cpu0、cpu1都加载count到自己缓存,本质上都是主存里count的副本,count为S状态
- cpu0想count++,cpu0将本地的count改成M状态,cpu0通知所有有这个count副本的其他线程(如cpu1),使其失效
- cpu1接到通知的把本地count改成I状态并且把修改结果返回给cpu0
- cpu0收到返回后把count++后的新结果返回给主存,把本地count改成E状态
- cpu1这时要做count++会发现本地count变成I状态,需要到主存中取
M-E状态之间,cpu类似阻塞;写操作放入storebuffer、读操作放入loadbuffer
那什么样的数据需要缓存?缓存中数据长什么样呢?
局部性原理
时间局部性:主存中有x,cpu加载x到缓存,认为接下来的操作都需要用到x
空间局部性:两个数据(x,y)在主存中空间上挨在一起,cpu需要用到x,但认为接下来的操作也需要用到y。加载的时候就把(x,y)都加载到缓存行(64字节)。由于存在MESI协议,导致x,y互相锁,即伪共享。
伪共享
可以在代码部分解决
第二种其实在优化伪共享,long8个字节,前后加8个long隔离,避免走MESI协议,影响效率
解决
硬件层面,即cpu处理器上,有memorybarrier
软件层面,JVM规范汇总,有四种内存屏障(LoadLoadBarries、storestore、loadstore、storeload)->JMM模型(JVM中的一种规范,规范了java虚拟机和计算机内存如何协同共存)
JMM模型
JMM指令
lock作用于主内存,标记变量只能被一条线程读取
read、load不能单独使用,read+load将变量加载到高速缓存中来
JVM层面完成了以上这些指令,用java线程和内存完成读写操作,并且加上一些内存屏障
volatile、sync、final关键字
顺序性问题
指令重排序
由于有storebuffer存在,buffer的存在使得一些写操作在storebuffer中进行,而一些写操作是直接写到内存中,无法保证storebuffer、内存里指令的顺序
解决
voliatle、sync
JAVA内存模型(多线程软件模型)
JMM模型
规范四种内存屏障LoadLoadBarries、StoreStoreLoadStore、StoreLoad
lock、sync、volatile实现了内存屏障
多线程三大核心性质
原子性、可见性、顺序性
Voliate(无法保证原子性)
本质:读前插入读屏障,写前插入写屏障,就可以解决可见性还有指令重排问题
源码
OrderAccess:storeload:万能屏障,即把写缓存数据全都刷新到内存中
linux86中storeload实现:
is_MP:是否是多cpu(多线程)
主要执行lock,锁住了0+0(语法规定,没什么实际意义)
为什么无法保证原子性
j++在底层是3条指令,读取——>加——>写入
而volatile是指令和指令之间加上内存屏障,所以无法保证原子性
new操作包含了4条指令
单例模式
多线程情况下,同时判断INSTANCE==null,就不是单例了
如何修改?
加锁
但是这个锁加的范围太大了,进一步优化
但这仍然有线程安全问题,同时会认为INSTANCE==null,锁住了但不影响另一个往下走
再加一层判断
双重检查锁单例模式。注意仍然具有线程安全问题。
INSTANCE关键字需不需要加上voliatle呢?
需要。因为注意new这步其实是4个指令,防止指令重排序