高性能 Disruptor——消除伪共享

最新推荐文章于 2025-02-15 17:00:41 发布

原创

最新推荐文章于 2025-02-15 17:00:41 发布 · 2.5k 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#disruptor #伪共享

一、CPU Cache

存储设备往往是速度越快价格越昂贵，速度越快价格越低廉。在计算机中，CPU 的速度远高于主存的速度，而主存的速度又远高于磁盘的速度。为了解决不同存储部件的速度不对等问题，让高速设备充分发挥性能，引入了多级缓存机制。

为了解决内存和 CPU 的速度不匹配问题，相继引入了 L1 Cache、L2 Cache、L3 Cache，数字越小，容量越小，速度越快，位置越接近 CPU。

现在的 CPU 都是由多个处理器，每个处理器由多个核心构成。一个处理器对应一个物理插槽，不同的处理器间通过 QPI 总线相连。一个处理器间的多核共享 L3 Cache。一个核包含寄存器、L1 Cache、L2 Cache，下图是Intel Sandy Bridge CPU架构：

二、缓存行与伪共享

缓存中的数据并不是独立的进行存储的，它的最小存储单位是缓存行，缓存行的大小是2的整数幂个字节，最常见的缓存行大小是 64 字节。CPU 为了执行的高效，会在读取某个对象时，从内存上加载 64 的整数倍的长度，来补齐缓存行。

以 Java 的 long 类型为例，它是 8 个字节，假设我们存在一个长度为 8 的 long 数组 arr，那么CPU 在读取 arr[0] 时，首先查询缓存，缓存没有命中，缓存就会去内存中加载。由于缓存的最小存储单位是缓存行，64 字节，且数组的内存地址是连续的，则将 arr[0] 到 arr[7] 加载到缓存中。后续 CPU 查询 arr[6] 时候也可以直接命中缓存。

现在假设多线程情况下，线程 A 的执行者 CPU Core-1 读取 arr[1]，首先查询缓存，缓存没有命中，缓存就会去内存中加载。从内存中读取 arr[1] 起的连续的 64 个字节地址到缓存中，组成缓存行。由于从arr[1] 起，arr 的长度不足够 64 个字节，只够 56 个字节。假设最后 8 个字节内存地址上存储的是对象 bar，那么对象 bar 也会被一起加载到缓存行中。

现在有另一个线程 B，线程 B 的执行者 CPU Core-2 去读取对象 bar，首先查询缓存，发现命中了，因为 Core-1 在读取 arr 数组的时候也顺带着把 bar 加载到了缓存中。

这就是缓存行共享，听起来不错，但是一旦牵扯到了写入操作就不妙了。

假设 Core-1 想要更新 arr[7] 的值，根据 CPU 的 MESI 协议，那么它所属的缓存行就会被标记为失效。因为它需要告诉其他的 Core，这个 arr[7] 的值已经被更新了，缓存已经不再准确了，你必须得重新去内存拉取。但是由于缓存的最小单元是缓存行，因此只能把 arr[7] 所在的一整行给标识为失效。

此时 Core-2 就会很郁闷了，刚刚还能够从缓存中读取到对象 bar，现在再读取却被告知缓存行失效，必须得去内存重新拉取，延缓了 Core-2 的执行效率。

这就是缓存伪共享问题，两个毫无关联的线程执行，一个线程却因为另一个线程的操作，导致缓存失效。这两个线程其实就是对同一缓存行产生了竞争，降低了并发性。

三、Disruptor 缓存行填充

Disruptor 为了解决伪共享问题，使用的方法是缓存行填充。这是一种以空间换时间的策略，主要思想就是通过往对象中填充无意义的变量，来保证整个对象独占缓存行。

举个例子，以 Disruptor 中的 Sequence 为例，在 volatile long value 的前后各放置了 7 个 long 型变量，确保 value 独占一个缓存行。

public class Sequence extends RhsPadding {
   
   
    private static final long VALUE_OFFSET;
    
    static {
   
   
        VALUE_OFFSET = UNSAFE.objectFieldOffset(Value.class.getDeclaredField("value"