zoukankan html css js c++ java

CPU高速缓存

Code：
物理结构：
缓存行Cache Line
伪共享：
- 概念：
- 解决办法：
内存屏障：
理解：
参考：

Code：

public class Main { 
    static long[][] arr; 
 
    public static void main(String[] args) { 
        arr = new long[1024 * 1024][8]; 
        // 横向遍历 
        long marked = System.currentTimeMillis(); 
        for (int i = 0; i < 1024 * 1024; i += 1) { 
            for (int j = 0; j < 8; j++) { 
                sum += arr[i][j]; 
            } 
        } 
        System.out.println("Loop times:" + (System.currentTimeMillis() - marked) + "ms"); 
 
        marked = System.currentTimeMillis(); 
        // 纵向遍历 
        for (int i = 0; i < 8; i += 1) { 
            for (int j = 0; j < 1024 * 1024; j++) { 
                sum += arr[j][i]; 
            } 
        } 
        System.out.println("Loop times:" + (System.currentTimeMillis() - marked) + "ms"); 
    } 
}

会发现横向遍历时间远远小于纵向遍历

物理结构：

二代i5处理器：

CacheLine size：64 Byte //缓存行
L1 Data Cache：32KB //L1数据缓存
L1 Instruction Cache：32KB //L1指令缓存
L2 Cache：256KB
L3 Cache：4MB

Martin和Mike的QCon演讲演讲中给出了一些缓存未命中的消耗数据，也就是从CPU访问不同层数数据的时间概念：

从CPU到	大约需要的CPU时钟周期	大约需要的时间
主存	约60-80ns
QPI总线传输（套接字之间，未绘制）	约20ns的
L3缓存	约40-45周期	约15ns的
L2缓存	约10个周期	约3ns的
L1缓存	约3-4个周期	约1ns的
寄存器	1个周期

CPU <--- > 寄存器<--- > 缓存<--- >内存

可见CPU读取主存中的数据会比从L1中读取慢了近2个数量级。

L3是每个处理器里面核心共享的，处理器之间不共享

主存是多个处理器共享的

缓存行Cache Line

缓存行(Cache Line) 便是CPU Cache 中的最小单位，CPU Cache 由若干缓存行组成，一个缓存行的大小通常是64 字节(这取决于CPU)，并且它有效地引用主内存中的一块地址。一个Java 的long 类型是8 字节，因此在一个缓存行中可以存8 个long 类型的变量。

试想一下你正在遍历一个长度为16 的long 数组data[16]，每一个long类型为8字节，原始数据自然存在于主内存中，访问过程描述如下

访问data[0]，CPU core 尝试访问CPU Cache，未命中。
尝试访问主内存，操作系统一次访问的单位是一个Cache Line 的大小— 64 字节，这意味着：既从主内存中获取到了data[0] 的值，同时将data[0] ~ data[7 ] 加入到了CPU Cache 之中，for free~
访问data[1]~data[7]，CPU core 尝试访问CPU Cache，命中直接返回。
访问data[8]，CPU core 尝试访问CPU Cache，未命中。
尝试访问主内存。重复步骤 2

CPU 缓存在顺序访问连续内存数据时挥发出了最大的优势

伪共享：

概念：

通常提到缓存行，大多数文章都会提到伪共享问题(正如提到CAS 便会提到ABA 问题一般)。

伪共享指的是多个线程同时读写同一个缓存行的不同变量时导致的CPU 缓存失效。尽管这些变量之间没有任何关系，但由于在主内存中邻近，存在于同一个缓存行之中，它们的相互覆盖会导致频繁的缓存未命中，引发性能下降。伪共享问题难以被定位，如果系统设计者不理解CPU 缓存架构，甚至永远无法发现— 原来我的进程还可以更快。

果多个线程的变量共享了同一个CacheLine，任意一方的修改操作都会使得整个CacheLine 失效(因为CacheLine 是CPU 缓存的最小单位)，也就意味着，频繁的多线程操作， CPU 缓存将会彻底失效，降级为CPU core 和主内存的直接交互

解决办法：

处理伪共享的两种方式：

字节填充：增大元素的间隔，使得不同线程访问的元素位于不同的缓存线上，典型的空间换时间。
在每个线程中创建对应元素的本地拷贝，结束后再写回全局数组，相当于线程各自操作自己的数据

字节填充：

Java8中：

@Retention(RetentionPolicy.RUNTIME) 
@Target({ElementType.FIELD, ElementType.TYPE}) 
public @interface Contended { 
    String value() default ""; 
}

Java8 中提供了字节填充的官方实现，这使得CPU Cache 更加可控了，无需担心jdk 的无效字段优化，无需担心Cache Line 在不同CPU 下的大小究竟是不是64 字节。使用@Contended 注解可以完美的避免伪共享问题。

但是这个功能暂时还是实验性功能，暂时还没到默认普及给用户代码用的程度。要在用户代码（非引导类加载器或扩展类加载器所加载的类）中使用@Contended注解的话，需要使用 - XX：-RestrictContended参数。

比如在JDK 8的ConcurrentHashMap源码中，使用 [@sun.misc.Contended]对静态内部类CounterCell进行了修饰。

/* ---------------- Counter support -------------- */

/**
 * 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; }
}

Thread中：

/** The current seed for a ThreadLocalRandom */
@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;