一、CPU缓存架构与一致性协议

1.1 CPU缓存架构

现代 CPU 的发展非常快，内存的速度已经完全跟不上。如果将CPU完成一个基本操作所用的时间定义为时钟周期，那么 CPU 的指令处理速度要比内存的加载速度快100 倍左右。

为了解决这个性能上的鸿沟，现代 CPU 架构往往采用如下图所示的缓存架构：

在多核CPU和主存（Main Memory）之间引入三级高速缓存——L1、L2、L3。

越靠近CPU的缓存，成本造价越高、性能越强、存储空间越小，其中 L3 缓存是多核共享，而L1、L2 是核内私有。

1.2 缓存行与伪共享问题

缓存行 Cache Line 是高速缓存一次读取内存数据的最小单位。目前最常见的 Intel cpu 的缓存行大小是 64 Bytes。
连续的数据很有可能由于数据跨度恰好在一个缓存行内，就很有可能会被CPU加载到 L1、L2、L3 高速缓存中。

由于高速缓存的存在，引出了缓存一致性协议，它可以保证 L1、L2、L3 中的数据在多核CPU和并发场景下不会出现线程不一致问题。早期的解决方案并不是各种缓存一致性方案，而是采用总线锁的方式。

总线锁，顾名思义就是将高速缓存与主内存之间的总线上锁，只允许一个线程去获取并操作上锁数据，处理完成后释放锁，并将数据从缓存中刷回主存。这种方式虽然安全，但也牺牲了很大的性能。于是，人们又引入了诸如 MESI 的缓存一致性协议。简单的说，就是给缓存数据做标记，如果CPU发现缓存的数据失效了，就必须从主存中重新加载最新的数据。

那什么又是伪共享呢？

伪共享是缓存行加载数据时必然会存在的性能损耗问题。当对象中包含线程局部变量，且尺寸大小小于 64 字节，就有可能发生伪共享问题。

再具体点，内存地址连续的不同变量被加载到了同一个缓存行中，而同一个缓存行中的多个变量，又不一定是CPU所需的，这种情况就是伪共享。

由于伪共享的存在，CPU核心中的高速缓存加载了本不需要数据，又在“缓存一致性协议”的要求下，不得不在这些无用数据失效后重新加载缓存，导致缓存失效，或造成性能损耗：

如上图所示，x、y 两个变量由 Main Memory 加载到 core 1 和 core 2两个核心的 L1、L2 缓存中。如果线程A、B 跑在两个核心上，且线程 A 修改 core 1 中的 x，由于缓存一致性协议， core 2 中的 x 变量将会失效，它必须从主内存中重新加载，这样频繁的加载、访问主内存， core 2 中的 L1、L2 缓存几乎等于失效。

1.3 MESI 缓存一致性协议

MESI是缓存锁的实现方式之一，注意这是 CPU 缓存一致性，并非通常说的应用缓存。有些无法被缓存的数据或跨多个缓存行的数据依然必须使用总线锁。

MESI 的核心思想是为每个 Cache Line 标记 4 种状态：

1. 若缓存数据更改过，则将 Cache Line 标记为 M
2. 如果缓存数据是独享，则标记为 E
3. 如果数据是被多个CPU读取，则标记为 S
4. 如果数据被其他CPU修改过，则标记为 I

1.4 伪共享的解决办法

Java 7 之前可以采用字节填充的方式，例如针对不同操作系统和对象头的大小，补齐多个 long 类型的空数据。
但这种方式在 Java 7 的某个版本中会出现 填充失效问题，原因是该版本的虚拟机优化了未使用 field 的排布。

在 Java 8 加入 @Contended 注解会帮助增加128 字节的 padding，并且需要开启 -XX:-RestrictContended 选项才能生效。

虽然解决了伪共享的问题，但是这种填充的方式也浪费了缓存资源，而且缓存又小又贵，时间和空间的取舍要酌情考虑。

二、JMM Java 内存模型

2.1 JMM 简介

JMM 全称是 “Java Memory Model”，Java 内存模型。
因为在不同的硬件生产商和操作系统下，内存的访问方式各有所差异，这样就会造成相同的代码出现不一样的问题，而 JMM 屏蔽掉了各种操作系统的内存访问差异，以实现“Write Once，Run Anywhere”的目标。

JMM 中规定所有的变量都存储在主内存 （Main Mem）中，包括实例变量、静态变量，但是不包括局部变量和方法参数。每条线程都有自己的工作内存（Work Mem），线程私有。工作内存中保存的是线程的变量从主内存中的拷贝副本。

这种结构的基本工作方式是：线程对变量的读和写都必须在工作内存中进行，而线程之间变量值的传递均需要通过主内存来完成。如下图所示，注意与Java 内存结构（堆栈等）等概念区分开。

2.2 原子性、可见性、有序性

整个 JMM 实际上是围绕着三个并发特征建立起来的——原子性、可见性、有序性。

