volatile的作用
volatile可以是多处理器环境下保证共享变量的可见性
什么是线程的可见性?
在单线程的环境下,如果向一个变量先写入一个值,然后在没有写干涉的情况下读取这个变量的值,那这个时候读取到的这个变量的值应该是之前写入的那个值。这本来是一个很正常的事情。但是在多线程环境下,读和写发生在不同的线程中的时候,可能会出现:读线程不能及时的读取到其他线程写入的最新的值。这就是所谓的可见性为了实现跨线程写入的内存可见性,必须使用到一些机制来实现。而 volatile 就是这样一种机制
volatile是如何保证可见性的?
可以使用hsdis工具查看加了volatile代码的汇编指令,在输出结果中,会发现修改带有volatile修饰的成员变量是,会多出一个lock指令,lock是一种控制指令,在多处理器环境下,lock 汇编指令可以基于总线锁或者缓存锁的机制来达到可见性的一个效果。
硬件方面了解可见性的本质
一台计算器的最核心的组件的CPU,内存,以及I/O设备,这三者存在速度差异,CPU>内存>I/O
为了平衡三者的速度差异,最大化的利用CPU提升性能,,从硬件、操作系统、编译器等方面都做出了很多的优化
- CPU 增加了高速缓存
- 操作系统增加了进程、线程。通过 CPU 的时间片切换最大化的提升 CPU 的使用率
- 编译器的指令优化,更合理的去利用好 CPU 的高速缓存然后每一种优化,都会带来相应的问题,而这些问题也是导致线程安全性问题的根源
CPU高速缓存
线程是 CPU 调度的最小单元,线程设计的目的最终仍然是更充分的利用计算机处理的效能,但是绝大部分的运算任
务不能只依靠处理器“计算”就能完成,处理器还需要与内存交互,比如读取运算数据、存储运算结果,这个 I/O 操作是很难消除的。而由于计算机的存储设备与处理器的运算速度差距非常大,所以现代计算机系统都会增加一层读写速度尽可能接近处理器运算速度的高速缓存来作为内存和处理器之间的缓冲:将运算需要使用的数据复制到缓存中,让运算能快速进行,当运算结束后再从缓存同步到内存之中
通过高速缓存的存储交互很好的解决了处理器与内存的速度矛盾,但是也为计算机系统带来了更高的复杂度,因为它引入了一个新的问题,缓存一致性。
什么叫缓存一致性呢?
首先,有了高速缓存的存在以后,每个 CPU 的处理过程是,先将计算需要用到的数据缓存在 CPU 高速缓存中,在 CPU
进行计算时,直接从高速缓存中读取数据并且在计算完成之后写入到缓存中。在整个运算过程完成后,再把缓存中的数据同步到主内存。
由于在多 CPU 种,每个线程可能会运行在不同的 CPU 内,并且每个线程拥有自己的高速缓存。同一份数据可能会被缓存到多个 CPU 中,如果在不同 CPU 中运行的不同线程看到同一份内存的缓存值不一样就会存在缓存不一致的问题
为了解决缓存不一致的问题,在 CPU 层面做了很多事情,
主要提供了两种解决办法
- 总线锁
- 缓存锁
总线锁,简单来说就是,在多 cpu 下,当其中一个处理器要对共享内存进行操作的时候,在总线上发出一个 LOCK#信号,这个信号使得其他处理器无法通过总线来访问到共享内存中的数据,总线锁定把 CPU 和内存之间的通信锁住了,这使得锁定期间,其他处理器不能操作其他内存地址的数据
最好的方法就是控制锁的保护粒度,我们只需要保证对于被多个 CPU 缓存的同一份数据是一致的就行。所以引入了缓存锁,它核心机制是基于缓存一致性协议来实现的
缓存一致性协议
为了达到数据访问的一致,需要各个处理器在访问缓存时遵循一些协议,在读写时根据协议来操作,常见的协议有MSI,MESI,MOSI 等。最常见的就是 MESI 协议
MESI 表示缓存行的四种状态,分别是
M(Modify) 表示共享数据只缓存在当前 CPU 缓存中,并且是被修改状态,也就是缓存的数据和主内存中的数据不一致
E(Exclusive) 表示缓存的独占状态,数据只缓存在当前CPU 缓存中,并且没有被修改
S(Shared) 表示数据可能被多个 CPU 缓存,并且各个缓存中的数据和主内存数据一致
I(Invalid) 表示缓存已经失效在 MESI 协议中,每个缓存的缓存控制器不仅知道自己的读写操作,而且也监听(snoop)其它 Cache 的读写操作
对于 MESI 协议,从 CPU 读写角度来说会遵循以下原则:
CPU 读请求:缓存处于 M、E、S 状态都可以被读取,I 状 态 CPU 只能从主存中读取数据CPU 写请求:缓存处于 M、E 状态才可以被写。对于 S 状态的写,需要将其他 CPU 中缓存行置为无效才可写使用总线锁和缓存锁机制之后,CPU 对于内存的操作大概可以抽象成下面这样的结构。从而达到缓存一致性效果
MESI 优化带来的可见性问题
MESI 协议虽然可以实现缓存的一致性,但是也会存在一些
问题。
就是各个 CPU 缓存行的状态是通过消息传递来进行的。如 果 CPU0 要对一个在缓存中共享的变量进行写入,首先需要发送一个失效的消息给到其他缓存了该数据的 CPU。并且要等到他们的确认回执。CPU0 在这段时间内都会处于阻塞状态。为了避免阻塞带来的资源浪费。在 cpu 中引入了 Store Bufferes。
CPU0 只需要在写入共享数据时,直接把数据写入到 storebufferes 中,同时发送 invalidate 消息,然后继续去处理其他指令。
当收到其他所有 CPU 发送了 invalidate acknowledge 消息时,再将 store bufferes 中的数据数据存储至 cache line中。最后再从缓存行同步到主内存。
但是这种优化存在两个问题
- 数据什么时候提交是不确定的,因为需要等待其他 cpu给回复才会进行数据同步。这里其实是一个异步操作
- 引入了 storebufferes 后,处理器会先尝试从 storebuffer中读取值,如果 storebuffer 中有数据,则直接从storebuffer 中读取,否则就再从缓存行中读取
CPU 的乱序执行,也可以认为是一种重排序,而这种重排序会带来可见性的问题
CPU 层面提供了 memory barrier(内存屏障)的指令,从硬件层面来看这个 memroy barrier 就是 CPU flush store bufferes 中的指令。软件层面可以决定在适当的地方来插入内存屏障
CPU 层面的内存屏障
内存屏障就是将 store bufferes 中的指令写入到内存,从而使得其他访问同一共享内存的线程的可见性。X86 的 memory barrier 指令包括 lfence(读屏障) sfence(写屏障) mfence(全屏障)
Store Memory Barrier(写屏障) 告诉处理器在写屏障之前的所有已经存储在存储缓存(store bufferes)中的数据同步到主内存,简单来说就是使得写屏障之前的指令的结果对屏障之后的读或者写是可见的
Load Memory Barrier(读屏障) 处理器在读屏障之后的读操作,都在读屏障之后执行。配合写屏障,使得写屏障之前的内存更新对于读屏障之后的读操作是可见的
Full Memory Barrier(全屏障) 确保屏障前的内存读写操作
的结果提交到内存之后,再执行屏障后的读写操作
总的来说,内存屏障的作用可以通过防止 CPU 对内存的乱序访问来保证共享数据在多线程并行执行下的可见性
volatile 关键字的代码,这个关键字会生成一个 Lock 的汇编指令,这个指令其实就相当于实现了一种内存屏障
JMM(Java Memory Model)
可见性问题的根本原因是缓存以及重排序。
而 JMM 实际上就是提供了合理的禁用缓存以及禁止重排序的方法。所以它最核心的价值在于解决可见性和有序性
JMM 属于语言级别的抽象内存模型,可以简单理解为对硬件模型的抽象,它定义了共享内存中多线程程序读写操作的行为规范:在虚拟机中把共享变量存储到内存以及从内存中取出共享变量的底层实现细节
通过这些规则来规范对内存的读写操作从而保证指令的正确性,它解决了 CPU 多级缓存、处理器优化、指令重排序导致的内存访问问题,保证了并发场景下的可见性。
**注意:**JMM 并没有限制执行引擎使用处理器的寄存器或者高速缓存来提升指令执行速度,也没有限制编译器对指令进行重排序,也就是说在 JMM 中,也会存在缓存一致性问题和指令重排序问题。只是 JMM 把底层的问题抽象到 JVM 层面,再基于 CPU 层面提供的内存屏障指令,以及限制编译器的重排序来解决并发问题
JMM 抽象模型分为主内存、工作内存;主内存是所有线程共享的,一般是实例对象、静态字段、数组对象等存储在堆内存中的变量。工作内存是每个线程独占的,线程对变量的所有操作都必须在工作内存中进行,不能直接读写主内存中的变量,线程之间的共享变量值的传递都是基于主内存来完成
Java 内存模型底层实现可以简单的认为:通过内存屏障(memory barrier)禁止重排序,即时编译器根据具体的底层体系架构,将这些内存屏障替换成具体的 CPU 指令。对于编译器而言,内存屏障将限制它所能做的重排序优化。而对于处理器而言,内存屏障将会导致缓存的刷新操作。比如,对于 volatile,编译器将在 volatile 字段的读写操作前后各插入一些内存屏障。
JMM 是如何解决可见性有序性问题的
JMM 提供了一些禁用缓存以及进制重排序的方法,来解决可见性和有序性问题。这些方法大家都很熟悉:
volatile、synchronized、final;
JMM 如何解决顺序一致性问题
重排序
为了提高程序的性能,编译器和处理器都会对指令重排序,重排序就是指执行的指令顺序
编译器的重排序指的是程序编写的指令在编译以后可能会产生重排序来优化程序的执行性能
JMM层面的内存屏障
屏障类型 | 指令实例 | 备注 |
---|---|---|
LoadLoadBarriers | load;LoadLoad;load2 | 确保load1数据装载有限与load2及所有后续装载指令的装载 |
StoreStoreBarriers | store1;storestore;store2 | 确保store1的数据对其他处理器可见优先于store2及后续存储指令的存储 |
LoadStoreBarriers | load1;loadstore;store2 | 确保load1数据装载优先于sotre2以及后续的存储指令刷新到内存 |
StoreLoadBarriers | store1;storeload;load2 | 确保store数据对其他处理器可见,优先于load2及所以的装载指令的装载,全能型指令 |
HappenBefore
他的意思的表示前一共操作的结果对于后续的操作是可见的,所以他是一种表达多个线程之间对于内存的可见性
可以认为在JMM中如果一个操作对于另一个操作可见那么这二个操作存在happenBefore关系
JMM中有哪些方法建立happen-before规则
程序顺序规则
一个线程中的每个操作,happens-before 于该线程中的任意后续操作;可以简单认为是 as-if-serial。单个线程中的代码顺序不管怎么变,对于结果来说是不变的
volatile 变量规则
volatile 变量规则,对于 volatile 修饰的变量的写的操作,一定 happen-before 后续对于 volatile 变量的读操作;根据 volatile 规则,2 happens before 3
int a=0;
volatile boolean flag=false;
public void writer(){
a=1; 1
flag=true; 2
}
public void reader(){
if(flag){ 3
int i=a; 4
}
}
传递性规则
如果 1 happens-before 2; 2happensbefore 3; 那么传递性规则表示: 1 happens-before 3;
int a=0;
volatile boolean flag=false;
public void writer(){
a=1; 1
flag=true; 2
}
public void reader(){
if(flag){ 3
int i=a; 4
}
}
start 规则
如果线程 A 执行操作 ThreadB.start(),那么线程 A 的 ThreadB.start()操作 happens-before 线程 B 中的任意操作
public static void main(String[] args) {
Thread threadA=new Thread(()->{
System.out.println(a==10);
});
a=10;
threadA.start();
System.out.println(a);
}
join 规则
如果线程 A 执行操作 ThreadB.join()并成功返回,那么线程 B 中的任意操作 happens-before 于线程A 从 ThreadB.join()操作成功返回。
Thread threadA=new Thread(()->{
a=10;
});
threadA.start();
threadA.join();
System.out.println(a==10);
监视器锁的规则
对一个锁的解锁,happens-before 于随后对这个锁的加锁
for(int i=0;i<10;i++){
new Thread(()->{
demo();
}).start();
}
public static void demo(){
synchronized (obj){
// a 是共享变量, 初始值 =0
if(a<10){
a=10;
}
System.out.println(a);
}//自动解锁
}