填之前的坑,伪共享

开发 前端
我们都知道 CPU 的执行速度远大于从内存获取数据的速度,为了减少这个差距科研人员们就不断的研究,产出了高速缓存,但这个高速缓存由于工艺集成度问题,无法作为主存的介质。

[[435661]]

大家好,我是yes。

之前在写 FastThreadLocal 的时候,挖了个坑。

咳咳,时间过得有点久了,但是影响不大今天就来补上。

来谈谈什么是伪共享,并且为什么 Netty 要在这里移除这个优化?

话不多说,发车!

什么是伪共享?

这个名词听着有点高级的感觉,实际上很好理解。

我们都知道 CPU 的执行速度远大于从内存获取数据的速度,为了减少这个差距科研人员们就不断的研究,产出了高速缓存,但这个高速缓存由于工艺集成度问题,无法作为主存的介质,所以常见的 CPU 缓存结构如下图所示:

L1、L2、L3则为 CPU 和主存之间的高速缓冲区,距离 CPU 越近的缓存访问速度越快,且容量越小。

比如我笔记本的 CPU上:

访问速度:L1>L2>L3>主存。

L1 和 L2 是单核 CPU 独享的,当 CPU 访问数据的时候会先去 L1 上面找,找不到再去 L2,然后是 L3,最后是主存。所以当对一个数据重复计算的时候,应该尽量保证数据在 L1 中,这样效率才高。

从上面的结构来看,有经验的同学肯定会发现上面的结构有共享内存多线程的问题。这里就引入了一致性协议 MESI。具体协议内容这里不作展开,这里简单举例理解下:

当 cpu1 和 cpu3 共同访问主存里面的一个数据时,会分别获取放置到自己高速缓冲区中,当 cpu1 修改了这个数据之后,cpu3 的高速缓冲区中这个数据就失效了,它会让 cpu1 把这个改动刷新到主存中,然后自己再去主存加载这个数据,这样数据才会正确。

图中按序号顺序来阅读,应该不难理解。

然后重点来了,CPU 缓存的单位是缓存行,也就是说 CPU 从主存拿数据不是一个一个拿,是一行一行的拿,这一行的大小一般是 64 字节,那问题就来了。

比如,现在有个 long 数组,大小为 8 ,那刚好这个数组满足一行的大小。现在 cpu1 频繁更新long[0]的值,而 cpu3 频繁更新 long[5] 的值,这就有点麻了。

由于缓存行的机制,每次 cpu1 会把整个数组都加载到缓存中,每次仅修改 long[0] 也会使得这一行都变脏,此时 cpu3 访问的 long[5] 就失效了,因此 cpu3 需要让 cpu1 把修改刷新到主存中,然后它从主存重新获取 long[5] 再进行操作,假设此时 cpu1 又修改了 long[0],则上面的操作就又得来一遍!

明明修改的是不同的变量,但是却相互影响了,这种情况,就称之为,伪共享!

如何避免伪共享问题?

解决的方案非常简单粗暴,填充。

把可能会冲突的数据在内存上隔开来,用什么隔?用无用的数据隔开。

在关键数据前后(上图仅填充了后)填充无用的数据,让一个缓存行中,仅会存在一个有效的数据,其它都是无效的数据,就避免了一个缓存行里面出现多个有效的数据。这样一来不同的 CPU 核心修改不同的数据就不会造成其它数据缓存失效,避免了伪共享的问题。

所以 Netty 里 InternalThreadLocalMap 中奇怪的代码就是起这个作用的。 

但恕我直言,可能是我等级太低,我没看出来这玩意到底是为了哪个变量而填充的。

果然,最新的版本有个大佬把它标注为废弃。

我从 github 上看了看,大佬将其废弃的理由如下:

简单直白的翻译下:

我看不出填充有什么切实的好处。

唯一保护的对象可能是 BitSet,但是它的修改并不频繁

填充用了 long,这并不一定会阻止 JVM 在对齐间隙中匹配上述的对象引用。

简单来讲就是没发现这填充有啥好用,所以废弃了,将来版本要咔嚓了它。

所以拿 Netty 来展示伪共享的例子不行(我只是把之前写 FastThreadLocal 的坑填了)。

现在填完了,我们换个好的例子。

用代码跑跑看

我写了个例子,咱们来看看填充和不填充的真实差距。

我用两个线程分别循环五千万次修改一个对象里面的两个变量 a 和 b,这两个变量大概率会在同一个缓存行中,这样就制造了伪共享的现场。

在未填充的情况下,耗费的毫秒数是1400。

然后我们再用变量p1-p7填充一下,隔开 a 和 b。

可以看到,结果变成了380毫秒,这么一看,确实生效了!说明填充确实有效!

其实 Java 提供了一个注解 @Contended,可以标记到指定的字段上,减少伪共享的发生,你可以认为这个注解会让 JVM 自动帮我们填充,而不需要我们手写填充的变量。不过要注意一点,这个注解需要启动时添加-XX:-RestrictContended 参数,才会生效。

我们跑一下看下结果:

果然,也提高了效率!

这个注解其实在别的地方也有应用,比如 ConcurrentHashMap 里的 CounterCell

还有 Striped64 里的 Cell

不过要注意,没有-XX:-RestrictContended 不会生效的!

最后

至此,想必你已经明白了什么是伪共享,并且可以利用填充来避免伪共享的问题。

但填充就代表着空间的浪费,也不是什么情况下都需要填充。

只有在频繁更新相邻字段的情况下,才可能需要考虑伪共享的情况,别的情况不需要下操心。

好了,今天就到这了。

 

责任编辑:武晓燕 来源: yes的练级攻略
相关推荐

2015-04-03 09:38:32

程序员前人挖坑后人填坑

2020-10-29 10:22:44

中台

2019-12-17 14:24:11

CPU缓存伪共享

2017-07-13 16:40:16

伪共享缓存行存储

2022-12-12 08:39:09

CPUCache伪共享

2021-03-25 10:14:10

自动化运营人工智能AIOps

2021-03-31 08:33:17

SysTick定时器SysTick定时器

2023-06-12 07:00:40

Rust进度任务

2022-01-17 14:24:09

共享字节面试

2021-04-16 08:11:24

js前端JavaScript

2023-12-26 10:08:57

缓存伪共享修饰结构体

2017-03-02 13:32:36

Android开发开发者

2016-10-19 19:03:18

javascriptes6React Nativ

2022-02-02 21:50:25

底层伪共享CPU

2017-08-23 13:21:31

2018-02-27 16:01:24

2018-11-22 16:20:07

RedisMySQL数据库

2019-01-15 14:44:02

CPU Cache L共享存储器

2022-08-17 06:25:19

伪共享多线程

2017-05-05 08:12:51

Spark共享变量
点赞
收藏

51CTO技术栈公众号