当我们谈 Java 并发的时候，你们在谈什么？

前言：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

当线程更新一个共享变量的值时，会发生内存可见性问题（Memory Visibility）。

当多个线程对同一个变量进行更新操作时，会产生竞态条件（Race Condition）。

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

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

在此我向大家推荐一个Java高级群 ：725633148 里面会分享一些资深架构师录制的视频录像：（有spring，mybatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构、面试资料）等这些成为架构师必备的知识体系 进群马上免费领取，目前受益良多！

内存可见性

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

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

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

竞态条件

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

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

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

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

在此我向大家推荐一个Java高级群 ：725633148 里面会分享一些资深架构师录制的视频录像：（有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构、面试资料）等这些成为架构师必备的知识体系 进群马上免费领取，目前受益良多！