当咱们谈 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 里面的变量和对象，可能在计算机存储结构中的任何地方存在。这就会致使两个问题：

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 获得的共享对象的值不是最新的！

下面经过一副图来讲明这个问题：

 

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

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

竞态条件

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

 

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

下面的流程图能够详细说明这种状况：

 

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