java内存模型关键字 volatile 详解（三十四）

快来打我* 2023-01-01 01:57 220阅读 0赞

今天对java内存模型关键字 volatile进行 详解：

***1、volatile***  ***特性***

可以把对  volatile  变量的单个读 / 写，看成是使用同一个锁对这些单个读 / 写 操作做了同步

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

可以看成

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

所以  volatile  变量自身具有下列特性：

可见性。对一个  volatile  变量的读，总是能看到（任意线程）对这个  volatile 变量最后的写入。

原子性：对任意单个  volatile  变量的读 / 写具有原子性，但类似于  volatile++ 这种复合操作不具有原子性。

***2、volatile***  ***的内存语义***

内存语义：可以简单理解为  volatile ，synchronize，atomic，lock 之类的在  JVM 中的内存方面实现原则。

volatile  写的内存语义如下：

当写一个  volatile  变量时， JMM  会把该线程对应的本地内存中的共享变量值刷新 到主内存。

volatile  读的内存语义如下：

当读一个  volatile  变量时， JMM  会把该线程对应的本地内存置为无效。线程接下 来将从主内存中读取共享变量。

所以对于代码

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

如果我们将  **flag**  变量以  **volatile**  关键字修饰，那么实际上：线程  A  在写  flag 变量后，本地内存 A  中被线程  A  更新过的两个共享变量的值都被刷新到主内存 中。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

在读  flag  变量后，本地内存  B  包含的值已经被置为无效。此时，线程  B  必须 从主内存中读取共享变量。线程 B  的读取操作将导致本地内存  B  与主内存中的共 享变量的值变成一致。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

如果我们把  volatile  写和  volatile  读两个步骤综合起来看的话，在读线程  B  读 一个 volatile  变量后，写线程  A  在写这个  volatile  变量之前所有可见的共享变量的 值都将立即变得对读线程 B  可见。

***3、为何***  ***volatile***  ***不是线程安全的***

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5][]

***4、volatile***  ***内存语义的实现***

volatile  重排序规则表

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6][]

总结起来就是：

当第二个操作是  volatile  写时，不管第一个操作是什么，都不能重排序。这 个规则确保 volatile  写之前的操作不会被编译器重排序到  volatile  写之后。

当第一个操作是  volatile  读时，不管第二个操作是什么，都不能重排序。这 个规则确保 volatile  读之后的操作不会被编译器重排序到  volatile  读之前。

当第一个操作是  volatile  写，第二个操作是  volatile  读时，不能重排序。

volatile  的内存屏障

在  Java  中对于  volatile  修饰的变量，编译器在生成字节码时，会在指令序列 中插入**内存屏障** 来禁止特定类型的处理器重排序问题。

*volatile*  *写*

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7][]

storestore  屏障：对于这样的语句  store1; storestore; store2 ，在  store2  及后续 写入操作执行前，保证 store1  的写入操作对其它处理器可见。 ( 也就是说如果出 现 storestore  屏障，那么  store1  指令一定会在  store2  之前执行， CPU  不会  store1 与 store2  进行重排序 ) storeload 屏障：对于这样的语句  store1; storeload; load2 ，在  load2  及后续所 有读取操作执行前，保证 store1  的写入对所有处理器可见。 ( 也就是说如果出现 storeload 屏障，那么  store1  指令一定会在  load2  之前执行 ,CPU  不会对  store1  与 load2 进行重排序 )

*volatile*  *读*

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8][]

在每个  volatile  读操作的后面插入一个  LoadLoad  屏障。在每个  volatile  读操 作的后面插入一个 loadstore  屏障。 loadload 屏障：对于这样的语句  load1; loadload; load2 ，在  load2  及后续 读取操作要读取的数据被访问前，保证 load1  要读取的数据被读取完毕。（也就 是说，如果出现 loadload  屏障，那么  load1  指令一定会在  load2  之前执行， CPU

不会对  load1  与  load2  进行重排序） loadstore 屏障：对于这样的语句  load1; loadstore; store2 ，在  store2  及 后续写入操作被刷出前，保证 load1  要读取的数据被读取完毕。（也就是说，如 果出现 loadstore  屏障，那么  load1  指令一定会在  store2  之前执行， CPU  不会对 load1 与  store2  进行重排序）

**5、volatile**  **的实现原理**

通过对  OpenJDK  中的  unsafe.cpp  源码的分析，会发现被  volatile  关键字修饰 的变量会存在一个“lock:” 的前缀。

Lock  前缀，Lock 不是一种内存屏障，但是它能完成类似内存屏障的功能。

Lock 会对 CPU  总线和高速缓存加锁，可以理解为  CPU  指令级的一种锁。 同时该指令会将当前处理器缓存行的数据直接写会到系统内存中，且这个写 回内存的操作会使在其他 CPU  里缓存了该地址的数据无效。

在具体的执行上，它先对总线和缓存加锁，然后执行后面的指令，最后释放 锁后会把高速缓存中的脏数据全部刷新回主内存。在 Lock  锁住总线的时候， 其他 CPU  的读写请求都会被阻塞，直到锁释放。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221120/2f5e49731f6a4183ba6f22a6b6846509.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221120/cd228b9ec67c46b88f37deae0e0a30ad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221120/1199ac3e0dc044548af6630d4085e75b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221120/0413cea85475492f8f4a7ec3bce6d3c8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221120/41fc3d9c652d4c7da96ecf4a1160a5a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5]: /images/20221120/e97d0b127787444b95443d8a76cf0b0b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6]: /images/20221120/ab9ff01307ce4da19f6cec803445488f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7]: /images/20221120/b1e05a48b01a4fd7835e393b271154f9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8]: /images/20221120/eccf73ffb36e47bb9a45c431b88c9a52.png