伪共享(False Sharing)和缓存行(Cache Line)

转载：https://www.jianshu.com/p/a9b1d32403ea

https://www.toutiao.com/a6644375612146319886/

前言

在上篇介绍LongAdder的文章中，我们最后留下了一个问题，为什么Cell中要插入很多个实际上并没有使用的Long变量？这个问题就得从False Sharing和Cache line开始说起。首先我们得知道Cache line是啥，推荐两篇文章:文章1和文章2。

科普False Sharing

在有了Cache line基础之后，让我们看看一篇介绍False Sharing的文章，这篇文章介绍了False Sharing以及简单说明了java8搞出的@Contented，翻译如下：

——————————————翻译start———————————————
java 8中引入了一个新注解 @Contented,主要是用来减少“False sharing”，这篇文章主要讲述了@Contented，解释了"False sharing"如何成为了性能杀手。

"Cache Line"简介

CPU不是按单个bytes来读取内存数据的，而是以“块数据”的形式，每块的大小通常为64bytes，这些“块”被成为“Cache Line”（这种说法其实很不太正确，关于Cache Line的知识请参考文末的参考链接）

如果有两个线程（Thread1 和 Thread2）同时修改一个volatile数据，把这个数据记为'x':

volatile long x;

如果线程1打算更改x的值，而线程2准备读取：

Thread1：x=3;
Thread2: System.out.println(x);

由于x值被更新了，所以x值需要在线程1和线程2之间传递（从线程1到线程2），x的变更会引起整块64bytes被交换，因为cpu核之间以cache lines的形式交换数据(cache lines的大小一般为64bytes)。有可能线程1和线程2在同一个核心里处理，但是在这个简单的例子中我们假设每个线程在不同的核中被处理。

我们知道long values的内存长度为8bytes，在我们例子中"Cache Line"为64bytes，所以一个cache line可以存储8个long型变量，在cache line中已经存储了一个long型变量x，我们假设cache line中剩余的空间用来存储了7个long型变量，例如从v1到v7
x,v1,v2,v3,v4,v5,v6,v7

False Sharing

一个cache lien可以被多个不同的线程所使用。如果有其他线程修改了v2的值，线程1和线程2将会强制重新加载cache line。你可以会疑惑我们只是修改了v2的值不应该会影响其他变量，为啥线程1和线程2需要重新加载cache line呢。然后，即使对于多个线程来说这些更新操作是逻辑独立的，但是一致性的保持是以cache line为基础的，而不是以单个独立的元素。这种明显没有必要的共享数据的方式被称作“False sharing”.

相应危害

这里假设有value1与value2共存在同一缓存行（这里前提是volatile修饰的变量）。A，B线程分别修改value1，value2的值。当A线程修改value1之后，会导致整个缓存行失效，然后B线程想修改value2的值的时候就会导致无法命中缓存，然后就会从L3甚至是从主内存中去重新加载value2的值。这一会使程序运行的效率大大降低。

这里还得再强调一遍，如果不是volatile修饰的变量，缓存行应该是不会立即失效的，也就是还会读到脏数据。因为CPU保证一个缓存行失效并得到确认失效的返回通知相对于CPU来说也是一个很耗时的操作，会白白浪费执行权。所以这里有个Invalidate Queues的知识点，CPU会将失效指令写入到Invalidate Queues中，然后由用户自行决定什么时候执行Invalidate Queues中的指令。

无效的消息会进入到一个无效队列中，但不会立即被处理，因此导致实际上CPU是无法知晓该缓存行是失效了的，CPU也无法主动去扫描这个无效队列，需要内存屏障来帮助我们去flush失效队列。

变量申明为volatile后便会在读取前有一个read barrier，写入后有个store barrier，这样可以使Store Buffer 与 Invalidate Queues中的指令都会被刷新。这样可以保证所有的写都能同步的被应用，缓存行的失效也会被同步，只不过这里会导致一些性能上的损耗，但是和正确的进行高并发比起来，这点损耗也是能够接受的。

