查看原文
其他

填之前的坑,伪共享

是yes呀 yes的练级攻略 2023-01-02

大家好,我是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 上看了看,大佬将其废弃的理由如下:

简单直白的翻译下:

  1. 我看不出填充有什么切实的好处。
  2. 唯一保护的对象可能是 BitSet,但是它的修改并不频繁
  3. 填充用了 long,这并不一定会阻止 JVM 在对齐间隙中匹配上述的对象引用。

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

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

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

用代码跑跑看

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

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

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

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

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

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

我们跑一下看下结果:

果然,也提高了效率!

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

还有 Striped64 里的 Cell

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

最后

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

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

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

好了,今天就到这了。


我是yes,从一点点到亿点点,我们下篇见!



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存