内存模型分析

我们都知道程序猿编写的代码都是跑在具体的硬件架构上面的，只是目前的高级语言系统屏蔽了很多底层硬件细节。但是如果想要对于并发问题有深入的理解，还是需要对底层计算机硬件系统的细节有更多的了解。因此要想分析并发安全问题的根本原因，我们需要从问题现象出发，刨根问底，深入研究才能找到问题的答案。

计算机内存模型

首先从计算机硬件系统出发，我们可以将计算机系统简化为三大部件，即CPU、内存以及IO设备。随着技术的不断发展，计算机硬件也有了长足的发展。各大部件的能力与日俱增。但是有一个问题一直围绕在计算机硬件结构周围，那就是CPU、内存以及IO设备之间的数据访问速度有着巨大的速度差异。正式由于这种访问速度的巨大差异造成了影响程序性能的最大因素正是最慢的IO设备，因此如果需要提升整体的性能，仅仅提高某一项是不够的，要从整体出发，充分发挥CPU性能优势。

为了应对这种数据读取速率差异，CPU中增加了高速缓存，来平衡其与内存的速度差异。操作系统通过增加进程、线程，以便与最大可能分时复用CPU，充分挖掘CPU性能。

在 CPU 中都会有一个高速缓冲区，在实际运行过程中，CPU首先从计算机主存中将数据复制到高速缓冲区中。CPU在进行运算时，直接基于高速缓冲区的数据进行运算，逻辑运算之后，再将高速缓冲区的数据刷新到主存中。通过这样的方式，CPU的执行指令的速度就可以大大提升。

在单核 CPU 时代，程序中所有的线程都跑在单核中，由于所有当线程都是操作同一块CPU的缓存，因此据一个线程对缓存的操作，对另外一个线程来说一定是可见的。因此不存在线程安全的问题。

但是当在多核CPU场景下，线程跑在不同当CPU中，因此对变量进行逻辑操作时，对其他线程不可见，因此会存在并发安全问题。

到此，我们分析出了并发安全的第一个根源，即缓存导致的数据可见性问题，由于存在CPU高速缓存，不同线程所在不同的CPU在计算后结果互不可见，这才导致了并发安全问题。

JVM 内存模型

JVM定义的内存模型实际是计算机硬件架构在JVM中的映射体现。内存模型屏蔽了不同操作系统与内存硬件的访问差异。Java的内存模型如图所示：

JVM启动运行之后，操作系统会为该JVM进程分配制定的的内存空间，这部分内存空间即为上图中的主内存。实际我们的Java程序的所有工作都由线程来完成，而每个线程都会有一小块内存，即所谓的工作内存。Java中的线程在执行的过程中，会先将数据从主内存中复制到线程的工作内存，然后再执行计算，执行计算之后，再把计算结果刷新到主内存中。

我们一起来分析下count++在多线程场景下无法得到预期结果的原因。

对于count++的操作 看上去是执行了一条指令实际上包含了三条指令。

（1）首先，需要把变量count从内存加载到工作线程的工作内存中；

（2）加载后在工作内存中执行+1操作；

（3）最后，将计算结果写入内存。

如上文所说的，由于计算机的大部件之间存在数据处理速度差异，处理一项任务时往往是CPU在等待其他部件完成后才进行后续的操作，为了提高CPU的工作效率，可以在CPU等待期间让出 CPU 使用权，让CPU去处理其他事情，这就是所谓的分时复用。那么在Java多线程场景下，必定也会发生线程切换，如下图所示，由于count++不具备运算的原子性，导致了线程在运行过程中发生线程切换，最终导致输出结果与预期不一致。