Padding

为了获取一个cache line，核心需要执行几百个指令。

如果核心需要等待一个cache line重新加载，核心将会停止做其他事情，这种现象被称为"Stall".Stalls可以通过减少“False Sharing”,一个减少"false sharing"的技巧是填充数据结构，使得线程操作的变量落入到不同的cache line中。

下面是一个填充了的数据结构的例子，尝试着把x和v1放入到不同的cache line中

public class FalseSharingWithPadding { 

    public volatile long x;

    public volatile long p2;   // padding

    public volatile long p3;   // padding

    public volatile long p4;   // padding

    public volatile long p5;   // padding

    public volatile long p6;   // padding

    public volatile long p7;   // padding

    public volatile long p8;   // padding

    public volatile long v1;

}

在你准备填充你的所有数据结构之前，你必须了解jvm会减少或者重排序没有使用的字段，因此可能会重新引入“false sharing”。因此对象会在堆中的位置是没有办法保证的。

为了减少未使用的填充字段被优化掉的机会，将这些字段设置成为volatile会很有帮助。对于填充的建议是你只需要在高度竞争的并发类上使用填充，并且在你的目标架构上测试使用有很大提升之后采用填充。最好的方式是做10000玄幻迭代，消除JVM的实时优化的影响。

java8 和 @Contended

比起引入填充字段，一个更加简单有效的方式是在你需要避免“false sharing”的字段上标记注解，这可以暗示虚拟机“这个字段可以分离到不同的cache line中”，这是JEP 142的目标。

JEP引入了 @Contended 注解。

public class Point {

    int x;

    @Contended

    int y;

}

以上代码使得x和y都在不同的cache line中。@Contended 使得y字段远离了对象头部分。

————————————————翻译end——————————————————

False Sharing在java6/7中

如何避免False Sharing在java 6 7 8 中有不同的实现方式，这篇文章对比了在6/7/8下面的实现。国内的多篇关于伪共享的文章基本都来源于Martin的两篇博客。
博客1和博客2，博客1主要介绍了什么是False Sharing以及怎么避免False Sharing（在java6的环境下），我在看完这篇文文章后使用他的testbench进行了测试，得到的结果是在java6环境下，使用6个long变量进行填充是不一定能完全避免false sharing，但是我使用了

public final static class VolatileLong {

        public volatile long q1, q2, q3, q4, q5, q6, q7;

        public volatile long value = 0L;

        public volatile long p1, p2, p3, p4, p5, p6, p7;

    }

这种方式得到的结果是完全能够避免false sharing，我以此邮件了作者Martin Thompson说明此问题，Martin Thompson很快回了邮件附上了博客2的链接问我是否看过博客2的内容，我读过之后发现博客2写的是在java7的环境下虚拟机层面会对没有使用的变量进行优化，所以会导致false sharing的问题，我觉得这是一个新的问题并不能解释我在java6环境下发生的现象。在java7环境下要使用填充的方式避免false sharing需要绕很多弯弯而且并不一定能够达到效果。所以我觉得我们不能通过这种“黑科技”解决false sharing的问题，包括Martin Thompson的很多人都希望jvm的开发团队能够搞出一套机制能够支持在上层决定多个字段是否可以出现在同一个cache line，所以应大家的响应，在java8中，jvm团队搞出了@Contended注解来进行支持

java8中的@Contended

关于@Contended的用法，我们可以参考一个链接，这是jvm团队内部关于JEP-142实现的一个邮件回复，虽然可能和具体实现有所差别，但是参考价值很大。所以LongAdder在java8中的实现已经采用了@Contended

总结

这是一个关于false sharing的参考文档的大杂烩，没啥自己的理解。我的建议就是要避免false sharing就在java8环境下使用@Contended。下篇终于要介绍HystrixRollingNumber了。