计算机内存模型、缓存一致性、MESI 协议

计算机内存模型

由于计算机的存储设备与运算器的运算速度之间有着几个数量级的差距，所以现代计算机系统不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存(cache)来作为内存与处理器之间的缓冲。
将运算需要用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无需等待缓慢的内存读写了。

缓存一致性

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也引入了新的问题：缓存一致性(Cache Coherence)。
在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存(Main Memory)。

当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致的情况，如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为准呢？

MESI协议

为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作，这类协议有MSI、MESI、MOSI、Synapse、Firefly及DragonProtocol等等。
Java虚拟机内存模型中定义的内存访问操作与硬件的缓存访问操作是具有可比性的。

MESI是指4种状态的首字母，每个Cache line有4个状态，可用两个bit表示。

  • M 修改(Modify)
    缓存块已经被改动，必须被写回主存，其他处理器不能再缓存这个块。
  • E 独享、互斥(Exclusive)
    缓存块还没有被改动，且其他处理器不能装入这个缓存块。
  • S 共享(Shared)
    缓存块未被改动，且其他处理器能够装入这个缓存块。
  • I 无效(Invalid)
    缓存块中的数据无效。

可见性、原子性、有序性、happens-before、内存屏障、synchronized、volatile、final、锁

Java内存模型

12.3.1 主内存与工作内存

Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。
此处的变量(Variable)与java编程中所说的变量略有区别，它包括了实例字段、静态字段和构成数组对象的元素，但是不包括局部变量和方法参数，因为后者是线程私有的，不会被共享，自然就不存在竞争问题。
为了获得较好的执行效能，java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存在和主内存进行交互，也没有限制即时编译器调整代码执行顺序这类权力。

Java内存模型规定了所有的变量都存储在主内存(MainMemory)中(可以类比物理机的主内存，此处仅是虚拟机内存的一部分)。
每条线程还有自己的工作内存(WorkingMemeory，可与处理器高速缓存类比)，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作(读取、赋值等)都必须在工作内存中进行，而不能直接读写主内存中的变量。
不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。

12.3.2 内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java内存模型中定义了以下8中操作(虚拟机实现时必须保证每一种操作都是原子的、不可再分的)来完成：

  • lock(锁定)：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
  • unlock(解锁)：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
  • read(读取)：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。
  • load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
  • use(使用)：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。
  • assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
  • store(存储)：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
  • write(写入)：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中。

12.3.4 对于volatile型变量的特殊规则

关键字volatile可以说是java虚拟机提供的最轻量级的同步机制，但是它并不容易被正确地、完整地理解，以至于许多程序员都不去使用它，遇到需要处理多线程数据竞争的问题时一律使用synchronized来进行同步。

Java内存模型对volatile专门定义了一些特殊的访问规则，在介绍这些规则定义之前，先介绍一下这个关键字的作用。
当一个变量被定义成volatile之后，它将具备两种特性，第一是保证此变量对所有线程的可见性；第二是禁止指令重排序优化。

两种特性产生的原因是Java内存模型对volatile变量的三条特殊规则。

  • 规则1
    只有当线程T对变量V执行的前一个操作为load时，线程T才可以对变量V执行use操作;
    并且只有当线程T对变量V执行的后一个操作为use时，线程T才可以对变量V执行load操作。

    该规则令read - load - use形成整体性的原子操作，使得volatile变量在被使用前会从主内存中读取最新值。

  • 规则2
    只有当线程T对变量V执行的前一个操作为assign时，线程T才可以对变量V执行store动作;
    并且只有当线程T对变量V执行的后一个操作为store时，线程T才可以对变量V执行assign动作。

    该规则令assign - store - write形成整体性的原子操作，使得volatile变量在被赋值后会立即同步回主内存。

  • 规则3
    假定操作A是线程T对变量V实施的use或assign操作，操作F是和操作A关联的load或store操作，操作P是和操作F相关联的read或write操作；
    假定操作B是线程T对变量W实施的use或assign操作，操作G是和操作B关联的load或store操作，操作Q是和操作G相关联的read或write操作；
    如果A先于B，则P先于Q。

