CPU Cache概述

随着CPU的频率不断提升，而内存的访问速度却没有质的突破，为了弥补访问内存的速度慢，充分发挥CPU的计算资源，提高CPU整体吞吐量，在CPU与内存之间引入了一级Cache。随着热点数据体积越来越大，一级Cache L1已经不满足发展的要求，引入了二级Cache L2，三级Cache L3。（注：若无特别说明，本文的Cache指CPU Cache，高速缓存）CPU Cache在存储器层次结构中的示意如下图：

计算机早已进入多核时代，软件也越来越多的支持多核运行。一个处理器对应一个物理插槽，多处理器间通过QPI总线相连。一个处理器包含多个核，一个处理器间的多核共享L3 Cache。一个核包含寄存器、L1 Cache、L2 Cache，下图是Intel Sandy Bridge CPU架构，一个典型的NUMA多处理器结构：

作为程序员，需要理解计算机存储器层次结构，它对应用程序的性能有巨大的影响。如果需要的程序是在CPU寄存器中的，指令执行时1个周期内就能访问到他们。如果在CPU Cache中，需要130个周期；如果在主存中，需要50200个周期；在磁盘上，大概需要几千万个周期。充分利用它的结构和机制，可以有效的提高程序的性能。

以我们常见的X86芯片为例，Cache的结构下图所示：整个Cache被分为S个组，每个组是又由E行个最小的存储单元——Cache Line所组成，而一个Cache Line中有B（B=64）个字节用来存储数据，即每个Cache Line能存储64个字节的数据，每个Cache Line又额外包含一个有效位(valid bit)、t个标记位(tag bit)，其中valid bit用来表示该缓存行是否有效；tag bit用来协助寻址，唯一标识存储在CacheLine中的块；而Cache Line里的64个字节其实是对应内存地址中的数据拷贝。根据Cache的结构题，我们可以推算出每一级Cache的大小为B×E×S。

Cache Line伪共享分析

说伪共享前，先看看Cache Line 在java编程中使用的场景。如果CPU访问的内存数据不在Cache中（一级、二级、三级），这就产生了Cache Line miss问题，此时CPU不得不发出新的加载指令，从内存中获取数据。通过前面对Cache存储层次的理解，我们知道一旦CPU要从内存中访问数据就会产生一个较大的时延，程序性能显著降低，所谓远水救不了近火。为此我们不得不提高Cache命中率，也就是充分发挥局部性原理。

局部性包括时间局部性、空间局部性。时间局部性：对于同一数据可能被多次使用，自第一次加载到Cache Line后，后面的访问就可以多次从Cache Line中命中，从而提高读取速度（而不是从下层缓存读取）。空间局部性：一个Cache Line有64字节块，我们可以充分利用一次加载64字节的空间，把程序后续会访问的数据，一次性全部加载进来，从而提高Cache Line命中率（而不是重新去寻址读取）。

看个例子：内存地址是连续的数组（利用空间局部性），能一次被L1缓存加载完成。

如下代码，长度为16的row和column数组，在Cache Line 64字节数据块上内存地址是连续的，能被一次加载到Cache Line中，所以在访问数组时，Cache Line命中率高，性能发挥到极致。

public int run(int[] row, int[] column) {    int sum = 0;    for(int i = 0; i < 16; i++ ) {        sum += row[i] * column[i];    }    return sum;}

而上面例子中变量i则体现了时间局部性，i作为计数器被频繁操作，一直存放在寄存器中，每次从寄存器访问，而不是从主存甚至磁盘访问。虽然连续紧凑的内存分配带来高性能，但并不代表它一直都能带来高性能。如果把它放在多线程中将会发生什么呢？如图：

数据X、Y、Z被加载到同一Cache Line中，线程A在Core1修改X，线程B在Core2上修改Y。根据MESI大法，假设是Core1是第一个发起操作的CPU核，Core1上的L1 Cache Line由S（共享）状态变成M（修改，脏数据）状态，然后告知其他的CPU核，图例则是Core2，引用同一地址的Cache Line已经无效了；当Core2发起写操作时，首先导致Core1将X写回主存，Cache Line状态由M变为I（无效），而后才是Core2从主存重新读取该地址内容，Cache Line状态由I变成E（独占），最后进行修改Y操作， Cache Line从E变成M。可见多个线程操作在同一Cache Line上的不同数据，相互竞争同一Cache Line，导致线程彼此牵制影响，变成了串行程序，降低了并发性。此时我们则需要将共享在多线程间的数据进行隔离，使他们不在同一个Cache Line上，从而提升多线程的性能。

 

