Cache一致性协议与伪共享问题

Cache一致性协议

在说伪共享问题之前，有必要聊一聊什么是Cache一致性协议

局部性原理

时间局部性：如果一个信息项正在被访问，那么在近期它很可能还会被再次访问
比如循环、方法的反复调用等

空间局部性：如果一个存储器的位置被引用，那么将来他附近的位置也会被引用
比如顺序结构、数组

Cache的作用

CPU在摩尔定律的指导下以每18个月翻一番的速度在发展，然而内存和硬盘的发展速度远远不及CPU。为了解决这个问题，CPU厂商在CPU中内置了少量的高速缓存Cache，以解决访存速度和CPU运算速度之间不匹配的问题

带Cache的CPU访存过程

CPU和Cache交换数据以字为单位。Cache与主存以块为单位，一个缓存行（Cache Line）对应一个主存块

读：

• Cache命中，则直接从Cache中读取数据
• Cache不命中，则访问主存，并将一个主存块调入Cache中，存入为一个缓存行。这个过程中可能由于Cache满而发生替换，替换算法包括RAND、FIFO、LRU、LFU

写：

• Cache命中时
  • 写回法（write back）：CPU只将数据写入Cache，只有当数据调出Cache时，才写入主存
  • 写穿法（write through）：CPU同时将数据写入Cache和主存
• Cache不命中时
  • 写分配法：从主存中将数据块调入Cache，并修改Cache，和写回法配合使用
  • 非写分配法：只写入主存，不调入Cache，和写穿法配合使用

Cache和主存的映射方式（三种）：直接映射、全相联映射、组相联映射

如果是单CPU结构，这么执行没有其他问题。但是现代系统往往包含多个CPU，每个CPU都有各自的Cache。多核CPU的情况下有多个一级缓存，如何保证缓存内部数据的一致性，本质上就是为了防止数据的脏读，这里就引出了Cache一致性协议——MESI。注意，这并不是唯一的缓存一致性协议，还有其他协议如MOSEI（相对于MESI多引入了一个Owned状态，并重新定义了S状态）、MESIF（配合NUMA架构）等，这里不多介绍

MESI协议详解

MESI（Modified Exclusive Shared Or Invalid），也称伊利诺斯协议，是一种广泛使用的、支持写回策略的缓存一致性协议。MESI协议其实就是使用4种状态来标记各个缓存行（Cache Line）的状态，而这些状态英文首字母缩写就构成了“MESI”

MESI协议中的各种状态

每个缓存行都使用一个状态来标记，该状态总共有4种，使用2bit进行存储：

• M（Modified）：相应的数据只被缓存在该CPU的Cache中，但数据是被修改过的（脏数据），即与主存中的数据不一致。该缓存行中的内存需要在未来的某个时间点，但必须是其它CPU读取主存中相应内存之前，将数据写回主存
• E（Exclusive）：相应的数据只被缓存在该CPU的缓存中，数据是未被修改过的，与主存中的数据一致
• S（Shared）：相应的数据被多个CPU缓存，且各个CPU的Cache中的数据和主存都是一致的
• I（Invalid）：该缓存行中的数据是无效的，因为有其他CPU修改了数据

总线嗅探机制（监听）

每个CPU都可以感知其他CPU的行为，比如读、写某个缓存行，这就是嗅探机制，也称监听。所有的缓存行（除了Invalid状态）都需要监听自己和其他CPU对相应的缓存行的读写操作，也称触发事件，从而根据触发事件和自身状态，进行状态的转换

各种触发事件

触发事件	描述
本地读取（Local Read）	本CPU读取本Cache的数据
本地写入（Local Write）	本CPU向本Cache写入数据
远端读取（Remote Read）	其他CPU读取它们各自Cache的数据
远端写入（Remote Write）	其他CPU向它们各自Cache写入数据

MESI中各个状态之间的转换

下图描述了当前缓存行在不同触发事件下的状态切换：

下表是对上图的一个详细解释：

举例

假设CPU0、CPU1、CPU2、CPU3中有一个缓存行（包含变量x）都是S状态
此时CPU1要对变量x进行写操作，这时候通过总线嗅探机制，CPU0、CPU2、CPU3中的缓存行会置为I状态（无效），然后给CPU1发响应，收到全部响应后CPU1会完成对变量x的写操作，并更新CPU1内的缓存行为M状态，但不会将数据x同步到主存中
接着CPU0想要对变量x执行读操作，却发现本地缓存行是I状态，就会触发CPU1去把缓存行写回到主存中，然后CPU0再去主存中同步最新的值

MESI协议解决了缓存一致性的问题，但其中有一个问题，那就是需要在等待其他处理器全部回复后才能进行下一步操作，这种等待明显是不能接受的，下面就继续来看看如何解决处理器等待的问题

写缓冲和无效化队列

