转载

当我们谈 Java 并发的时候,我们在谈什么

很多人在刚开始学 Java 的时候,会觉得多线程是一块难啃的骨头,特别是对于非科班的同学。究其原因,我想主要是因为没有将多线程建立起一种模型,不清楚多线程的问题到底是怎么产生的。在这里,我就和大家聊一下我对Java 多线程的一些想法。

Java 是基于 Java 虚拟机(JVM)实现的一套编程语言,我们写的 Java 代码是要在 JVM 中才能运行。所谓虚拟机,其实就是模拟了一个操作系统。一个常规操作系统所必备的功能,虚拟机一般也会有。我们计算机的操作系统能管理内存资源,那么虚拟机当然也要能管理内存资源了。在 JVM 里,从逻辑的角度来说,会把内存划分为两部分: 线程栈

嗯,我知道你们对这样简单粗暴的划分方式有意见,JVM 里面的内存划分远比上面说的复杂。

而我们今天的谈论只涉及到 线程栈 (即虚拟机栈)和 ,因此就简单地认为 JVM 只划分了这两部分。

也就是说,JVM 里面的内存模型,我们可以简要地画成下面的那样:

当我们谈 Java 并发的时候,我们在谈什么

每一个线程对应一个线程栈,线程栈里面的资源是私有的,也就是说我们在线程栈里的变量(即所谓的局部变量)是不会被多个线程共享。

堆内存是被所有线程所共享的,程序中创建的对象都会保留在堆内存中。

好了,说完了 Java 的内存模型,我们来看一看计算机的内存模型。

我们写代码的时候,代码和数据一般都是保存在硬盘中。当我们在 shell 中输入完一个 javac 命令,或者点击 IDE 的编译按钮的时候,我们的代码和数据会第一时间复制到内存中。复制完成之后会通知我们的 CPU 处理器,然后 CPU 开始执行命令,将内存中的信息复制到 CPU 寄存器中,用来执行相应指令。在现代 CPU 中,CPU 寄存器运行速度非常快,而内存运行速度相对来说就非常慢了,为了弥补两者运行速度之间的巨大差异,在内存和 CPU 寄存器之间会有高速缓存(一般有三级缓存),用来暂时存放从内存中获取的数据。整个结构大体如下图:

当我们谈 Java 并发的时候,我们在谈什么

上面这幅图就是计算机的简单存储模型,这里只画了三层,第一层是 CPU 寄存器,第二层是 CPU 高速缓存,第三层是内存。这里的箭头可以理解为数据总线,表示数据流动的方向。

在真实计算机中,CPU 高速缓存一般有多级,其中一部分封装在 CPU 核中,另一部分封装在 CPU 处理器中(一个处理器可以有多个核),这里为了方便,默认都封装在 CPU 处理器中的。

如果 CPU 想要读取我们代码中的数据,CPU 会先在高速缓存中查找需要的数据,如果找到了,那么就直接使用这数据;如果在缓存中没有找到需要的数据,那么就会继续往下找,在内存中获取数据,并且在缓存中存放一份,再拿回 CPU 使用。

而 CPU 想要把处理后的数据写回来的时候,就稍微麻烦一些了。如果 CPU 返回一个数据,就把该数据一级一级地往下送的话,那么数据总线流量就会非常大。因此,什么时间、以什么样的方式将返回的数据写入下一级存储器,以达到性能最优,是一个比较困难的问题。我们只知道, CPU 返回一个数据后,我们不会立即在内存中看到这个数据

了解了计算机的内存模型,这和 JVM 的内存模型有什么关系呢?

我们已经知道,计算机的内存模型和 JVM 的内存模型是不一样的,计算机的内存模型里面并不区分线程栈和堆。而 JVM 里的堆和线程栈信息,一开始也只在计算机的内存中,只有当 CPU 运行指令需要堆或线程栈中的信息时,JVM 里面的一部分堆和线程栈的数据才会被加载到高速缓存和 CPU 寄存器中。因此,JVM 的线程栈和堆的信息可以用下面的图来表示:

当我们谈 Java 并发的时候,我们在谈什么

也就是说,JVM 里面的变量和对象,可能在计算机存储结构中的任何地方存在。这就会导致两个问题:

  1. 当线程更新一个共享变量的值时,会发生内存可见性问题(Memory Visibility)。
  2. 当多个线程对同一个变量进行更新操作时,会产生竞态条件(Race Condition)。

这里其实还可以思考一个问题,即在 JVM 里面进行的线程操作,是如何分布到操作系统的线程的。换句话说,JVM 里面的线程是用户态还是内核态?

其实 JVM 虚拟机规范并未对此作出限制,不同的 JVM 可以有不同的实现。HotSpot 虚拟机默认使用的是内核线程,也就是说 HotSpot 虚拟机不干涉线程的调度,全权交由操作系统来处理。当然,如果想将线程绑定到特定的 CPU 核执行,也是可以的。HotSpot 虚拟机中实现了 static bool bind_to_processor(uint processor_id); 方法,用来将线程绑定到指定的 CPU 核运行。

内存可见性

假设有一个共享对象,它最开始只是在内存中,当一个线程争取到了左 CPU 的时间片,在这段时间里将共享对象复制到左 CPU 的高速缓存中,然后左 CPU 对这个共享对象做了一些修改并返回这个共享对象。之前我们说过, CPU 返回一个数据后,我们不会立即在内存中看到这个数据 ,因此,在共享对象的值返回到内存之前,如果右 CPU 也想使用这个共享对象,那么右 CPU 拿到的共享对象不是左 CPU 修改后的共享对象,也就是说右 CPU 得到的共享对象的值不是最新的!

下面通过一副图来说明这个问题:

当我们谈 Java 并发的时候,我们在谈什么

在上图中,左边的 CPU 会将内存中的 obj 对象复制一份在 CPU 高速缓存中,然后 CPU 对其进行操作,修改了 obj 对象中 count 属性的值,让 obj.count 从 1 变成了 2。然而在 CPU 高速缓存把 obj 最新的值返回到内存中之前,右边的 CPU 执行了相同的代码,也从内存中获取了 obj 对象,但它不知道左边的 CPU 对 obj 对象进行修改了,它 看不见 obj 对象最新的值,因此,右边的 CPU 获取的 obj.count 的值还是 1 。

竞态条件

可见性问题说的是一个线程对共享变量修改了之后,其他线程不能立即看到该共享变量最新的值得问题。如果有多个线程对同一个变量进行读取和修改,那么就可能发生竞态条件。

当我们谈 Java 并发的时候,我们在谈什么

如上图,假设左边的 CPU 从内存中获取了 obj 对象,并将其复制到 CPU 高速缓存中,这个时候,右边的 CPU 也从内存中获取到了 obj 对象,也将其复制到了 CPU 高速缓存中。然后两个 CPU 都对 obj.count 的值增加 1。从整体上来看,obj.count 的值增加了两次,而当左右两边的 CPU 高速缓存将 obj 的值写回到内存中时,会发现实际上 obj.count 的值只增加了 1 次。

下面的流程图可以详细说明这种情况:

当我们谈 Java 并发的时候,我们在谈什么

左 CPU 和右 CPU 同时争夺 obj 对象的情况,就被成为“竞态条件”。

(嗯,先写给腾腾看,未完待续~)

原文  http://wl9739.github.io/2018/08/01/当我们谈-Java-并发的时候,我们在谈什么/
正文到此结束
Loading...