Cache Line伪共享处理方案

处理伪共享的两种方式：

1. 增大数组元素的间隔使得不同线程存取的元素位于不同的cache line上。典型的空间换时间。（Linux cache机制与之相关）
2. 在每个线程中创建全局数组各个元素的本地拷贝，然后结束后再写回全局数组。

在Java类中，最优化的设计是考虑清楚哪些变量是不变的，哪些是经常变化的，哪些变化是完全相互独立的，哪些属性一起变化。举个例子：

 

public class Data{    long modifyTime;    boolean flag;    long createTime;    char key;    int value;}

假如业务场景中，上述的类满足以下几个特点：

1. 当value变量改变时，modifyTime肯定会改变
2. createTime变量和key变量在创建后，就不会再变化。
3. flag也经常会变化，不过与modifyTime和value变量毫无关联。

当上面的对象需要由多个线程同时的访问时，从Cache角度来说，就会有一些有趣的问题。当我们没有加任何措施时，Data对象所有的变量极有可能被加载在L1缓存的一行Cache Line中。在高并发访问下，会出现这种问题：

如上图所示，每次value变更时，根据MESI协议，对象其他CPU上相关的Cache Line全部被设置为失效。其他的处理器想要访问未变化的数据(key 和 createTime)时，必须从内存中重新拉取数据，增大了数据访问的开销。

JAVA处理方式

Padding 方式

正确的方式应该将该对象属性分组，将一起变化的放在一组，与其他属性无关的属性放到一组，将不变的属性放到一组。这样当每次对象变化时，不会带动所有的属性重新加载缓存，提升了读取效率。在JDK1.8以前，我们一般是在属性间增加长整型变量来分隔每一组属性。被操作的每一组属性占的字节数加上前后填充属性所占的字节数，不小于一个cache line的字节数就可以达到要求：

public class DataPadding{    long a1,a2,a3,a4,a5,a6,a7,a8;//防止与前一个对象产生伪共享    int value;    long modifyTime;    long b1,b2,b3,b4,b5,b6,b7,b8;//防止不相关变量伪共享;    boolean flag;    long c1,c2,c3,c4,c5,c6,c7,c8;//    long createTime;    char key;    long d1,d2,d3,d4,d5,d6,d7,d8;//防止与下一个对象产生伪共享}

通过填充变量，使不相关的变量分开

Contended注解方式

在JDK1.8中，新增了一种注解@sun.misc.Contended，来使各个变量在Cache line中分隔开。注意，jvm需要添加参数-XX:-RestrictContended才能开启此功能
用时，可以在类前或属性前加上此注释：

 

// 类前加上代表整个类的每个变量都会在单独的cache line中@sun.misc.Contended@SuppressWarnings("restriction")
public class ContendedData {int value;long modifyTime;boolean flag;long createTime;char key;
}
或者这种：
// 属性前加上时需要加上组标签@SuppressWarnings("restriction")
public class ContendedGroupData {@sun.misc.Contended("group1") int value;@sun.misc.Contended("group1") long modifyTime;@sun.misc.Contended("group2") boolean flag;@sun.misc.Contended("group3") long createTime;@sun.misc.Contended("group3") char key;
}

采取上述措施图示：

JDK1.8 ConcurrentHashMap的处理

java.util.concurrent.ConcurrentHashMap在这个如雷贯耳的Map中，有一个很基本的操作问题，在并发条件下进行++操作。因为++这个操作并不是原子的，而且在连续的Atomic中，很容易产生伪共享（false sharing）。所以在其内部有专门的数据结构来保存long型的数据:

  /*** A padded cell for distributing counts.  Adapted from LongAdder* and Striped64.  See their internal docs for explanation.*/@sun.misc.Contended static final class CounterCell {volatile long value;CounterCell(long x) { value = x; }}

我们看到该类中，是通过@sun.misc.Contended达到防止false sharing的目的

JDK1.8 Thread 的处理

java.lang.Thread在java中，生成随机数是和线程有着关联。而且在很多情况下，多线程下产生随机数的操作是很常见的，JDK为了确保产生随机数的操作不会产生false sharing ,把产生随机数的三个相关值设为独占cache line。

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