「计算机原理」| CPU 缓存 & 缓存一致性 & 伪共享

简介: 「计算机原理」| CPU 缓存 & 缓存一致性 & 伪共享

前言


  • CPU 缓存是计算机组成原理中比较基础,同时也是比较常用的知识,面试中也可能会有一定延伸;
  • 在这篇文章里,我将总结CPU 缓存 & 缓存一致性 & 伪共享 等问题。如果能帮上忙,请务必点赞加关注,这真的对我非常重要。


目录

image.png



1. CPU 三级缓存


  • 背景: CPU 处理器的运算速度与内存存取速度、磁盘 I/O 速度不匹配(相差了几个数量级);
  • 目的: 提高 CPU 吞吐量;
  • 方案: 增加一个缓存层来协调两者的速度差,即:在 CPU 和内存中间增加一层 「高速缓存」,缓存的存取速度尽可能接近。


数据加载的流程如下:


  • 1、将程序和数据从磁盘加载到内存中;
  • 2、将程序和数据从内存加载到缓存中(三级缓存,数据加载顺序:L3->L2->L1);
  • 3、CPU将缓存中的数据加载到寄存器中(L0),并进行运算;
  • 4、CPU将数据同步回缓存,并在一定的时间周期之后同步回内存。


经验表明,CPU 往往需要重复读取同一个数据块,而缓存容量的增大,可以大幅度提升 CPU 内部读取数据的命中率,以此提升 CPU 吞吐量。但是出于 CPU 芯片体积和价格因素来考虑,缓存都不会很大。现代 CPU 芯片使用的是三级的高速缓存:

image.png

—— 图片引用自网络


最开始是寄存器(也称为 L0 缓存),接下来是 L1,L2,L3 三级缓存,最后是内存,本地磁盘,远程存储。从上到下空间越大,速度越慢,但是成本越低。需要注意的是:在现代 CPU 里,L0、L1、L2、L3 都集成在一颗 CPU 内部,其中 L0、L1、L2 是每个处理核心独立的,而 L3 是一颗 CPU 的多个处理器共用的。


image.png

—— 图片引用自网络


2. 缓存一致性问题


现代 CPU 通常有多个核心,每个核心也都有自己独立的缓存(L1、L2 缓存),当多个核心同时操作同一个数据时,如果核心 2 在核心 1 还未将更新的数据同步回内存之前读取了数据,就出现了缓存不一致问题。


举个例子,假设线程 A 和线程 B 同时对一个变量执行 i++,就可能存在缓存不一致问题:


  • 1、核心 A 和核心 B 从内存中加载了 i 的值,并且缓存到各自的高速缓存中,此时两个副本都为0;
  • 2、核心 A 进行加一操作,副本值变成了 1,最后回写到主存中,主存中的值为 1;
  • 3、核心 B 进行加一操作,副本值变成了 1,最后回写到主存中,主存中的值为 1;
  • 4、最终主存的值为 1,而不是期望的 2。

为了解决缓存不一致性问题,通常来说有两种解决方法:


  • 1、锁总线

早期的 CPU 是通过在锁总线来解决缓存不一致的问题。锁总线是对整个内存加锁,在锁总线期间,其他处理器无法访问内存,可想而知会严重降低 CPU 性能。


  • 2、缓存一致性协议(MESI)


缓存一致性协议提供了一种高效的内存数据管理方案。「锁内存方案」相当于保证了整块内存的一致性,而「缓存一致性协议方案」本质上相当与一致性保护范围,从整块内存缩小为单个缓存行(缓存行是缓存的基本单元)。


简单来说:当 CPU 核心准备写数据时,如果发现操作的变量是共享变量(即在其他核心中也存在该变量的副本),就会通知其他核心该变量「缓存行」无效,需要重新从内存读取。


具体来说,MESI 协议会将缓存数据定义为四种状态:


状态 描述
E(Exclusive) 独享 / 互斥
S(Shared) 共享
M(Modify) 修改
I(Invalid) 无效


