【闲话开篇】:这段时间项目接近尾声,我终于闲了一点,又拿起了早先未看完的书《JAVA高并发程序设计》,强迫自己学习。看到其中介绍《无锁的缓存框架:Disruptor》时,接触到了一个概念——伪共享(false sharing),说是会影响并发程序的执行性能,被很多人描述成无声的性能杀手,突然感觉到了自己知识的匮乏,罪过啊。
伪共享(false sharing),究竟是怎样一回事呢?不急,我们先倒杯水边喝边回顾,以前上学时丢下的计算机组成原理相关知识点。
CPU 缓存(Cache Memory)是位于CPU与内存之间的临时存储器,它的容量比内存小很多,但是交换速度却比内存要快得多。CPU和主内存之间有好几级缓存,CPU缓存可以分为一级缓存,二级缓存,部分高端CPU还具有三级缓存。每一级缓存中所储存的全部数据都是下一级缓存的一部分,越靠近 CPU 的缓存越快也越小。
高速缓存的出现主要是为了解决CPU运算速度与内存读写速度不匹配的矛盾,因为CPU运算速度要比内存读写速度快很多,这样会使 CPU 花费很长时间等待数据到来或把数据写入内存。在缓存中的数据是内存中的一小部分,但这一小部分是短时间内CPU即将访问的,当CPU调用大量数据时,就可避开内存直接从缓存中调用,从而加快读取速度。
如果我们的程序正在多次对同一数据块做相同的运算,那么在执行运算的时候把它加载到离 CPU 很近的缓存中就能大大的提高程序运行速度。
我们以L1、L2、L3分别表示一级缓存、二级缓存、三级缓存,按照数据读取顺序和与CPU结合的紧密程度,速度是L1 >L2 > L3 >主存,容量是L1< L2< L3< 主存。
L1 缓存很小但是很快,并且紧靠着在使用它的 CPU 内核,L2 大一些,也慢一些,并且仍然只能被一个单独的 CPU 核使用,L3 更大,更慢,并且被单个插槽上的所有 CPU 核共享,最后是主存,由全部插槽上的所有 CPU 核共享。拥有三级缓存的的 CPU,到三级缓存时能够达到95%的命中率,只有不到5%的数据需要从内存中查询。 三级缓存示意图:
缓存行 (Cache Line) 是 CPU 缓存中的最小单位,CPU 缓存由若干缓存行组成,一个缓存行的大小通常是 64 字节(备注:取决于 CPU,本文基于64字节,其他长度的如32字节等本文不作讨论),并且它有效地引用主内存中的一块地址。一个 Java 的 long 类型是 8 字节,因此在一个缓存行中可以存 8 个 long 类型的变量。 所以,如果你访问一个 long 数组,当数组中的一个值被加载到缓存中,它会额外加载另外 7 个,以致你能非常快地遍历这个数组。事实上,你可以非常快速的遍历在连续的内存块中分配的任意数据结构。而如果你在数据结构中的项在内存中不是彼此相邻的(如链表),你将得不到缓存加载所带来的优势,并且在这些数据结构中的每一项都可能会出现缓存未命中的情况。
MESI 协议是基于Invalidate的高速缓存一致性协议,并且是支持回写高速缓存的最常用协议之一。
CPU 的缓存是以缓存行(cache line)为单位的,MESI协议描述了多核处理器中一个缓存行的状态。(现在主流的处理器都是用它来保证缓存的相干性和内存的相干性。)
在MESI协议中,每个缓存行有4个状态,分别是:
M(修改,Modified):本地处理器已经修改缓存行,即是脏行,它的内容与内存中的内容不一样,并且此 cache 只有本地一个拷贝(专有)
E(专有,Exclusive):缓存行内容和内存中的一样,而且其它处理器都没有这行数据
S(共享,Shared):缓存行内容和内存中的一样, 有可能其它处理器也存在此缓存行的拷贝
I(无效,Invalid):缓存行失效, 不能使用
在 MESI 协议中,每个Cache的Cache控制器不仅知道自己的读写操作,而且也监听其它Cache的读写操作。每个Cache line所处的状态根据本核和其它核的读写操作在4个状态间进行迁移。MESI 协议状态迁移图如下:
初始:一开始时,缓存行没有加载任何数据,所以它处于 I 状态。
本地写(Local Write):如果本地处理器写数据至处于 I 状态的缓存行,则缓存行的状态变成 M。
本地读(Local Read):如果本地处理器读取处于I状态的缓存行,很明显此缓存没有数据给它。此时分两种情况:
(1)其它处理器的缓存里也没有此行数据,则从内存加载数据到此缓存行后,再将它设成 E 状态,表示只有我
一家有这条数据,其它处理器都没有
(2)其它处理器的缓存有此行数据,则将此缓存行的状态设为 S 状态。(备注:如果处于M状态的缓存行,再
由本地处理器写入/读出,状态是不会改变的)
远程读(Remote Read):假设我们有两个处理器 c1 和 c2,如果 c2 需要读另外一个处理器 c1 的缓存行内容,
c1 需要把它缓存行的内容通过内存控制器 (Memory Controller) 发送给 c2,c2 接到后将相应的缓存行状
态设为 S。在设置之前,内存也得从总线上得到这份数据并保存。
远程写(Remote Write):其实确切地说不是远程写,而是c2得到c1的数据后,不是为了读,而是为了写。也算是
本地写,只是 c1 也拥有这份数据的拷贝,这该怎么办呢?c2 将发出一个 RFO (Request For Owner) 请求,
它需要拥有这行数据的权限,其它处理器的相应缓存行设为I,除了它自已,谁不能动这行数据。这保证了数据
的安全,同时处理 RFO 请求以及设置I的过程将给写操作带来很大的性能消耗。
了解了上述一些概念之后,咱们提出一个疑问?如果有多个线程操作不同的成员变量,但它们是相同的缓存行,这个时候会发生什么?
没错,伪共享(False Sharing)问题就发生了!咱们来看一张经典的CPU 缓存行示意图:
注释:一个运行在处理器 core1上的线程想要更新变量 X 的值,同时另外一个运行在处理器 core2 上的线程想要更新变量 Y 的值。
但是,这两个频繁改动的变量都处于同一条缓存行。两个线程就会轮番发送 RFO (Request For Owner) 消息,占得此缓存行的拥有
权。当 core1 取得了拥有权开始更新 X,则 core2 对应的缓存行需要设为 I 状态(失效态)。当 core2 取得了拥有权开始更新 Y,
则core1 对应的缓存行需要设为 I 状态(失效态)。轮番夺取拥有权不但带来大量的 RFO 消息,而且如果某个线程需要读此行数据时,
L1 和 L2 缓存上都是失效数据,只有L3缓存上是同步好的数据。从前面的内容我们知道,读L3的数据会影响性能,更坏的情况是跨槽
读取,L3 都出现缓存未命中,只能从主存上加载。
举例说明:
咱们以Java里面的ArrayBlockingQueue为例采用生产消费模型说明,ArrayBlockingQueue有三个成员变量:
- takeIndex:需要被取走的元素下标
- putIndex:可被元素插入的位置的下标
- count:队列中元素的数量
这三个变量很容易放到一个缓存行中,但是修改并没有太多的关联。所以每次修改,都会使之前缓存的数据失效,从而不能完全达到共享的效果。
当生产者线程put一个元素到ArrayBlockingQueue时,putIndex会修改,从而导致消费者线程的缓存中的缓存行无效,需要向上重新读取,这种无法充分使用缓存行特性的现象,称为伪共享。
看到此处,我们可以自行总结,关于伪共享给出一个非标准的定义: CPU 缓存系统中是以缓存行为单位存储的,当多线程修改互相独立的变量时,如果这些变量共享同一个缓存行,就会无意中影响彼此的性能,这就是伪共享。
程序用四个线程修改一数组不同元素的内容,元素类型为 VolatileLong,包含一个长整型成员 value 和 6 个没用到的长整型成员,value 设为 volatile 是为了让 value 的修改对所有线程都可见。主要代码如下:
public class FalseShare implements Runnable {
public static int NUM_THREADS = 4;
public final static long ITERATIONS = 500L * 1000L * 1000L;
private final int arrayIndex;
private static VolatileLong[] longs;
public static long SUM_TIME = 0l;
public FalseShare(final int arrayIndex) {
this.arrayIndex = arrayIndex;
}
private static void exeTest() throws InterruptedException {
Thread[] threads = new Thread[NUM_THREADS];
for (int i = 0; i < threads.length; i++) {
threads[i] = new Thread(new FalseShare(i));
}
for (Thread t : threads) {
t.start();
}
for (Thread t : threads) {
t.join();
}
}
public void run() {
long i = ITERATIONS + 1;
while (0 != --i) {
longs[arrayIndex].value = i;
}
}
public final static class VolatileLong {
public volatile long value = 0L;
// public long p1, p2, p3, p4, p5, p6; //缓存行填充
}
public static void main(final String[] args) throws Exception {
for (int j = 0; j < 10; j++) {
System.out.println("第" + j + "次...");
longs = new VolatileLong[NUM_THREADS];
for (int i = 0; i < longs.length; i++) {
longs[i] = new VolatileLong();
}
long start = System.nanoTime();
exeTest();
long end = System.nanoTime();
SUM_TIME += end - start;
}
System.out.println("平均耗时:" + SUM_TIME / 10);
}
}
第一次执行:
// public long p1, p2, p3, p4, p5, p6; //缓存行填充
第二次执行:
public long p1, p2, p3, p4, p5, p6; //缓存行填充
程序每次运行,循环10次,取平均耗时,耗时结果如下:
第一次:
平均耗时:28305116160
第二次:
平均耗时:14071204270
【实例说明】:一个缓存行有 64 字节,一个long占8个字节,而 Java 程序的对象头固定占 8 字节(32位系统)或 12 字节( 64 位系统默认开启压缩, 不开压缩为 16 字节),所以我们只需要填 6个无用的长整型补上6*8=48字节,让不同的 VolatileLong 对象处于不同的缓存行,就避免了伪共享( 64 位系统超过缓存行的 64 字节也无所谓,只要保证不同线程不操作同一缓存行就可以了)。
1.缓存行填充(让不同线程操作的对象处于不同的缓存行)
1)缓存行手动填充
2)使用Contended注解自动进行填充
2.使用编译指示,来强制每一个变量对齐(略)
1)CPU 缓存是以缓存行为单位进行操作的,产生伪共享问题的根源在于不同的CPU核同时操作同一个缓存行; 2)可以通过缓存行填充来解决伪共享问题,且Java8 中引入了@sun.misc.Contended注解来自动填充; 3)一个缓存行有四种状态,分别为:M(修改)E(专有)S(共享)I(无效); 4)每个缓存行所处的状态根据本核和其它核的读写操作在4个状态间进行迁移; 5)不是所有的场景都需要解决伪共享问题,因为CPU缓存是有限的,填充会牺牲掉一部分缓存;