Java 内存模型存在的问题（三十二）

柔情只为你懂 2023-01-01 01:56 85阅读 0赞

今天分享Java 内存模型存在的问题及如何解决：

从抽象的角度来看， JMM  定义了线程和主内存之间的抽象关系：线程之间 的共享变量存储在主内存（Main Memory ）中，每个线程都有一个 **私有** 的本地内 存（Local Memory ），本地内存中存储了该线程以读 / 写共享变量的副本。本地 内存是 JMM  的一个抽象概念，并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。

![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][]

**Java**  **内存模型带来的问题**

**1、可见性问题**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

左边  CPU  中运行的线程从主存中拷贝共享对象  obj  到它的  CPU  缓存，把对 象 obj  的  count  变量改为  2 。但这个变更对运行在右边  CPU  中的线程不可见，因 为这个更改还没有 flush  到主存中。 在多线程的环境下，如果某个线程首次读取共享变量，则首先到主内存中获 取该变量，然后存入工作内存中，以后只需要在工作内存中读取该变量即可。同 样如果对该变量执行了修改的操作，则先将新值写入工作内存中，然后再刷新至 主内存中。但是什么时候最新的值会被刷新至主内存中是不太确定，一般来说会 很快，但具体时间不知。 要解决共享对象可见性这个问题，我们可以使用 volatile  关键字或者是加锁。

**2、竞争问题**

线程  A  和线程  B  共享一个对象  obj 。假设线程  A  从主存读取  Obj.count  变量 到自己的 CPU  缓存，同时，线程  B  也读取了  Obj.count  变量到它的  CPU  缓存，并 且这两个线程都对 Obj.count  做了加  1  操作。此时， Obj.count  加  1  操作被执行了 两次，不过都在不同的 CPU  缓存中。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

如果这两个加  1  操作是串行执行的，那么  Obj.count  变量便会在原始值上加 2，最终主存中的  Obj.count  的值会是  3 。然而图中两个加  1  操作是并行的，不管 是线程 A  还是线程  B  先  flush  计算结果到主存，最终主存中的  Obj.count  只会增 加 1  次变成  2 ，尽管一共有两次加  1  操作。 要解决上面的问题我们可以使用  java synchronized 代码块

**3、重排序**

***1）重排序类型***

除了共享内存和工作内存带来的问题，还存在重排序的问题：在执行程序时， 为了提高性能，编译器和处理器常常会对指令做重排序。重排序分 3  种类型。

1.1 ）编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以 重新安排语句的执行顺序。

1.2 ）指令级并行的重排序。现代处理器采用了指令级并行技术 （Instruction-LevelParallelism ， ILP ）来将多条指令重叠执行。如果不存在数据依 赖性，处理器可以改变语句对应机器指令的执行顺序。

1.3 ）内存系统的重排序。由于处理器使用缓存和读 / 写缓冲区，这使得加载和 存储操作看上去可能是在乱序执行。

***2)数据依赖性***

数据依赖性：如果两个操作访问同一个变量，且这两个操作中有一个为写操 作，此时这两个操作之间就存在数据依赖性。数据依赖分为下列 3  种类型，上面 3 种情况，只要重排序两个操作的执行顺序，程序的执行结果就会被改变。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

![2020123016295881.png][]

很明显， A  和  C  存在数据依赖， B  和  C  也存在数据依赖，而  A  和  B  之间不存 在数据依赖，如果重排序了 A  和  C  或者  B  和  C  的执行顺序，程序的执行结果就 会被改变。

很明显，不管如何重排序，都必须保证代码在单线程下的运行正确，连单线 程下都无法正确，更不用讨论多线程并发的情况，所以就提出了一个 as-if-serial 的概念。

***3) as-if-serial***

as-if-serial  语义的意思是：不管怎么重排序（编译器和处理器为了提高并行 度），（单线程）程序的执行结果不能被改变。编译器、runtime  和处理器都必 须遵守 as-if-serial  语义。

为了遵守  as-if-serial  语义，编译器和处理器不会对存在数据依赖关系的操作 做重排序，因为这种重排序会改变执行结果。（强调一下，这里所说的数据依赖 性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之 间和不同线程之间的数据依赖性不被编译器和处理器考虑。）但是，如果操作之 间不存在数据依赖关系，这些操作依然可能被编译器和处理器重排序。 A 和  C  之间存在数据依赖关系，同时  B  和  C  之间也存在数据依赖关系。因此 在最终执行的指令序列中，C  不能被重排序到  A  和  B  的前面（ C  排到  A  和  B  的前

面，程序的结果将会被改变）。但  A  和  B  之间没有数据依赖关系，编译器和处 理器可以重排序 A  和  B  之间的执行顺序。

![20201230163026796.png][] ![20201230163032583.png][]

as-if-serial  语义把单线程程序保护了起来，遵守  as-if-serial  语义的编译器、 runtime 和处理器可以让我们感觉到：单线程程序看起来是按程序的顺序来执行 的。asif-serial  语义使单线程程序员无需担心重排序会干扰他们，也无需担心内 存可见性问题。