详细工作原理:


  • 1、核心 A 从内存中加载变量 i,并将缓存行设置为 E(独享),随后通过总线嗅探检查内存中对变量 i 的操作;
  • 2、核心 B 从内存中加载变量 i,总线嗅探机制会将核心 A 与核心 B 的缓存行设置为 S(共享);
  • 3、核心 A 对变量 i 进行修改,缓存行设置为 M(修改),而核心 B 被通知修改缓存行为 I(无效)。如果存在高并发,则交给总线裁决;
  • 4、核心 A 将修改后数据同步回内存,并将变量设置为 E(独享);
  • 5、核心 B 重新刷新缓存行,并将缓存行核心 A 和核心 B 的缓存行设置为 S(共享)。


易混淆: MESI 协议是 CPU 的协议,JMM 也有自己的协议来保证缓存一致性。


3. 伪共享(False Sharing)


在 CPU 缓存中,缓存管理的基本单位并不是「字节」,而是「缓存行(Cache Line)」。缓存行的大小取决于 CPU,一般是 64 字节。


缓存行的设计源于:“CPU 读取一个数据之后,往往还需要重复读取附近的数据”。使用缓存行一次将一小块数据加载进高速缓存,有助于提高运算效率。

image.png


—— 图片引用自网络


当然,缓存也不是完美的,也存在副作用 —— 伪共享。伪共享是指多个线程同时读写同一个缓存行中的变量,而导致缓存行失效的问题。尽管两个线程分别访问的是不同的数据,但由于它们存在同一个缓存行中,只要任何一方修改都会使得缓存失效,降低了运算效率。


解决伪共享的方法是 「字节填充」,即通过在两个变量中间的内容填充额外的字节,使得两个变量存放在到不同缓存行中,从而规避伪共享问题。

在使用字节填充时,需要先考虑哪些变量是独立变化的,哪些变量是协同变化的。协同变化的变量放在一组,而无关的变量分到不同组。这样当修改变量时,不会导致无关变量的缓存行无效。


在 Java 中,Java 8 前后的处理方式不同:

  • Java 8 之前:通过填充 long 变量来分组


public class DataPadding{
    long a1,a2,a3,a4,a5,a6,a7; 防止与前一个对象产生伪共享
    int value1;
    long value2;
    long b1,b2,b3,b4,b5,b6,b7; 防止两组变量伪共享;
    boolean flag;
    long d1,d2,d3,d4,d5,d6,d7; 防止与下一个对象产生伪共享
}
复制代码
  • Java 8:通过 @sun.misc.Contended 分组


@Contended 注解是 JDK 1.8 新增的注解,用于将变量划分到不同的缓存行。

例如:Java 8 Thread.java


/** The current seed for a ThreadLocalRandom */
@sun.misc.Contended("tlr")
long threadLocalRandomSeed;
/** Probe hash value; nonzero if threadLocalRandomSeed initialized */
@sun.misc.Contended("tlr")
int threadLocalRandomProbe;
/** Secondary seed isolated from public ThreadLocalRandom sequence */
@sun.misc.Contended("tlr")
int threadLocalRandomSecondarySeed;
复制代码


Java 8 ConcurrentHashMap.java


@sun.misc.Contended static final class CounterCell {
        volatile long value;
        CounterCell(long x) { value = x; }
    }
复制代码

提示: 需要 JVM 开启字节填充功能 -XX:-RestrictContended


4. 总结


  • 由于 CPU 处理器的运算速度与内存存取速度、磁盘 I/O 速度不匹配,所以 CPU 中会增加一层缓存来协调两者的速度差。CPU 缓存是一个三级结构,其中 L0、L1、L2 是每个处理核心独立的,而 L3 是一颗 CPU 的多个处理器共用的;
  • 由于 CPU 每个核心也都有自己独立的缓存(L1、L2 缓存),当多个核心同时操作同一个数据时,如果核心 2 在核心 1 还未将更新的数据同步回内存之前读取了数据,就出现了缓存不一致问题。解决方案有「锁总线」&「缓存一致性协议」;
  • 由于 “CPU 读取一个数据之后,往往还需要重复读取附近的数据”,所以 CPU 设计了缓存行(Cache Line)作为基本单位。当然,缓存页存在副作用 —— 伪共享,即:当多个线程同时读写同一个缓存行中的变量,而导致缓存行失效的问题。解决方案是「字节填充」,使得两个变量存放在到不同缓存行中。Java 8 之前采用填充 long 变量,而 Java 8 之后采用 @sun.misc.Contended 注解。
