进程与线程
进程是程序执行的最小单位
线程是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个指令，防止指令重排序