1、写缓冲（Store Buffer）
实际CPU1在执行写操作要更新缓存行时，其实并不会乖乖地等待其他CPU的缓存行状态都置为I状态，才去执行写操作，这样效率很低。实际做法是：每个CPU都引入一个写缓存器，相当于在CPU和Cache之间又加了一层buffer，在CPU执行写操作时直接写入写缓冲，然后去忙其他事，等其他CPU的缓存行都置为I后，CPU1才把buffer中的数据写入到Cache中

2、无效化队列（Invalidate Queue）
引入写缓冲后，CPU1就可以不用等待其他CPU中对应的缓存行失效而去忙别的。不过其他CPU也不傻，实际上他们也不会真的把缓存行置为I后，才给CPU1发响应。他们会写入一个无效化队列，还没把缓存置为I状态就发送响应了
之后CPU会异步扫描无效化队列，将缓存行置为I状态。和写缓冲不同的是，CPU1之后读变量x时，会先查写缓冲，再查Cache。而CPU0要读变量x时，不会先去检查无效化队列，所以存在脏读的可能

总之，写缓冲器解决了写数据时要等待其他处理器响应的问题，无效化队列解决了删除数据的等待问题。不管是写缓冲器还是无效化队列，其实都是为了减少处理器的等待时间，采用了空间换时间的方式来实现命令的异步处理

不过既然是异步处理，就又会引发新的问题——内存重排序和内存可见性问题，这里不过多赘述，请参考网上其他文章，之后博主也会跟进

看懂这篇，才能说了解并发底层技术

多级缓存架构对MESI的影响

现代系统都会采用多级缓存架构，L1-L3级缓存，其中L3缓存是所有CPU共享的一个缓存，但MESI的描述中并没有涉及L3缓存。其实上文提到的所有跟“主存”交换数据的地方，在L3缓存存在的情况下，都应该替换为L3缓存。比如我上一节举的例子中，CPU0中某缓存行是I，CPU1 中是M。当CPU0想到执行local read操作时，就会触发CPU1中的缓存写入到主存中，然后CPU0从主存中取最新的缓存行。其实这里的描述是不准确的，因为由于L3缓存的存在，这里其实是直接从L3缓存读取缓存行，而不直接访问主存

个人认为是如果在描述MESI的状态流转时，如果引入L3缓存，会使得描述过于复杂，因此一般的描述都会刻意忽略L3缓存

作者：酒冽        出处：https://www.cnblogs.com/frankiedyz/p/15786362.html
版权：本文版权归作者和博客园共有
转载：欢迎转载，但未经作者同意，必须保留此段声明；必须在文章中给出原文连接；否则必究法律责任

伪共享

由于内存和Cache之间的交换单位是内存块/缓存行，因此如果访问一个变量，会将一整个内存块读入一个缓存行。但是如果多个线程访问的变量不相同，且这些变量在内存中的位置临近，那么很可能在同一个缓存行中。在Cache一致性协议（如MESI协议）的约束下，多个线程（CPU）在并行读写相对应的缓存行会有限制，因此其他线程不得不去访问低级别的Cache甚至是主存，这会导致cache没有起到真正的作用，程序性能下降

伪共享示例

如图，线程1访问变量x，而线程2访问变量y，而这两个变量在内存中的位置临近（在同一个内存块中），虽然线程都将该内存块读入到各自的工作内存（Cache）中，但是在Cache一致性协议的约束下，同一时间两个线程很难自由地读写相同位置的缓存行，那么可能就会让其中一个线程去低级别的内存中读写数据，性能因此降低，这就是伪共享

一般地址连续的多个变量更可能被放在同一个缓存行中，例如创建数组时，数组中的多个元素更可能被放入同一个缓存行中

如何避免伪共享问题

JDK8之前
JDK8之前，使用字节填充的方式，即创建一个变量时，使用填充字段填充该变量所在的缓存行，从而避免多个变量被放入同一个缓存行中，如下：

public final static class FilledLong {
    public volatile long value = 0L;
    public long p1, p2, p3, p4, p5, p6;
}

一般来说，缓存行为64 Byte，而经过填充的FilledLong对象有7*8 Byte=56 Byte，而FilledLong对象的对象头也有8 Byte，正好填满一个缓存行

JDK8及之后
JDK8提供了一个注解——sun.misc.Contended，用于解决伪共享问题，上述代码可以修改为如下：

@sun.misc.Contended
public final static class FilledLong {
	public volatile long value = 0L;
}

在Thread类中，也有这样的字段，如下：

@sun.misc.Contended("tlr")
long threadLocalRandomSeed;

/** Probe hash value; nonzero if threadLocalRandomSeed initialized */
@sun.misc.Contended("tlr")
int threadLocalRandomProbe;

/** Secondary seed isolated from public ThreadLocalRandom sequence */
@sun.misc.Contended("tlr")
int threadLocalRandomSecondarySeed;

但是，@Contended注解只用于Java核心类，而用户类路径下的类使用该注解，需要添加JVM参数-XX:-RestrictContended。填充宽度默认为128 Byte，也可以自定义宽度，通过JVM参数-XX:ContendedPaddingWidth来设定