前体概要
CPU和内存之间同样存在一致性问题。很多人认为CPU是一个计算组件，并没有数据一致性的问题。但事实上，由于内存的发展速度跟不上CPU的更新，在CPU和内存之间，存在着多层的高速缓存。
原因就是由于多核所引起的，这些高速缓存，往往会有多层。如果一个线程的时间片跨越了多个CPU，那么同样存在同步的问题。
import java.util.stream.IntStream; public class JMMDemo { int value = 0; void add() { value++; } public static void main(String[] args) throws Exception { final int count = 100000; final JMMDemo demo = new JMMDemo(); Thread t1 = new Thread(() -> IntStream.range(0, count).forEach((i) -> demo.add())); Thread t2 = new Thread(() -> IntStream.range(0, count).forEach((i) -> demo.add())); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(demo.value); 复制代码
void add(); descriptor: ()V flags: Code: stack=3, locals=1, args_size=1 0: aload_0 1: dup 2: getfield #2 // Field value:I 5: iconst_1 6: iadd 7: putfield #2 // Field value:I 10: return LineNumberTable: line 7: 0 line 8: 10 LocalVariableTable: Start Length Slot Name Signature 0 11 0 this LJMMDemo; 复制代码
另外，在执行过程中，CPU 可能也会对输入的代码进行乱序执行优化，Java 虚拟机的即时编译器也有类似的指令重排序优化,缓存内存机制的优化。整个函数的执行步骤就分的更加细致，看起来非常的碎片化（比字节码指令要细很多）,不管是字节码的原因，还是硬件的原因，在粗粒度上简化来看，比较浅显且明显的因素，那就是线程 add 方法的操作并不是原子性的。
为了解决这个问题，我们可以在add方法上添加synchronized关键字，它不仅保证了内存上的同步，而且还保证了CPU的同步。这个时候，各个线程只能排队进入add方法。
synchronized void add() { value++; }
着重看一下 add 方法，可以看到一个简单的 i++ 操作，竟然有这么多的字节码，而它们都是傻乎乎按照“顺序执行”的。当它自己执行的时候不会有什么问题，但是如果放在多线程环境中，执行顺序就变得不可预料了。
由上图可以看出来CPU私有人Cache只有L1和L2，L3和L4（新版支持），都属于公用的。
问题分析
- 1.（可见性问题+原子性问题）上图展示了这个乱序的过程。线程 A 和线程 B “并发”执行相同的代码块 add，执行的顺序如图中的标号，它们在线程中是有序的（1、2、5 或者 3、4、6），但整体顺序是不可预测的。
- 2.（可见性问题）线程 A 和 B 各自执行了一次加 1 操作，但在这种场景中，线程 B 的 putfield 指令直接覆盖了线程 A 的值，最终 value 的结果是 101。
- 3.(可见性问题)上面的示例仅仅是字节码层面上的，更加复杂的是，CPU 和内存之间同样存在一致性问题。很多人认为 CPU 是一个计算组件，并没有数据一致性的问题。但事实上，由于内存的发展速度跟不上CPU的更新，在CPU和内存之间，存在着多层的高速缓存，原因就是由于多核所引起的，这些高速缓存，往往会有多层。如果一个线程的时间片跨越了多个 CPU，那么同样存在同步的问题。
- 4.(有序性问题)另外，在执行过程中，CPU 可能也会对输入的代码进行乱序执行优化，Java 虚拟机的即时编译器也有类似的指令重排序优化。整个函数的执行步骤就分的更加细致，看起来非常的碎片化（比字节码指令要细很多）。
并发场景
- 单线程：CPU 核心的缓存只被一个线程访问。缓存独占，不会出现访问冲突等问题。
- 单核 CPU，多线程：进程中的多个线程会同时访问进程中的共享数据，CPU 将某块内存加载到缓存后，不同线程在访问相同的物理地址的时候，都会映射到相同的缓存位置，这样即使发生线程的切换，缓存仍然不会失效。
- 多核 CPU，多线程：每个核都至少有一个 L1 缓存 和 L2 缓存 。 多个线程访问进程中的某个共享内存，且这多个线程分别在不同的核心上执行，则每个核心都会在各自的Cache中保留一份共享内存的缓冲，由于多核是可以并行的，可能会出现多个线程同时写各自的缓存的情况，而各自的 Cache 之间的数据就有可能不同。
另一种情况（缺乏标准化和统一化）
- 在不同的硬件生产商和不同的操作系统下，内存的访问逻辑有一定的差异，结果就是当你的代码在某个系统环境下运行良好，并且线程安全，换了个系统就出现各种问题；
- 这是因为不同的处理器，在处理器优化和指令重排等方面存在差异，造成同样的代码，在经过不同的处理器优化和指令重排后，最后执行出来的结果可能不同，这是我们所不能接受的。
- JMM就应运而生了，究其根本就是为了解决在并发环境下，保证数据的安全，满足场景的可见性、原子性、有序性。
基本概念
- JMM是一个抽象的概念，它描述了一系列的规则或者规范，用来解决多线程的共享变量问题，比如 volatile、synchronized 等关键字就是围绕 JMM 的语法。这里所说的变量，包括实例字段、静态字段，但不包括局部变量和方法参数，因为后者是线程私有的，不存在竞争问题。
- JMM试图定义一种统一的内存模型，能将各种底层硬件，以及操作系统的内存访问差异进行封装，使Java程序在不同硬件及操作系统上都能达到相同的并发效果。
JMM规定了共享变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存保存了主内存的副本拷贝，对变量的操作在工作内存中进行，不能直接操作主内存中的变量。不同线程间无法直接访问对方的工作内存变量，需要通过主内存完成。
JMM的结构
JMM分为主存储器（Main Memory）和工作存储器（Working Memory）两种。
- 主存储器是实例位置所在的区域，所有的实例都存在于主存储器内。比如，实例所拥有的字段即位于主存储器内，主存储器是所有的线程所共享的。
- 工作存储器是线程所拥有的作业区，每个线程都有其专用的工作存储器。工作存储器存有主存储器中必要部分的拷贝，称之为工作拷贝（Working Copy）。
在这个模型中，线程无法对主存储器直接进行操作。如下图，线程A想要和线程B通信，只能通过主存进行交换。
- 这些内存区域都是在哪存储的呢？如果非要有个对应的话，你可以认为主存中的内容是Java堆中的对象，而工作内存对应的是虚拟机栈中的内容。
- 但实际上，主内存也可能存在于高速缓存，或者CPU的寄存器上；工作内存也可能存在于硬件内存中，我们不用太纠结具体的存储位置。
8个操作类型
支持JMM，Java定义8种原子操作，用来控制主存与工作内存之间的交互。
（1）read（读取）作用于主内存，它把变量从主内存传动到线程的工作内存中，供后面的 load 动作使用。
（2）load（载入）作用于工作内存，它把read操作的值放入到工作内存中的变量副本中。
（3）store（存储）作用于工作内存，它把工作内存中的一个变量传送给主内存中，以备随后的write操作使用。
（4）write （写入）作用于主内存，它把store传送值放到主内存中的变量中。
（5）use（使用）作用于工作内存，它把工作内存中的值传递给执行引擎，每当虚拟机遇到一个需要使用这个变量的指令时，将会执行这个动作。
（6）assign（赋值）作用于工作内存，它把从执行引擎获取的值赋值给工作内存中的变量，每当虚拟机遇到一个给变量赋值的指令时，执行该操作。
（7）lock（锁定）作用于主内存，把变量标记为线程独占状态。
（8）unlock（解锁）作用于主内存，它将释放独占状态。
