多线程原理深度剖析

进程与线程

进程是程序执行的最小单位
线程是cpu调度的最小单位

多线程硬件模型

读与返回的过程比较缓慢，通过总线
L1、L2、L3三级缓存，速度依次减，容量依次加
计算单元要读取数据顺序为L1、L2、L3、内存

可见性问题

内存有数据count=1，cpu0、cpu1把内存中的count缓存到本地，都要做count++，此时都返回给内存，两遍count++最终结果却是count=2

方案：

1. 总线上锁：变成串行，多线程没意义了
2. 数据一致性的缓存锁

缓存锁

MESI协议（修改、独占、共享、失效）

1. cpu0、cpu1都加载count到自己缓存，本质上都是主存里count的副本，count为S状态
2. cpu0想count++，cpu0将本地的count改成M状态，cpu0通知所有有这个count副本的其他线程（如cpu1），使其失效
3. cpu1接到通知的把本地count改成I状态并且把修改结果返回给cpu0
4. cpu0收到返回后把count++后的新结果返回给主存，把本地count改成E状态
5. 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个指令，防止指令重排序