[Java 并发]从底层看 volatile

迷南。 2022-09-08 13:59 129阅读 0赞

今天从底层来看 volatile 这个关键字,其实我也不知道今天写的内容有没有到底层,我感觉的话是到了,哈哈哈哈  
关于 volatile 写过一篇: [\[Java 并发\]你确定你了解 volatile ?][Java _ volatile]  
如果看过这篇文章的话,就知道 volatile 它保证了可见性,那么它具体是如何保证的呢  
synchronized 它是通过 `monitorenter` 和 `monitorexit` 指令来保证锁的持有和释放的,那么 volatile 在底层这块它是通过什么来保证的呢?  
我们通过汇编指令来看一下,当我们使用了 volatile 关键字之后有什么是不一样的(我这里截取了多的那一行)

0x0000000002b91351 : lock add dword ptr [rsp],0h ;*putstatic instance

能够看到使用了 volatile 关键字之后,汇编指令多了 `lock` ,也就是 volatile 通过 `lock` 指令来达到了可见性的目的

#  硬件层面 #

volatile 在 JVM 层面是如何实现的,已经做过分析了:  
[\[Java 并发\]为什么会有重排序?和 happens-before 有啥关系][Java _ happens-before]  
[\[Java 并发\]你确定你了解 volatile ?][Java _ volatile]

接下来从硬件层面去分析一下  
我们都知道计算机系统中所有的运算操作都是由 CPU 来完成的,那么 CPU 就需要从内存里面加载数据,把数据计算完成之后,再同步给内存,但是 CPU 的速度实在是太快了,如果在 CPU 进行数据运算时直接访问内存的话,就会让 CPU 的效率大大降低  
为了解决这个问题,就引入了缓存的概念,目前的主流 CPU 都有 L1/L2/L3 三级缓存,大概就是这样:  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6YOR55KQ55KQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]

L1 和 L2 缓存是每个 CPU 独有的,有了高速缓存之后, CPU 的处理过程就变成了:先将计算需要用到的数据缓存到 CPU 高速缓存中,这样在 CPU 进行计算时,直接从高速缓存中读取数据,然后再将计算之后的数据写入到缓存中就 OK 了  
但是只要有缓存存在的地方,就一定有一个问题:缓存不一致  
比如现在线程 A 和线程 B 都要进行一个 i++ 的操作,然后线程 A 在左边的 CPU 中运行,线程 B 在右边的 CPU 运行,那这样的话,两个线程都不知道彼此对 i 进行了操作,最后的结果就是 i 的值是 1 ,两个线程同时进行了 i++ 操作,最后结果是 1 ,这样的结果肯定是不能接受的,如何解决这个问题呢,在 CPU 层面有两种解决办法:**总线锁和缓存锁**

## 总线锁 ##

在上面的图中,可以看到总线  
所谓的总线锁就是(还以 i++ 这个操作为例),现在不是多核 CPU ,当其中一个 CPU 要进行 i++ 操作时,就在总线上发出一个 `LOCK#` 信号,这个信号发出之后,其他 CPU 就没有办法通过总线来访问到主内存中的数据了,这样做的话,这一个时刻只有一个 CPU 在进行 i++ 的操作,其他不能操作主内存中的数据  
但是这样的代价太大了,怎么优化一下呢?就从降低锁的粒度来优化,就有了缓存锁

## 缓存锁 ##

缓存锁的核心就在于一个处理器的缓存回写到内存中时,会导致其他处理器的缓存无效,这是基于缓存一致性协议来实现的,缓存一致性协议有很多种,大致可以分为两类:"窥探( snooping)"协议和"基于目录的(directory-based)"协议,常见的就是 MESI 协议,它属于一种窥探协议

窥探协议的基本思想是:所有 cache 与内存, cache 与 cache 之间的数据传输都发生在一条共享的总线上,所有的 CPU 都能看到这条总线(还是上面那张图),在同一个指令周期中,只有一个 cache 可以读写内存,所有的内存访问都要经过仲裁(arbitrate),所以 cache 不但和内存通信时和总线打交道,还会不停的窥探总线上发生的数据交换,来跟踪其他 cache 在做什么,所以当一个 cache 代表它所属的 CPU 去读写内存时,其他 CPU 都会得到通知,通过这样的机制来让自己的 cache 保持同步

