一,一段代码引发可见性思考
1,代码片段:从代码可以看出,子线程会一直在循环中阻塞,当主线程已经修改flag的值为true后,子线程并没有对flag值做同步修改。当给flag加上volatile关键字修饰后,则子线程会获取到最新的flag值,并打印出结果(不做演示)
package com.gupao;
/**
* @author pj_zhang
* @create 2019-09-07 20:50
**/
public class VolatileTest {
// 初始化表示位
private static boolean flag = false;
private static int i;
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
while (!flag) {
i++;
}
System.out.println("子线程执行完成: i = " + i);
}, "线程_1").start();
// 等待100毫秒,保证子线程已经加载flag值到线程高速缓存区
Thread.sleep(100);
// 修改flag为true
flag = true;
System.out.println("主线程执行完成。。。");
}
}
二,从硬件层面了解可见性本质
1,缓存一致性
1.1,在计算机迭代发展中,CPU、内存和I/O设备有一个非常核心的矛盾点,即三者的处理速度的差异(CPU > 内存 > I/O)。为了提升计算性能,CPU从单核升级到多核甚至使用超线程技术最大化提高CPU的处理性能,但是后面两者的速度没有跟上CPU的速度。为了平衡三者的速度差异,最大化的利用CPU的计算性能,从硬件,操作系统,编译器等方面做了很大优化
a,CPU增加了高速缓存
b,操作系统增加了线程和进程,通过CPU的时间片切换最大限度的提升CPU的使用率
c,编译器的指令优化,更合理的去利用好CPU的告诉缓存
但是每一种优化,都会带来线程安全性问题,这也是可见性的本质
1.2,CPU高速缓存
a,因为CPU计算速度与内存或者I/O计算速度差异,现代计算机都会增加一层读写速度尽可能接近CPU运算速度的高速缓存,以此来作为CPU和内存之间的缓冲:将线程使用到的数据复制到高速缓存中,等运算结束后再从高速缓存同步到主内存。
b,通过CPU高速缓存确实最大化解决了CPU和主内存间的运行差异,但是同时增加了计算机系统的复杂度,带来了缓存一致性的问题。在多CPU环境下,在同一主内存中的数据可能会被多核CPU共享,如果运行在多核CPU的多线程加载到各自CPU高速缓存中的数据,并各自进行修改,则可能存在缓存不一致问题。为了解决缓存不一致问题,CPU层面提供了两种解决方式
* 总线锁:即对主内存加锁,各个CPU在进行数据处理时串行执行,如Synchornized那样。这种方式在一定程度上抹杀了多核CPU的优势,显然是不合适的
* 缓存锁:基于MESI缓存一致性协议
1.3,缓存一致性协议 -- MESI
a,MESI状态详解
* M(Modify):缓存修改,表示缓存在当前CPU高速缓存中的数据已经被修改,即缓存数据与主内存数据不一致;如果存在其他CPU同时缓存该数据,则数据状态置为I(Invalid)
* E(Exclusive):缓存独占,数据只缓存在当前CPU高速缓存中,并且没有被修改
* S(Shard):缓存共享,表示多个CPU高速缓存同时缓存当前数据
* I(Invalid):缓存实效,当前CPU高速缓存缓存数据状态为S(Shard),且存在其他CPU高速缓存数据已经被修改M(Modify),则设置其他CPU高速缓存中该数据状态为I(Invalid)
b,MESI状态转换
* 在MESI协议中,每一个缓存的缓存控制器不仅知道当前缓存的读写操作,同时也需要监听其他CPU高速缓存的操作,进行状态变更
* 单个CPU从主内存缓存数据到高速缓存,此时高速缓存的数据状态为E(Exclusive)
* 多个CPU同时从主内存中缓存数据到高速缓存,此时高速缓存的数据状态为S(Shard)
* CPU对高速缓存中的数据进行修改,则数据状态修改为M(Modify)。此时,如果之前数据状态为E(Exclusive),则直接修改状态为M(Modify)(E -> M)。如果之前数据状态为S(Shard),则修改当前CPU高速缓存中该数据状态为M(Modify)(S -> M),同时发送消息到其他CPU,通知其他CPU修改高速缓存中该数据状态为I(Invalid)(S -> I)
* CPU读请求:高速缓存中数据状态为M(Modify),E(Exclusive),S(Shard)的数据都可以被读取,I(Invalid)状态数据需要从主内存中重新读取
* CPU写请求:高速缓存中数据状态为M(Modify),E(Exclusive)的数据都可以被直接写到主内存,S(Shard)状态的数据写操作,需要通知其他CPU修改高速缓存中该数据状态为I(Invalid)
1.4,缓存一致性带来的问题
* 在状态修改时,各个CPU修改状态是通过传递消息进行的。如果此时一个CPU进行了数据变更,则需要通知其他CPU将高速缓存中的数据状态置为无效,并且到等到各个CPU的确认回执。在这个阶段,当前CPU一直处于阻塞状态。
* 为了避免阻塞带来的CPU资源浪费,在CPU中引入了Store Bufferes
2,Store Bufferes
1.1,Store Bufferes发送消息流程
* CPU在写入共享数据时,直接将数据写入到Store Bufferes中,同时发送 Invalidate 消息,然后去处理其他指令(CPU去阻塞)
* 接收到其他CPU返回的 invalidate acknowledge 后,再将Store Bufferes中的数据存储至CPU高速缓存
* 最终再从CPU高速缓存中同步数据到主内存
1.2,Store Bufferes存在问题
* 加入Store Bufferes流程后,CPU取数据增加了一道流程,需要先从Store Bufferes中获取被修改的数据,如果Store Bufferes中不存在该数据,则继续到CPU高速缓存或者主内存中去取数据
* 因为加入Store Bufferes并发送消息,再到接收到ACK回执进行数据同步完全是异步操作,数据提交时间不确定,这就会造成CPU的指令重排问题
3,CPU指令重排问题
1.1,从一张图开始思考;多核多线程下,下图断言的执行结果可能会是 false
* 在上图中,对于成员变量 value = 3,在多核CPU下,该值被多个CPU加载后,在各个CPU高速缓存中数据状态为S(Shard)
* 此时CPU0对 value 值进行修改,在CPU0中,该值状态为M(Modify)。修改完成后,CPU0需要发消息通知其他CPU将高速缓存中该值状态修改为I(Invalid)。此时,CPU0需要做两件事情:1)将 (value = 10)存储到Store BUfferes中;2)发送Invalidate消息。之后,CPU0继续向下执行,执行语句(isFinsh = true, isFinsh状态为E(Exclusive)时会直接写入到主内存),此时各个CPU还没有返回ACK回执,Stroe Bufferes中的数据并没有写入到高速缓存和主内存
* 此时存在CPU1执行 if 判断,从主内存获取到 isFinsh 的最新值 true,接着执行 assert value == 3,但是此时由于CPU0修改的 value 值还没有同步到主内存,则对于 CPU1来讲,value值依旧为3,则执行结果为false。在显式上看,好像CPU0先执行了( isFinsh = true),然后在没有执行(value = 10)时,CPU1线程已经抢先执行,所以执行结果为false,这就是CPU的指令重排序
4,CPU层面的内存屏障
4.1,硬件层面优化到这种程度,就目前技术来看,已经没有了优化空间。但是还是不符合功能要求,那就需要硬件层面上添加指令处理。所以,在CPU层面上提供了Memory Barrier(内存屏障)的指令,这个指令就是用来(flush store bufferes)中的指令,软件层面可以在合适的地方加入内存屏障(volatile是加入了storeload屏障)。CPU层面提供了三种屏障:
* 写屏障(Store Barrier):写屏障之前的已经存储到Store Buffer的数据同步到主内存
* 读屏障(Load Barrier):读屏障之后的读操作, 都在读屏障之后执行, 配合写屏障, 使得写屏障之前的内存更新对于读屏障之后的操作都是可见的
* 全屏障(Full Barrier): 确保屏障前的读写操作全部更新到主内存后, 再进行屏障后的读写操作
三,JMM(Java Memory Model)-- java内存模型
1,JMM内存模型:就是一种符合内存模型规范的,屏蔽了各种硬件和操作系统的访问差异的,保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。JMM实际上就是提供了合理的禁用缓存和禁用重排序的方法。最核心的价值在于解决可见性和有序性
2,JMM解决重排序问题
2.1,为了提升程序的执行性能,编译器和处理器都会对指令做重排序,处理器的重排序前面已经分析。编译器的重排序值程序编写的指令在编译之后,会产生重排序来优化程序的执行性能。从源代码到最终执行的指令,可能会经过三种重排序
2.2,1属于编译器的重排序,JMM提供了禁止特定类型的编译器重排序
2.3,2和3属于处理器的重排序,JMM会要求编译器生成指令时,插入内存屏障来保障处理器重排序(例如volatile的storeLoad),当然并不是所有指令都会被重排序,符合Happen-Before规则的不会参与重排序
3,JMM层面内存屏障
* loadload():读屏障
* storestore():写屏障
* loadStore():读写屏障
* storeLoad():写读屏障
4,Volatile关键字使用了 storeload() 内存屏障,在JVM层面进行了内存屏障处理,保证了可见性和有序性
四,HappenBefore
1,它的意思表示的是前一个操作的结果对于后续操作是可见的,所以它是一种表达多个线程之间对于内存的可见性。所以我们可以认为在 JMM 中,如果一个操作执行的结果需要对另一个操作可见,那么这两个操作必须要存在happens before 关系 。 这两个操作可以是同一个线程,也可以是不同的线程
2,能建立Happens-Before原则的操作
* 程序的顺序规则
* volatile规则
* 传递性规则
* start()规则, 线程可见
* join()规则
* 监视器规则(锁规则)
五,Volatile可以保证线程的有序性和可见性,但是不能保证原子性。因为在多线程环境下,存在线程在写数据时,会产生并发覆盖场景
package com.gupao.concurrent;
/**
* @author pj_zhang
* @create 2019-09-26 22:26
**/
public class VolatileAddTest {
private static volatile int i = 0;
public static void main(String[] args) {
for (int count = 0; count < 100; count++){
new Thread(() -> {
i++;
}).start();
}
System.out.println(i);
}
}