伪共享(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了

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师之旅

JVM内存管理------JAVA语言的内存管理概述

引言 内存管理一直是Java语言自豪与骄傲的资本,它让JAVA程序员基本上可以彻底忽略与内存管理相关的细节,只专注于业务逻辑。不过世界上不存在十全十...

1947
来自专栏PHP实战技术

PHP经典面试题目汇总(上篇)

1、双引号和单引号的区别 双引号解释变量,单引号不解释变量 双引号里插入单引号,其中单引号里如果有变量的话,变量解释 双引号的变量名后面必须要有一个非数字、字母...

3497
来自专栏乐沙弥的世界

mongoDB简介及关键特性

761
来自专栏SDNLAB

SDNLAB技术分享(三):OpenDaylight中编程抽象的实现

这次主要分三部分说一下,首先我会粗略介绍一下maple system。 之后将以这个为例来阐述一下ODL模块的开发过程。 最后会说明一下ODL模块的结构。 目前...

36210
来自专栏owent

libcopp更新 (merge boost 1.59 context)

这个框架的上下文部分是使用了boost.context,但是从开始写libcopp到现在,boost.context也更新了几个版本。而之前几次merge基本都...

852
来自专栏FreeBuf

Java反序列化漏洞从理解到实践

一、前言 在学习新事物时,我们需要不断提醒自己一点:纸上得来终觉浅,绝知此事要躬行。这也是为什么我们在学到知识后要付诸实践的原因所在。在本文中,我们会深入分析大...

29510
来自专栏magicsoar

C++编译与链接(2)-浅谈内部链接与外部链接

发现每次写技术博客时,都会在文章开头处花费一番功夫 ...从前,有一个程序员....他的名字叫magicsoar 为什么有时会出现aaa已在bbb中重定义的错误...

2799
来自专栏同步博客

制作类似ThinkPHP框架中的PATHINFO模式功能(二)

  距离上一次发布的《制作类似ThinkPHP框架中的PATHINFO模式功能》(文章地址:http://www.cnblogs.com/phpstudy201...

775
来自专栏FreeBuf

渗透测试中利用基于时间差反馈的远程代码执行漏洞(Timed Based RCE)进行数据获取

在最近的渗透测试项目中,为了进一步验证漏洞的可用性和危害性,我们遇到了这样一种情形:构造基于时间差反馈的系统注入命令(OS command injection ...

2189
来自专栏编程

PHP7 下的协程实现

前言 相信大家都听说过『协程』这个概念吧。 但是有些同学对这个概念似懂非懂,不知道怎么实现,怎么用,用在哪,甚至有些人认为yield就是协程! 我始终相信,如果...

3368

扫码关注云+社区

领取腾讯云代金券