并发场景下的底层细节伪同享问题

发布时间：2022-02-17 12:17:40 所属栏目：系统来源：互联网

导读：最近看书看到的伪共享问题，直接触碰到知识盲区了，之前确实没听说过这个东西，打开百度就像吃饭一样自然。虽然面经上出现的次数不多，不过我觉得还是很重要的一个问题，而且不难，花个五分钟就能弄清楚~ 老规矩，背诵版在文末。点击阅读原文可以直达我收

最近看书看到的伪共享问题，直接触碰到知识盲区了，之前确实没听说过这个东西，打开百度就像吃饭一样自然。

虽然面经上出现的次数不多，不过我觉得还是很重要的一个问题，而且不难，花个五分钟就能弄清楚~

老规矩，背诵版在文末。点击阅读原文可以直达我收录整理的各大厂面试真题

越靠近 CPU 的缓存，速度越快，容量也越小。所以 L1 缓存容量最小但是速度最快;L3 缓存容量最大同时速度也最慢

当 CPU 执行运算的时候，它会先去 L1 缓存查找所需的数据、如果没有找到的话就再去 L2 缓存、然后是 L3 缓存，如果最后这三级缓存中都没有命中，那么 CPU 就要去访问内存了。

显然，CPU 走得越远，运算耗费的时间就越长。所以尽量确保数据存在 L1 缓存中能够提升大计算量情况下的运行速度。

需要注意的是，CPU 和三级缓存以及内存的对应使用关系：

L1 和 L2 都是只能被一个单独的 CPU 核心使用
L3 可以被单个插槽上的所有 CPU 核心共享
内存由全部插槽上的所有 CPU 核心共享

缓存中的基本存储单元就是 Cache Line。

每个 Cache Line 通常是 64 字节，也就是说，一个 Java 的 long 类型变量是 8 字节，一个 Cache Line 中可以存 8 个 long 类型的变量。

所以小伙伴们看出来了吗~ 缓存中的数据并不是按照一个一个单独的变量这样存储组织起来的，而是多个变量会放到一行中。

在程序运行的过程中，由于缓存的基本单元 Cache Line 是 64 字节，所以缓存每次更新都会从内存中加载连续的 64 个字节。

如果访问的是一个 long 类型数组的话，当数组中的一个值比如 v1 被加载到缓存中时，接下来地址相邻的 7 个元素也会被加载到缓存中。(这也能解释为啥我们数组总是能够这么快，像链表这种离散存储的数据结构，就无法享受到这种红利)。

But，这波红利很可能带来无妄之灾。

举个例子，如果我们定义了两个 long 类型的变量 a 和 b，他们在内存中的地址是紧挨着的，会出现什么问题?

如果我们想要访问 a 的话，那么 b 也会被存储到缓存中来。

懵了懵了，这有什么问题吗，看起来似乎没有什么毛病，多么 nice 的特性啊

来来来，直接上个例子

回想下上文提到的 CPU 和三级缓存以及内存的对应使用关系，设想这种情况，如果一个 CPU 核心的线程 T1 在对 a 进行修改，另一个 CPU 核心的线程 T2 却在对 b 进行读取。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

并发场景下的底层细节 伪同享问题

并发场景下的底层细节伪同享问题