JMM(Java内存模型)、并发编程三大特性

CPU缓存模型：

　　CPU缓存为了解决CPU处理速度和内存处理速度不对等的问题，内存缓存的是硬盘数据用于解决硬盘访问速度过慢的问题。

指令重排序：

　　为了提升执行速度/性能，系统在执行代码的时候并不一定是按照你写的代码的顺序依次执行。

• 编译器优化重排 ：编译器（包括 JVM、JIT 编译器等）在不改变单线程程序语义的前提下，重新安排语句的执行顺序。
• 指令并行重排 ：现代处理器采用了指令级并行技术(Instruction-Level Parallelism，ILP)来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。

　　Java 源代码会经历 编译器优化重排 —> 指令并行重排 —> 内存系统重排 的过程，最终才变成操作系统可执行的指令序列。

 

JMM（Java Memory Model）　　

　　Java内存模型，Java语言是跨平台的，它需要自己提供一套内存模型以屏蔽系统差异。

　　可以把JMM看作是Java定义的并发编程的一组规范，其主要目的是为了简化多线程编程，增强程序可移植性。

 

JMM 是如何抽象线程和主内存之间的关系？

　　Java 内存模型（JMM） 抽象了线程和主内存之间的关系，就比如说线程之间的共享变量必须存储在主内存中。

　　在 JDK1.2 之前，Java 的内存模型实现总是从 主存 （即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量保存 本地内存 （比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。这和我们上面讲到的 CPU 缓存模型非常相似。

什么是主内存？什么是本地内存？

• 主内存：所有线程创建的实例对象都存放在主内存中，不管该实例对象是成员变量还是方法中的本地变量(也称局部变量)
• 本地内存：每个线程都有一个私有的本地内存来存储共享变量的副本，并且，每个线程只能访问自己的本地内存，无法访问其他线程的本地内存。本地内存是 JMM 抽象出来的一个概念，存储了主内存中的共享变量副本。

Java 内存模型的抽象示意图如下：

从上图来看，线程 1 与线程 2 之间如果要进行通信的话，必须要经历下面 2 个步骤：

1. 线程 1 把本地内存中修改过的共享变量副本的值同步到主内存中去。
2. 线程 2 到主存中读取对应的共享变量的值。

也就是说，JMM 为共享变量提供了可见性的保障。

不过，多线程下，对主内存中的一个共享变量进行操作有可能诱发线程安全问题。举个例子：

1. 线程 1 和线程 2 分别对同一个共享变量进行操作，一个执行修改，一个执行读取。
2. 线程 2 读取到的是线程 1 修改之前的值还是修改后的值并不确定，都有可能，因为线程 1 和线程 2 都是先将共享变量从主内存拷贝到对应线程的工作内存中。

　　关于主内存与工作内存直接的具体交互协议，即一个变量如何从主内存拷贝到工作内存，如何从工作内存同步到主内存之间的实现细节，Java 内存模型定义来以下八种同步操作：锁定、解锁、read、load、use、assign、store、write,除了这 8 种同步操作之外，还规定了一些同步规则来保证这些同步操作的正确执行。

 

Java内存区域（JVM内存结构）和Java内存模型（JMM）有何区别：

　　· 内存结构是指 Jvm 运行时将数据分区域存储,强调对内存空间的划分。

　　· 而内存模型(Java Memory Model,简称 JMM )是定义了线程和主内存之间的抽象关系,即 JMM 定义了 JVM 在计算机内存(RAM)中的工作方式,是虚拟机的内存管理模型,是一种虚拟机工程规范。

 

happens-before原则：

　　逻辑时钟并不度量时间本身，仅区分事件发生的前后顺序，其本质就是定义了一种 happens-before 关系。

　　JSR 133 引入了 happens-before 这个概念来描述两个操作之间的内存可见性。

 为什么需要 happens-before 原则？

　　happens-before 原则的诞生是为了程序员和编译器、处理器之间的平衡。程序员追求的是易于理解和编程的强内存模型，遵守既定规则编码即可。编译器和处理器追求的是较少约束的弱内存模型，让它们尽己所能地去优化性能，让性能最大化。

happens-before 原则的设计思想其实非常简单：

　　· 为了对编译器和处理器的约束尽可能少，只要不改变程序的执行结果（单线程程序和正确执行的多线程程序），编译器和处理器怎么进行重排序优化都行。

　　· 对于会改变程序执行结果的重排序，JMM 要求编译器和处理器必须禁止这种重排序。

JSR-133 对 happens-before 原则的定义：

• 如果一个操作 happens-before 另一个操作，那么第一个操作的执行结果将对第二个操作可见，并且第一个操作的执行顺序排在第二个操作之前。
• 两个操作之间存在 happens-before 关系，并不意味着 Java 平台的具体实现必须要按照 happens-before 关系指定的顺序来执行。如果重排序之后的执行结果，与按 happens-before 关系来执行的结果一致，那么 JMM 也允许这样的重排序。

　　happens-before 原则表达的意义其实并不是一个操作发生在另外一个操作的前面，虽然这从程序员的角度上来说也并无大碍。更准确地来说，它更想表达的意义是前一个操作的结果对于后一个操作是可见的，无论这两个操作是否在同一个线程里。

 

happens-before 常见规则有哪些？谈谈你的理解？

　　happens-before 的规则就 8 条，说多不多，重点了解下面列举的 5 条即可。

1. 程序顺序规则 ：一个线程内，按照代码顺序，书写在前面的操作 happens-before 于书写在后面的操作；
2. 解锁规则 ：解锁 happens-before 于加锁；
3. volatile 变量规则 ：对 volatile 变量的写操作的结果对于发生于其后的任何操作都是可见的。
4. 传递规则 ：如果 A happens-before B，且 B happens-before C，那么 A happens-before C；
5. 线程启动规则 ：Thread 对象的 start()方法 happens-before 于此线程的每一个动作。

　　如果两个操作不满足上述任意一个 happens-before 规则，那么这两个操作就没有顺序的保障，JVM 可以对这两个操作进行重排序。

happens-before 和 JMM 什么关系？

并发编程三个重要特性：

1.原子性：一次操作或者多次操作，要么所有的操作全部都得到执行并且不会受到任何因素的干扰而中断，要么都不执行。

　　在 Java 中，可以借助synchronized 、各种 Lock 以及各种原子类实现原子性。

　　synchronized 和各种 Lock 可以保证任一时刻只有一个线程访问该代码块，因此可以保障原子性。各种原子类是利用 CAS (compare and swap) 操作（可能也会用到 volatile或者final关键字）来保证原子操作。

2.可见性：当一个线程对共享变量进行了修改，那么另外的线程都是立即可以看到修改后的最新值。

　　在 Java 中，可以借助synchronized 、volatile 以及各种 Lock 实现可见性。

　　如果我们将变量声明为 volatile ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。

3.有序性：由于指令重排序问题，代码的执行顺序未必就是编写代码时候的顺序。

指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致 ，所以在多线程下，指令重排序可能会导致一些问题。

　　在 Java 中，volatile 关键字可以禁止指令进行重排序优化。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。当然JMM是通过Happens-Before 规则来保证有序性的。