1. 原子性：和事务的 ACID 的 原子性概念一致，即表示一个操作中间不可分割，不能中断，执行过程不允许被其他线程打扰。 JMM 只能保证基本操作的原子性，如果要保证一个代码块的原子性，Java 提供了 synchronized 关键字，它对应了 monitorentrer 和 monitorexit 字节码指令。
2. 可见性：不同的线程对数据的修改结果可以被其他线程感知到，这就是可见性。synchronized 是保证可见性的最常用的操作，除此之外，还有 volatile 关键字，它是较弱的同步机制。
3. 有序性：字节码指令的执行顺序不可重排。可以使用 synchronized 或 volatile 保证多线程之间操作的有序性。volatile是使用内存屏障达到禁止指令重排，保证有序性。而 synchronized 则以互斥锁的形式要求上锁的资源必须按序执行。

2.3 八大内存交互操作

说是 8 种内存交互操作：

• lock 和 unlock：锁定与解锁。作用于主内存的变量，将其设置为线程独占或解除。
• Read 和 Write：发生在主内存和工作内存之间，将变量传输到工作内存，将从工作内存得到的值放入主内存中。
• Load 和 Store：作用于工作内存的变量，将工作内存中的变量放入副本中，将工作内存中的变量传输到主内存中。
• Use 和 Assign：将工作内存中的变量传输到执行引擎，将一个从执行引擎中接收到的值赋值给工作内存的副本。

使用规则：

• 不允许 read、load、store、write 操作之一单独出现，即 read 操作后必须 load，store后必须 write。
• 不允许线程丢弃它最近的 assign 操作，即工作内存中的变量修改之后，必须告知主存。
• 不允许线程将没有 assign 的数据从工作内存同步到主存。
• lock 和 unlock 必须成对出现。
• 新的变量必须由主存中诞生。
• 如果对一个变量进行 lock，会清空所有工作内存中此变量的值。在执行引擎使用这个变量前，必须重新 load 或 assign 。
• unlock 之前，必须将此变量同步回主内存。

2.4 happens-before 原则

happens-before是JMM提供的有序性保证。在理解它的概念之前，需要了解一下弱内存模型和强内存模型。

弱内存模型——weak memory model
弱内存模型中，loadload、loadstore、storestore、storeload 四种内存重排序都有可能发生。只要不改变单线程行为，弱内存模型可随意对代码进行重排序，这是一种近乎不存在任何保证的模型。

强内存模型
Java的内存模型属于一种叫做 “顺序一致性” 的强内存模型。在顺序一致性模型中，不再存在重排序，Java的JMM就属于这种强内存模型。

虽然 JMM 属于最高级别的强内存模型——顺序一致性内存模型，但并不是说Java 不允许重排序，而是在某些情况下，可以支持严格限制重排序的目的，如volatile。而弱内存模型是无法满足这种保证的。

happens-before 是 JMM 提供的一系列关于重排序问题的规则。可以概括为：

If one action happens-before another, then the first is visible to and ordered before the second.
如果一个动作 happens-before 另一个动作，那么前者的执行会排在后者的前面，并且（其结果）对后者可见。
《java language specification 8》

可以分为以下两种策略：

1. 对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序。
2. 对于不会改变程序执行结果的重排序，JMM对编译器和处理器不做要求（JMM允许这种重排序）。

这两个策略概括起来，可以这样理解——只要不改变程序的执行结果，编译器和处理器想怎么优化就怎么优化。

例如，如果编译器经过细致的分析，认定一个锁只能被一个线程访问到，那么这个锁可以被消除。
又例如，编译器认定一个 volatile 变量只会被单个线程访问到，那么它可以把这个 volatile 变量当做一个普通变量对待。

happens-before 的具体规则如下：

1. 程序顺序执行，如果x和y是同一个线程的动作，并且在程序顺序中x出现在y之前，则 x happens-before y。
2. 如果动作 x 的结果需要同步给后面的动作 y ，那么 x happens-before y。也就是说，synchronized 修饰的情况，先获得锁的线程就是 x ，后获得锁的就是 y，前者的执行结果需要同步给 y，那么同样会有 x happens-before y。
3. 传递性，x happens-before y，y happens-before z，那么 x happens-before z。

根据这些规则，以下这些场景都是 happens-before 的情况：

1. 对象锁的解锁，发生在对象锁后续的上锁之前
2. 对 volatile 变量的写操作，一定发生在后续对该 volatile 变量的读操作之前。
3. 对线程的 start() 方法的调用，一定发生在线程内其他操作之前。
4. 线程中的所有操作，一定发生在该线程 join() 方法结束之前。
5. 任何对象的默认初始化一定发生在程序中其他操作之前。

总之，happens-before 定义了两个动作发生资源竞争时的时间顺序，是JMM 描述特定动作前后执行顺序的一种抽象关系。它原则上不允许重排序，但在一些不影响程序执行结果的情况下，乱序执行也是可以的。