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

前言

在上篇介绍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”.

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了