本文详细介绍了Java内存模型（JMM）及其在多线程并发编程中的作用，包括解决可见性、原子性和有序性问题。JVM内存结构中包含堆、方法区、方法栈、本地方法栈和程序计数器，而JMM规定了线程如何在工作内存和主内存之间同步变量，确保并发安全。文中举例说明了并发编程中可能出现的问题，如缓存不一致和指令重排序，并探讨了解决方案，如加锁和MESI缓存一致性协议。
JVM内存模型
JVM的内存结构大概分为：
- 堆（Heap）：线程共享。所有的对象实例以及数组都要在堆上分配。回收器主要管理的对象。
- 方法区（Method Area）：线程共享。存储类信息、常量、静态变量、即时编译器编译后的代码。
- 方法栈（JVM Stack）：线程私有。存储局部变量表、操作栈、动态链接、方法出口，对象指针。
- 本地方法栈（Native Method Stack）：线程私有。为虚拟机使用到的Native 方法服务。如Java使用c或者c++编写的接口服务时，代码在此区运行。
- 程序计数器（Program Counter Register）：线程私有。有些文章也翻译成PC寄存器（PC Register），同一个东西。它可以看作是当前线程所执行的字节码的行号指示器。指向下一条要执行的指令。
Java内存模型（Java Memory Model ,JMM）
就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了Java程序在各种平台下对内存的访问都能得到一致效果的机制及规范。目的是解决由于多线程通过共享内存进行通信时，存在的原子性、可见性（缓存一致性）以及有序性问题
Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。
而JMM就作用于工作内存和主存之间数据同步过程。他规定了如何做数据同步以及什么时候做数据同步。
因此，JVM 内存结构和Java内存模型不是同一回事
1. 可见性问题
多核时代，每颗 CPU 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 上执行时，这些线程操作的是不同的 CPU 缓存。
比如下图中，线程 A 操作的是 CPU-1 上的缓存，而线程 B 操作的是 CPU-2 上的缓存，很明显，这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了。
这个就属于硬件程序员给软件程序员挖的“坑”。
2. 原子性问题
早期的操作系统基于进程来调度 CPU，不同进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址，而一个进程创建的所有线程，都是共享一个内存空间的，所以线程做任务切换成本就很低了。现代的操作系统都基于更轻量的线程来调度，现在我们提到的“任务切换”都是指“线程切换”。
Java 并发程序都是基于多线程的，自然也会涉及到任务切换，也许你想不到，任务切换竟然也是并发编程里诡异 Bug 的源头之一。任务切换的时机大多数是在时间片结束的时候，我们现在基本都使用高级语言编程，高级语言里一条语句往往需要多条 CPU 指令完成，例如上面代码中的count += 1，至少需要三条 CPU 指令。
-
指令 1：首先，需要把变量 count 从内存加载到 CPU 的寄存器；
-
指令 2：之后，在寄存器中执行 +1 操作；
-
指令 3：最后，将结果写入内存（缓存机制导致可能写入的是 CPU 缓存而不是内存）。
操作系统做任务切换，可以发生在任何一条 CPU 指令执行完，是的，是 CPU 指令，而不是高级语言里的一条语句。对于上面的三条指令来说，我们假设 count=0，如果线程 A 在指令 1 执行完后做线程切换，线程 A 和线程 B 按照下图的序列执行，那么我们会发现两个线程都执行了 count+=1 的操作，但是得到的结果不是我们期望的 2，而是 1。
有序性--重新排序带来的问题
编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变成“b=7；a=6；”，在这个例子中，编译器调整了语句的顺序，但是不影响程序的最终结果。不过有时候编译器及解释器的优化可能导致意想不到的 Bug。
一个经典的案例就是利用双重检查创建单例对象，例如下面的代码：在获取实例 getInstance() 的方法中，我们首先判断 instance 是否为空，如果为空，则锁定 Singleton.class 并再次检查 instance 是否为空，如果还为空则创建 Singleton 的一个实例。
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
假设有两个线程 A、B 同时调用 getInstance() 方法，他们会同时发现 instance == null ，于是同时对 Singleton.class 加锁，此时 JVM 保证只有一个线程能够加锁成功（假设是线程 A），另外一个线程则会处于等待状态（假设是线程 B）；线程 A 会创建一个 Singleton 实例，之后释放锁，锁释放后，线程 B 被唤醒，线程 B 再次尝试加锁，此时是可以加锁成功的，加锁成功后，线程 B 检查 instance == null 时会发现，已经创建过 Singleton 实例了，所以线程 B 不会再创建一个 Singleton 实例。这看上去一切都很完美，无懈可击，但实际上这个 getInstance() 方法并不完美。问题出在哪里呢？出在 new 操作上，我们以为的 new 操作应该是：
-
分配一块内存 M；
-
在内存 M 上初始化 Singleton 对象；
-
然后 M 的地址赋值给 instance 变量。
实际上优化后的执行路径却是这样的：
-
分配一块内存 M；
-
将 M 的地址赋值给 instance 变量；
-
最后在内存 M 上初始化 Singleton 对象。
优化后会导致什么问题呢？我们假设线程 A 先执行 getInstance() 方法，当执行完指令 2 时恰好发生了线程切换，切换到了线程 B 上；如果此时线程 B 也执行 getInstance() 方法，那么线程 B 在执行第一个判断时会发现 instance != null ，所以直接返回 instance，而此时的 instance 是没有初始化过的，如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。
实际上为了提高性能，编译器和处理器在运行时都会对指令做重排序。可以分为以下三类：
-
编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
-
指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism，ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
-
内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
从Java源代码到最终实际执行的指令序列，会分别经历下面3种重排序：
Java内存模型
Java内存模型中规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。我们来看一张图：
每个线程拥有一个自己的私有工作内存，需要变量时从主内存中拷贝一份到工作内存，如果更新过变量之后再将共享变量刷新到主内存。
但是两个线程之间，是没有办法读取对方工作内存中的变量值的。看一个例子：
public class Test {
private static boolean flag=false;
public static void main(String[] args) throws InterruptedException {
new Thread(new Runnable() {
@Override
public void run() {
System.out.println("waiting");
while (!flag){}
System.out.println("in");
}
}).start();
Thread.sleep(2000);
new Thread(new Runnable() {
@Override
public void run() {
System.out.println("change flag");
flag=true;
System.out.println("change success");
}
}).start();
}
}
首先定义了一个静态变量flag为false，A线程等待flag等于true后输出in，于是我们新开一个线程将flag修改为true。结果是A线程依旧无法输出in。
整个过程一共十步，重复几个步骤不讲了，我把不重复的六个操作列一下：
read：从主内存读取数据
load：将主内存读取到的数据写入工作内存
use ：从工作内存中读取数据来使用
assign：把计算好的值重新赋值到工作内存中
store：将工作内存数据写入主内存
write：将store过去的变量赋值给主内存中的变量
通过上面的图，对下面六个原子操作的理解应该可以更加深刻了。JMM的原子操作一共有八个，下面列出剩下的两个
lock：将主内存变量加锁，标识为线程独占状态
unlock：将主内存变量解锁，解锁后其他线程可以锁定该变量
JMM缓存不一致问题
从前面的例子我们已经看到了，一个线程修改完数据，另外一个线程无法立即可见，这就是JMM缓存不一致的问题，有两种解决办法：
加锁：
还记得我们没有用到过的JMM原操作的最后两个吗，lock和unlock，使用这两个操作就可以实现缓存一致性，一个线程想要获取某个主内存变量时，先使用lock将主内存变量加锁，只有他才能使用，等用完后再unlock，其他线程才能竞争。但是加锁意味着性能低。
MESI缓存一致性协议：
这个协议涉及到cpu的总线嗅探机制，从上面的JMM执行的流程图中我们可以看到当某个线程修改了共享变量后，他会回写到主内存，MESI缓存一致性协议就是通过cpu的总线嗅探机制，将其他也正在使用该变量的线程的数据失效掉，使得这些线程要重新读取主内存中的值，从而保证缓存最终一致性。(volatile的实现原理)
以上记录，参考了以下博文，用于个人学习和知识积累
原文链接：
https://blog.csdn.net/weixin_39712611/article/details/114775963
https://xie.infoq.cn/article/c00639000ec96e4b08d312052
https://www.hollischuang.com/archives/2550
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
