volatile 关键字与 CPU cache line 的效率问题-编程知识

volatile 关键字与 CPU cache line 的效率问题

分析&回答

Cache Line可以简单的理解为CPU Cache中的最小缓存单位。目前主流的CPU Cache的Cache Line大小都是64Bytes。假设我们有一个512字节的一级缓存，那么按照64B的缓存单位大小来算，这个一级缓存所能存放的缓存个数就是512/64 = 8个。具体参见下图：

代码示例：

public class CacheLine {private static class T {public volatile long x = 0L;//long类型占据8个字节}public static T[]  arr = new T[2];static {arr[0] = new T();arr[1] = new T();//两个数组紧挨着保证在内存中也是挨在一起的}public static void main(String[] args) throws Exception{Thread t1 = new Thread(() -> {for (long i = 0; i<10000000L; i++) {arr[0].x = i;//修改一千万次}});Thread t2 = new Thread(() -> {for (long i = 0; i<10000000L; i++) {arr[1].x = i;//修改一千万次}});final long start = System.currentTimeMillis();t1.start();t2.start();t1.join();//让t1线程先执行完t2.join();//让t2线程执行完System.out.println(System.currentTimeMillis() - start);//join 保证主线程的这段代码最后执行}
}
复制代码

执行结果为 300ms左右
上面代码中 arr[0] 和 arr[1]会在同一个cache line中，而每个cache line 是cpu 读入的最基本单位，在我们使用vaolatile 之后线程t1对x的1000000万次修改都要刷新内存通知t2，而同样t2对x的修改也要告诉t1。这样就会存在频繁的cache line 和内存的刷新读取。
如果我们将对x的修饰的valitile去掉执行结果为10ms左右\

使用缓存行对其的方式代码示例：

public class CacheLine {private static class parent {public volatile long p1,p2,p3,p4,p5,p6,p7;//创建七个long 基本数据类型的成员变量占据56个字节}private static class T extends parent{public volatile  long x = 0L;//long类型占据8个字节}public static T[]  arr = new T[2];static {arr[0] = new T();arr[1] = new T();//两个数组紧挨着保证在内存中也是挨在一起的}public static void main(String[] args) throws Exception{Thread t1 = new Thread(() -> {for (long i = 0; i<10000000L; i++) {arr[0].x = i;//修改一千万次}});Thread t2 = new Thread(() -> {for (long i = 0; i<10000000L; i++) {arr[1].x = i;//修改一千万次}});final long start = System.currentTimeMillis();t1.start();t2.start();t1.join();//让t1线程先执行完t2.join();//让t2线程执行完System.out.println(System.currentTimeMillis() - start);//join 保证主线程的这段代码最后执行}
}
复制代码

执行结果为 100ms左右
现成t1一次读入x 包括p1p2p3p4p5p6p7的所有变量64个字节刚好占据一个缓存行，线程t2 也是如此，所以他们对变量x的修改都不用刷新内存通知对方提高了性能。
为什么这里不包括对象头的那部分呢，因为对相头不是使用的部分，不会读入缓存，我们用到的只是成员变量
总结为cpu对于内存的读入到缓存的数据是按照缓存行的大小（64k）来读取的。

反思&扩展

cache 是为了进一步提升计算机性能引入的存储结构，cache和内存的最小的传输单位是cache line，因为每个物理core有自己独享的L1、L2 cache，并且一个cache line可能存在多个cache中，所以就出现了MESI协议保证cache line的一致性。进而又引入了cache line的伪共享的问题，为了进一步降低cache line伪共享所带来的的消耗，我们应该尽量避免多个线程同时修改的不同变量在同一个cache line中。虽然真实业务场景中，cache line的消耗占比可能会被弱化很多，但是追求极致的程序猿们，又怎么能放过这样一个无意义的消耗呢！