***4) 控制依赖性***

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5][]

上述代码中， flag  变量是个标记，用来标识变量  a  是否已被写入，在  use  方 法中变量 i  的赋值依赖  if (flag) 的判断，这里就叫控制依赖，如果发生了重排序， 结果就不对了。

考察代码，我们可以看见，操作 1 和操作  2  没有数据依赖关系，编译器和处理器可以对这两个操作重排 序；同样，操作 3  和操作  4  没有数据依赖关系，编译器和处理器也可以对这两个

操作重排序。操作  3  和操作  4  则存在所谓 **控制依赖关系** 。 在程序中，当代码中存在控制依赖性时，会影响指令序列执行的并行度。为 此，编译器和处理器会采用猜测（Speculation ）执行来克服控制相关性对并行度 的影响。以处理器的猜测执行为例，执行线程 B  的处理器可以提前读取并计算 a\*a，然后把计算结果临时保存到一个名为重排序缓冲（ Reorder Buffer ， ROB ） 的硬件缓存中。当操作 3  的条件判断为真时，就把该计算结果写入变量  i  中。猜 测执行实质上对操作 3  和  4  做了重排序，问题在于这时候， a  的值还没被线程  A 赋值。

在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也 是 as-if-serial  语义允许对存在控制依赖的操作做重排序的原因）。 但是对多线程来说就完全不同了：这里假设有两个线程 A  和  B ， A  首先执行 init ()方法，随后  B  线程接着执行  use () 方法。线程  B  在执行操作  4  时，能否看到 线程 A  在操作  1  对共享变量  a  的写入呢？答案是：不一定能看到。

让我们先来看看，当操作  1  和操作  2  重排序，操作  3  和操作  4  重排序时，可 能会产生什么效果？操作 1  和操作  2  做了重排序。程序执行时，线程  A  首先写标 记变量 flag ，随后线程  B  读这个变量。由于条件判断为真，线程  B  将读取变量  a 。 此时，变量 a  还没有被线程  A  写入，这时就会发生错误！ 所以在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执 行结果。多线程安全执行代码：

/**
     * 控制依赖
     */
    public class ControlDep {
    	int a = 0;
        //保证内存的可见性
    	volatile boolean flag = false;
    
    	public void init() {
    		a = 1; // 1
    		flag = true; // 2
    		//.......
    	}
        //加锁保证线程数据安全
    	public synchronized void use() {
    		if (flag) { // 3
    			int i = a * a; // 4
    		}
    		//.......
    	}
    }

**4、内存屏障**

Java  编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类 型的处理器重排序，从而让程序按我们预想的流程去执行。

1） 、保证特定操作的执行顺序。

2） 、影响某些数据（或则是某条指令的执行结果）的内存可见性。 编译器和 CPU  能够重排序指令，保证最终相同的结果，尝试优化性能。插 入一条 Memory Barrier （内存屏障） 会告诉编译器和  CPU ：不管什么指令都不能和这条 Memory Barrier 指令重排序。 Memory Barrier 所做的另外一件事是强制刷出各种  CPU cache ，如一个 Write-Barrier（写入屏障）将刷出所有在  Barrier  之前写入  cache  的数据，因此， 任何 CPU  上的线程都能读取到这些数据的最新版本。 JMM 把内存屏障指令分为  4  类

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6][]

StoreLoad Barriers  是一个“全能型”的屏障，它同时具有其他  3  个屏障的 效果。现代的多处理器大多支持该屏障（其他类型的屏障不一定被所有处理器支 持）。

**5、临界区**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7][]

JMM  会在退出临界区和进入临界区这两个关键时间点做一些特别处理，使 得多线程在这两个时间点按某种顺序执行。 临界区内的代码则可以重排序（但 JMM  不允许临界区内的代码“逸出”到 临界区之外，那样会破坏监视器的语义）。虽然线程 A  在临界区内做了重排序， 但由于监视器互斥执行的特性，这里的线程 B  根本无法“观察”到线程  A 在临 界区内的重排序。这种重排序既提高了执行效率，又没有改变程序的执行结果。

到此，Java 内存模型存在的问题分析结束。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221120/8f57f38fdf4a4755b0ee6bc4494335f2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221120/7139d559e4a84fb39b8e6bb6e5cdebcc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221120/e0c00c6e10e6461e90b9477a99db4cdb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221120/736c8bd66a174dcdad15074d5f2cdc10.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221120/4d06805aff2d4f10bc43f0a17f79de87.png
[2020123016295881.png]: /images/20221120/3580757238c84659aed2750893a22363.png
[20201230163026796.png]: https://img-blog.csdnimg.cn/20201230163026796.png
[20201230163032583.png]: /images/20221120/8590af50d10b4bfc8638e551d7d908a1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5]: /images/20221120/8c574e151c7e4648abe0fcc9468a104a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6]: /images/20221120/fa06de39dd714a89ab28b09f41c81b02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7]: /images/20221120/fc133fb9f50948b9b98b0501ffdfd90b.png