### MESI 协议 ###

MESI 协议是由 4 个状态首字母的缩写来的,分别是:

*  M : Modified ,表示共享数据只缓存在当前 CPU 中,而且是修改状态,也就是此时缓存的数据和主内存中的数据不一致
 *  E : Exclusive ,表示数据只缓存在当前 CPU 中,并且没有被修改
 *  S : Shared ,表示数据可能被多个 CPU 缓存,而且各个缓存中的数据与主内存数据一致
 *  I : Invalid ,表示缓存已经失效

我们现在已经知道了,窥探协议的存在,使得 CPU 不仅知道自己的读写操作,还知道其他 CPU 的读写操作,所以对于 MESI 协议来说,从 CPU 读写角度来说会遵循以下原则:  
CPU 读请求:缓存处于 M/E/S 状态都可以读取, I 状态 CPU 只能从主内存中读取数据  
CPU 写请求:缓存处于 M/E 状态才可以被写,对于 S 状态的写请求,需要将其他 CPU 中的缓存置为无效才可以  
这样的话, CPU 对于内存的操作就变成了下面这样:  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6YOR55KQ55KQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]

### MESI 协议带来的问题 ###

MESI 协议虽然可以实现缓存的一致性,但是也有一些问题,就是各个 CPU 缓存的状态是通过消息传递来进行的,如果一个 CPU 要对一个在缓存中共享的变量进行写入,就需要发送一个失效的消息到其他缓存了该数据的 CPU ,而且要等到它们的确认回执,此时这个 CPU 就处于阻塞状态,为了解决这个问题,就引入了 store buffers  
在写入共享数据时,直接将数据写入到 store buffers 中,同时发送 invalidate 消息,然后 CPU 就不 care 这块内容了,它就去处理其他指令去了,当收到其他所有缓存了该数据的 CPU 的 invalidate acknowledge 消息回执时,再把 store buffers 中的数据存储到缓存行中,然后再从缓存同步到主内存  
但是这种优化,又带来了可见性问题,因为在 CPU 层面也会发现指令重排,所以对于开发者来说,我们写的代码到底是怎样的顺序去执行的就不知道了  
JVM 层面提供了内存屏障去解决问题,在 CPU 层面也是通过内存屏障去解决的

## CPU 层面的内存屏障 ##

CPU内存屏障主要分为以下三类：  
写屏障(Store Memory Barrier): 告诉处理器在写屏障之前的所有已经存储在存储缓存(store bufferes)中的数据同步到主内存,简单来说就是使得写屏障之前的指令的结果对写屏障之后的读或者写是可见的  
读屏障(Load Memory Barrier): 处理器在读屏障之后的读操作,都在读屏障之后执行.配合写屏障,使得写屏障之前的内存更新对于读屏障之后的读操作是可见的  
全屏障(Full Memory Barrier): 确保屏障前的内存读写操作的结果提交到内存之后,再执行屏障后的读写操作

这篇文章到这里,你可能都懵了,这些 JVM 层面的屏障, CPU 层面的屏障,我们开发者该怎么加呢  
其实不用加的~只要我们在程序中使用了 volatile 关键字,这个关键字就会生成一个 `lock` 的汇编指令,这个指令就相当于实现了一种内存屏障  
没有想到吧,一个小小的 volatile 背后竟然有这么多内容~  
大概就是这样了,感谢您的阅读哇

[Java _ volatile]: https://blog.csdn.net/zll_0405/article/details/105853414
[Java _ happens-before]: https://blog.csdn.net/zll_0405/article/details/105853490
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6YOR55KQ55KQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220829/aa20d13e0c8440ddbb3e2e532a889ea3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6YOR55KQ55KQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]: /images/20220829/f98dcaab3fba457ba052e4ea92cd3a38.png