目录
相关文章
|
4天前
|
缓存 NoSQL Java
面试官:如何保证本地缓存的一致性?
面试官:如何保证本地缓存的一致性?
235 1
|
4天前
|
缓存 算法 NoSQL
【分布式详解】一致性算法、全局唯一ID、分布式锁、分布式事务、 分布式缓存、分布式任务、分布式会话
分布式系统通过副本控制协议,使得从系统外部读取系统内部各个副本的数据在一定的约束条件下相同,称之为副本一致性(consistency)。副本一致性是针对分布式系统而言的,不是针对某一个副本而言。强一致性(strong consistency):任何时刻任何用户或节点都可以读到最近一次成功更新的副本数据。强一致性是程度最高的一致性要求,也是实践中最难以实现的一致性。单调一致性(monotonic consistency):任何时刻,任何用户一旦读到某个数据在某次更新后的值,这个用户不会再读到比这个值更旧的值。
429 0
|
4天前
|
canal 缓存 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-03 Refresh Ahead + SingleFlight + 删除缓存 + 延迟双删
【5月更文挑战第11天】Refresh Ahead模式通过CDC异步刷新缓存,但面临缓存一致性问题,可借鉴Write Back策略解决。SingleFlight限制并发加载,减少数据库压力,适合热点数据。删除缓存模式在更新数据库后删除缓存,一致性问题源于读写线程冲突。延迟双删模式两次删除,理论上减少不一致,但可能降低缓存命中率。选用模式需权衡优劣,延迟双删在低并发下较优。装饰器模式可用于实现多种缓存模式,无侵入地增强现有缓存系统。
22 2
|
4天前
|
缓存 数据库 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back
【5月更文挑战第10天】`Write Through`是一种缓存策略,写操作仅需写入缓存,缓存负责更新数据库。异步版本可能丢失数据,而同步变种先写数据库再异步刷新缓存,减少丢数据风险。`Write Back`模式数据先写入缓存,过期时才写入数据库,可能导致数据丢失,但若使用Redis并确保高可用,可部分解决一致性问题。在特定条件下,如使用SETNX命令,能缓解一致性挑战。
16 0
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back
|
4天前
|
消息中间件 缓存 中间件
中间件缓存一致性
【5月更文挑战第6天】中间件缓存一致性
15 1
中间件缓存一致性
|
4天前
|
存储 缓存 数据库
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?
【5月更文挑战第9天】面试准备中,熟悉缓存模式如Cache Aside、Read Through、Write Through、Write Back、Singleflight,以及删除缓存和延迟双删策略,能解决缓存一致性、穿透、击穿和雪崩问题。在自我介绍时展示对缓存模式的理解,例如Cache Aside模式,它是基础模式,读写由业务控制,先写数据库以保证数据准确性,但无法解决所有一致性问题。Read Through模式在缓存未命中时自动从数据库加载数据,可异步加载优化响应时间,但也存在一致性挑战。
16 0
|
4天前
|
缓存 NoSQL 关系型数据库
Redis 缓存 一致性
Redis 缓存 一致性
9 0
|
4天前
|
消息中间件 缓存 关系型数据库
数据库和缓存如何保证一致性?
数据库和缓存如何保证一致性?
|
4天前
|
存储 缓存
CPU缓存简介
CPU缓存简介
19 1
|
4天前
|
缓存 NoSQL Redis
深度解析Redis的缓存双写一致性
【4月更文挑战第20天】
44 1

相关实验场景

更多