这里的可见性是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的，而普通变量不能做到这一点，变量值在线程间传递均需要通过主内存来完成。
如：线程A修改一个普通变量的值，然后向主内存进行回写，另外一条线程B在线程A回写完成了之后再从主内存进行读取操作，新变量的值才会对线程B可见。

关于volatile变量的可见性，经常会被开发人员误解，认为以下描述成立：“volatile变量对所有线程是立即可见的，对volatile变量所有的写操作都能立刻反应到其他线程之中，换句话说，volatile变量在各个线程中是一致的，所以基于volatile变量的运算在并发下是安全的”。
这句话的论据部分并没有错，但是其论据并不能得出“基于volatile变量的运算在并发下是安全的”这个结论。
volatile变量在各个线程的工作内存中不存在一致性问题(在各个线程的工作内存中volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题)，但是java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的。

由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁(使用synchronized或java.util.concurrent中的原子类)来保证原子性：

  1. 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值；
  2. 变量不需要与其他的状态变量共同参与不变约束。

使用volatile变量的第二个语义是禁止指令重排序优化，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，这也就是Java内存模型中描述的所谓的“线程内表现为串行的语义”(Within-Thread-As-If-Serial Semantics)。

volatile与内存屏障
  • 在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障
  • 在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障

解决了volatile的语义问题，再来看看在众多保障并发安全的工具中选用volatile的意义——它能让我们的代码比使用其他的同步工具更快吗？
确实在某些情况下，volatile同步机制的性能要优于锁(使用synchronized关键字或java.util.concurrent包里面的锁)，但是由于虚拟机对锁实行的许多消除和优化，使得我们很难量化地说volatile就会比synchronized快上多少。
如果让volatile自己与自己比较，则可以确定一个原则：volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢上一些，因为它需要在本地代码中插入许多内存屏障(Memory Barrier或Memory Fence)指令来保证处理器不发生乱序执行。
不过即便如此，大多数情况下volatile的总开销仍然要比锁来得低，我们在volatile与锁中选择的唯一判断依据仅仅是volatile的语义能否满足使用场景的需求。

12.3.4 对于long和double型变量的特殊规则

Java内存模型只保证32位数据类型操作的原子性，对于64位数据类型（long和double）操作则由两个32位原子操作组成。

java内存模型要求lock、unlock、read、load、assign、use、store和write这八个操作都具有原子性。
但是对于64位的数据类型(long和double)，在模型中特别定义了一条宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这四个操作的原子性，这点就是所谓的long和double的非原子性协定。

如果有多个进程共享一个并未声明为volatile的long或double类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了“半个变量”的数值。
不过这种读取到“半个变量”的情况非常罕见，因为java内存模型虽然允许虚拟机不把long和double变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为具有原子性的操作，而且还“强烈建议”虚拟机这样实现。
在实际开发中，目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待，因此我们在编写代码时一般不需要将用到的long和double变量专门声明为volatile。

12.3.5 原子性、可见性与有序性

Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这三个特征来建立的。
想要线程安全，必须保证原子性、可见行、有序性。

原子性(Atomicity)

由Java内存模型来直接保证原子性变量操作包括read、load、assign、use、store和write这六个，大致可以认为基本数据类型的访问读写是具备原子性的(long和double的非原子性协定例外)。
如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求。
尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

可见性(Visibility)

可见性就是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。
Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此。
普通变量与volatile变量的区别是volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新，因此可以说volatile保证了多线程操作时变量的可见性，而普通变量不能保证这一点。

除了volatile之外，java还有两个关键字能实现可见性，它们是synchronized和final。
同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(执行store和write操作)”这条规则获得的。
而final关键字的可见性是指被final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把“this”的引用传递出去(this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一半”的对象)，那么在其他线程中就能看见final字段的值。

有序性(Ordering)

Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。
前半句是指“线程内表现为串行的语义”，后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性。
volatile关键字本身就包含了禁止指令重排序的含义。
而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。

12.3.6 先行发生规则（happens-before）

先行发生原则（happens - before），如果操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到。