CPU缓存一致性协议MESI

我会带着你远行 2022-09-14 09:43 177阅读 0赞

# **CPU****高速缓存（****Cache Memory****）**  #

## **CPU****为何要有高速缓存**  ##

CPU 在摩尔定律的指导下以每 18 个月翻一番的速度在发展，然而内存和硬盘的发展速度远远不及 CPU 。这 就造成了高性能能的内存和硬盘价格及其昂贵。然而CPU 的高度运算需要高速的数据。为了解决这个问 题， CPU 厂商在 CPU 中内置了少量的高速缓存以解决 I\\O 速度和 CPU 运算速度之间的不匹配问题。

在 CPU 访问存储设备时，无论是存取数据抑或存取指令，都趋于聚集在一片连续的区域中，这就被称为局 部性原理。

**时间局部性（** **Temporal Locality** **）** ：如果一个信息项正在被访问，那么在近期它很可能还会被再次访问。  比如循环、递归、方法的反复调用等。

**空间局部性（** **Spatial Locality** **）** ：如果一个存储器的位置被引用，那么将来他附近的位置也会被引用。  比如顺序执行的代码、连续创建的两个对象、数组等。

**带有高速缓存的** **CPU** **执行计算的流程**

1.  程序以及数据被加载到主内存

2.  指令和数据被加载到 CPU 的高速缓存

3. CPU 执行指令，把结果写到高速缓存

4.  高速缓存中的数据写回主内存

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16][]

**目前流行的多级缓存结构：**

由于 CPU 的运算速度超越了 1 级缓存的数据 I\\O 能力， CPU 厂商又引入了多级的缓存结构。

多级缓存结构

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

## **多核****CPU****多级缓存一致性协议****MESI**  ##

多核 CPU 的情况下有多个一级缓存，如何保证缓存内部数据的一致 , 不让系统数据混乱。这里就引出了一个一致性的协议MESI 。

**MESI** **协议缓存状态**

MESI  是指4中状态的首字母。 **缓存行（** **Cache line** **）** :缓存存储数据的单元。 每个 Cache line 有 4 个状态，可用 2 个 bit 表示，它们分别是：

<table style="width:500px;"> 
 <tbody> 
  <tr> 
   <td style="width:17px;"><span style="color:#000000;">状态</span></td> 
   <td style="width:178px;"><span style="color:#000000;">描述</span></td> 
   <td><span style="color:#000000;">监听任务</span></td> 
  </tr> 
  <tr> 
   <td style="width:17px;"> 
    <div> 
     <span style="color:#000000;">M 修改 (Modified) </span> 
    </div> </td> 
   <td style="width:178px;"> 
    <div> 
     <span style="color:#000000;">该Cache line有效数据被修改了，和内存中数</span> 
    </div> 
    <div> 
     <span style="color:#000000;">据不一致，数据只存在于本Cache中。 </span> 
    </div> </td> 
   <td> 
    <div> 
     <span style="color:#000000;">缓存行必须时刻监听所有试图读该缓存行相对就主存的操作，这种操作必须在缓存将该缓存行写回主存并将状态变成S（共享）。</span> 
    </div> </td> 
  </tr> 
  <tr> 
   <td style="width:17px;"> 
    <div> 
     <span style="color:#000000;">E 独享、互斥 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">(Exclusive)</span> 
    </div> </td> 
   <td style="width:178px;"> 
    <div> 
     <span style="color:#000000;">该Cache line有效，数据和内存中的数据一 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">致，数据只存在于本Cache中。</span> 
    </div> </td> 
   <td> 
    <div> 
     <span style="color:#000000;">缓存行也必须监听其它缓存读主存中该缓存行的操作，一旦有这种操作，该缓存行需要 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">变成S（共享）状态。</span> 
    </div> </td> 
  </tr> 
  <tr> 
   <td style="width:17px;"> 
    <div> 
     <span style="color:#000000;">S 共享 (Shared) </span> 
    </div> </td> 
   <td style="width:178px;"> 
    <div> 
     <span style="color:#000000;">该Cache line有效，数据和内存中的数据一 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">致，数据存在于很多Cache中。 </span> 
    </div> </td> 
   <td> 
    <div> 
     <span style="color:#000000;">缓存行也必须监听其它缓存使该缓存行无效或者独享该缓存行的请求，并将该缓存行变 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">成无效（</span> 
    </div> 
    <div> 
     <span style="color:#000000;">Invalid）。</span> 
    </div> </td> 
  </tr> 
  <tr> 
   <td style="width:17px;"> 
    <div> 
     <span style="color:#000000;">I 无效 (Invalid) </span> 
    </div> </td> 
   <td style="width:178px;"> 
    <div> 
     <span style="color:#000000;">该Cache line无效。</span> 
    </div> </td> 
   <td> 
    <div> 
     <span style="color:#000000;">无</span> 
    </div> </td> 
  </tr> 
 </tbody> 
</table>

**注意：**

**对于** **M** **和** **E** **状态而言总是精确的，他们在和该缓存行的真正状态是一致的，而** **S** **状态可能是非一致的** 。如果一个缓存将处于S 状态的缓存行作废了，而另一个缓存实际上可能已经独享了该缓存行，但是该缓存却不会将该缓存行升迁为E 状态，这是因为其它缓存不会广播他们作废掉该缓存行的通知，同样由于缓存并没有保存该缓存行的copy 的数量，因此（即使有这种通知）也没有办法确定自己是否已经独享了该缓存行。 从上面的意义看来E 状态是一种投机性的优化：如果一个 CPU 想修改一个处于 S 状态的缓存行，总线事务需要将所有该缓存行的copy 变成 invalid 状态，而修改 E 状态的缓存不需要使用总线事务。

## **MESI****状态转换**  ##

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

理解该图的前置说明：

1. 触发事件

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

2.cache分类：

前提：所有的 cache 共同缓存了主内存中的某一条数据。

本地 cache: 指当前 cpu 的 cache 。

触发 cache: 触发读写事件的 cache 。

其他 cache: 指既除了以上两种之外的 cache 。

注意：本地的事件触发 本地 cache 和触发 cache 为相同。

上图的切换解释：

<table style="width:590px;"> 
 <tbody> 
  <tr> 
   <td><span style="color:#000000;">状态</span></td> 
   <td><span style="color:#000000;">触发本地读取</span></td> 
   <td style="width:198px;"><span style="color:#000000;">触发本地写入</span></td> 
   <td style="width:204px;"><span style="color:#000000;">触发远端读取</span></td> 
  </tr> 
  <tr> 
   <td><span style="color:#000000;"><strong>M状态（修改）</strong></span></td> 
   <td> <p><span style="color:#000000;">本地cache:M</span></p> <p></p> 
    <div> 
     <span style="color:#000000;">触发cache:M </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:I</span> 
    </div> </td> 
   <td style="width:198px;"> <p><span style="color:#000000;">本地cache:M</span></p> <p></p> 
    <div> 
     <span style="color:#000000;">触发cache:M </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:I</span> 
    </div> </td> 
   <td style="width:204px;"> <p><span style="color:#000000;">本地cache:M→E→S</span></p> <p></p> 
    <div> 
     <span style="color:#000000;">触发cache:I→S </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:I→S</span> 
    </div> 
    <div> 
     <div> 
      <span style="color:#000000;">同步主内存后修改为E独享,同步触发、其他 </span> 
     </div> 
     <div> 
      <span style="color:#000000;">cache后本地、触发、其他cache修改为S共 </span> 
     </div> 
     <div> 
      <span style="color:#000000;">享</span> 
     </div> 
    </div> </td> 
  </tr> 
  <tr> 
   <td> 
    <div> 
     <span style="color:#000000;"><strong>E状态（独 </strong></span> 
    </div> 
    <div> 
     <span style="color:#000000;"><strong>享）</strong></span> 
    </div> </td> 
   <td> 
    <div> 
     <span style="color:#000000;">本地cache:E </span> 
    </div> 
    <div> 
     <span style="color:#000000;">触发cache:E </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:I </span> 
    </div> </td> 
   <td style="width:198px;"> 
    <div> 
     <span style="color:#000000;">本地cache:E→M </span> 
    </div> 
    <div> 
     <span style="color:#000000;">触发cache:E→M </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:I </span> 
    </div> 
    <div> 
     <span style="color:#000000;">本地cache变更为M,其 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">他cache状态应当是 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">I（无效） </span> 
    </div> </td> 
   <td style="width:204px;"> 
    <div> 
     <span style="color:#000000;">本地cache:E→S </span> 
    </div> 
    <div> 
     <span style="color:#000000;">触发cache:I→S </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:I→S </span> 
    </div> 
    <div> 
     <span style="color:#000000;">当其他cache要读取该数据时，其他、触 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">发、本地cache都被设置为S(共享) </span> 
    </div> </td> 
  </tr> 
  <tr> 
   <td> 
    <div> 
     <span style="color:#000000;"><strong>S状态(共享)</strong></span> 
    </div> </td> 
   <td> 
    <div> 
     <span style="color:#000000;">本地cache:S </span> 
    </div> 
    <div> 
     <span style="color:#000000;">触发cache:S </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:S </span> 
    </div> </td> 
   <td style="width:198px;"> 
    <div> 
     <span style="color:#000000;">本地cache:S→E→M </span> 
    </div> 
    <div> 
     <span style="color:#000000;">触发cache:S→E→M </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:S→I </span> 
    </div> 
    <div> 
     <span style="color:#000000;">当本地cache修改时，将 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">本地cache修改为E,其他 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">cache修改为I,然后再将 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">本地cache为M状态</span> 
    </div> </td> 
   <td style="width:204px;"> 
    <div> 
     <span style="color:#000000;">本地cache:S </span> 
    </div> 
    <div> 
     <span style="color:#000000;">触发cache:S </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:S </span> 
    </div> </td> 
  </tr> 
  <tr> 
   <td> 
    <div> 
     <span style="color:#000000;"><strong>I状态（无效）</strong></span> 
    </div> </td> 
   <td> 
    <div> 
     <span style="color:#000000;">本地cache:I→S或者I→E </span> 
    </div> 
    <div> 
     <span style="color:#000000;">触发cache:I→S或者I →E </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:E、M、 I→S、I </span> 
    </div> 
    <div> 
     <span style="color:#000000;">本地、触发</span> 
    </div> 
    <div> 
     <span style="color:#000000;">cache将从I无 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">效修改为S共享或者E独 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">享，其他cache将从E、 M、I 变为S或者I </span> 
    </div> </td> 
   <td style="width:198px;"> 
    <div> 
     <span style="color:#000000;">本地cache:I→S→E→M </span> 
    </div> 
    <div> 
     <span style="color:#000000;">触发</span> 
    </div> 
    <div> 
     <span style="color:#000000;">cache:I→S→E→M </span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache:M、E、 S→S→I </span> 
    </div> </td> 
   <td style="width:204px;"> 
    <div> 
     <span style="color:#000000;">既然是本cache是I，</span> 
    </div> 
    <div> 
     <span style="color:#000000;">其他cache操作与它无 </span> 
    </div> 
    <div> 
     <span style="color:#000000;">关 </span> 
    </div> </td> 
  </tr> 
  <tr> 
   <td></td> 
   <td></td> 
   <td style="width:198px;"></td> 
   <td style="width:204px;"></td> 
  </tr> 
 </tbody> 
</table>

下图示意了，当一个 cache line 的调整的状态的时候，另外一个 cache line  需要调整的状态。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_17_color_FFFFFF_t_70_g_se_x_16][]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 4][]

举个栗子来说：

假设 cache 1  中有一个变量 x = 0 的 cache line  处于 S 状态 ( 共享 ) 。

那么其他拥有 x 变量的 cache 2 、 cache 3 等 x 的 cache line 调整为 S 状态（共享）或者调整为  I  状态（无

效）。

**多核缓存协同操作**

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 5][]

假设有三个 CPU A 、 B 、 C ，对应三个缓存分别是 cache a 、 b 、  c 。在主内存中定义了 x 的引用值为 0 。

**单核读取**

那么执行流程是：

CPU A 发出了一条指令，从主内存中读取 x 。

从主内存通过 bus 读取到缓存中（远端读取 Remote read ） , 这是该 Cache line 修改为 E 状态（独享） .

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 6][]

**双核读取**

那么执行流程是：

CPU A 发出了一条指令，从主内存中读取 x 。

CPU A 从主内存通过 bus 读取到  cache a 中并将该 cache line  设置为 E 状态。

CPU B 发出了一条指令，从主内存中读取 x 。

CPU B 试图从主内存中读取 x 时， CPU A 检测到了地址冲突。这时 CPU A 对相关数据做出响应。此时 x  存储

于 cache a 和 cache b 中， x 在 chche a 和 cache b 中都被设置为 S 状态 ( 共享 ) 。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 7][]

**修改数据**

那么执行流程是：

CPU A  计算完成后发指令需要修改 x.

CPU A  将 x 设置为 M 状态（修改）并通知缓存了 x 的 CPU B, CPU B 将本地 cache b 中的 x 设置为 I 状态 ( 无

效 )

CPU A  对 x 进行赋值。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 8][]

**同步数据**

那么执行流程是：

CPU B  发出了要读取 x 的指令。

CPU B  通知 CPU A,CPU A 将修改后的数据同步到主内存时 cache a  修改为 E （独享）

CPU A 同步 CPU B 的 x, 将 cache a 和同步后 cache b 中的 x 设置为 S 状态（共享）。 **缓存行伪共享**

**什么是伪共享？**

CPU缓存系统中是以缓存行（

cache line）为单位存储的。目前主流的CPU Cache 的

Cache Line 大小都是64Bytes。在多线程情况下，如果需要修改“共享同一个缓存行的变

量”，就会无意中影响彼此的性能，这就是伪共享（

False Sharing）。

举个例子: 现在有2个long 型变量 a 、b，如果有t1在访问a，t2在访问b，而a与b刚好在同一个

cache line中，此时t1先修改a，将导致b被刷新！

**怎么解决伪共享？**

Java8中新增了一个注解：@sun.misc.Contended。加上这个注解的类会自动补齐缓

存行，需要注意的是此注解默认是无效的，需要在jvm启动时设置 -XX:-

RestrictContended 才会生效。

1  @sun.misc.Contended

2  public final static class  TulingVolatileLong  \{

3  public volatile long  value  =  0 L; 4  //public long p1, p2, p3, p4, p5, p6;

5  \}

**MESI** **优化和他们引入的问题**

缓存的一致性消息传递是要时间的，这就使其切换时会产生延迟。当一个缓存被切换状态时其他缓存收到

消息完成各自的切换并且发出回应消息这么一长串的时间中 CPU 都会等待所有缓存响应完成。可能出现的

阻塞都会导致各种各样的性能问题和稳定性问题。

**CPU** **切换状态阻塞解决** **** **存储缓存（** **Store Bufferes** **）**

比如你需要修改本地缓存中的一条信息，那么你必须将 I （无效）状态通知到其他拥有该缓存数据的 CPU 缓

存中，并且等待确认。等待确认的过程会阻塞处理器，这会降低处理器的性能。应为这个等待远远比一个

指令的执行时间长的多。

**Store Bufferes**

为了避免这种 CPU 运算能力的浪费， Store Bufferes 被引入使用。处理器把它想要写入到主存的值写到缓

存，然后继续去处理其他事情。当所有失效确认（

Invalidate Acknowledge ）都接收到时，数据才会最

终被提交。

这么做有两个风险

**Store Bufferes** **的风险**

第一、就是处理器会尝试从存储缓存（ Store buffer ）中读取值，但它还没有进行提交。这个的解决方案

称为 Store Forwarding ，它使得加载的时候，如果存储缓存中存在，则进行返回。

第二、保存什么时候会完成，这个并没有任何保证。

1  value  =  3 ；

2  void  exeToCPUA ()\{

3  value  =  10 ;

4  isFinsh  =  true ;

5  \}

6  void  exeToCPUB ()\{

7  if (isFinsh)\{

8  //value 一定等于 10 ？！

9  assert  value  ==  10 ;

10  \}

11  \}

试想一下开始执行时， CPU A 保存着 finished 在 E( 独享 ) 状态，而 value 并没有保存在它的缓存中。（例

如， Invalid ）。在这种情况下， value 会比 finished 更迟地抛弃存储缓存。完全有可能 CPU B 读取

finished 的值为 true ，而 value 的值不等于 10 。

**即** **isFinsh** **的赋值在** **value** **赋值之前。**

这种在可识别的行为中发生的变化称为重排序（

reordings ）。注意，这不意味着你的指令的位置被恶意

（或者好意）地更改。

它只是意味着其他的 CPU 会读到跟程序中写入的顺序不一样的结果。 顺便提一下 NIO 的设计和 Store Bufferes 的设计是非常相像的。

**硬件内存模型**

执行失效也不是一个简单的操作，它需要处理器去处理。另外，存储缓存（ Store Buffers ）并不是无穷大

的，所以处理器有时需要等待失效确认的返回。这两个操作都会使得性能大幅降低。为了应付这种情况，

引入了失效队列。它们的约定如下：

对于所有的收到的 Invalidate 请求， Invalidate Acknowlege 消息必须立刻发送

Invalidate 并不真正执行，而是被放在一个特殊的队列中，在方便的时候才会去执行。

处理器不会发送任何消息给所处理的缓存条目，直到它处理 Invalidate 。

即便是这样处理器已然不知道什么时候优化是允许的，而什么时候并不允许。

干脆处理器将这个任务丢给了写代码的人。这就是内存屏障（ Memory Barriers ）。

写屏障 Store Memory Barrier(a.k.a. ST, SMB, smp\_wmb)是一条告诉处理器在执行这之后的指令之前，应用所

有已经在存储缓存（

store buffer）中的保存的指令。

读屏障Load Memory Barrier (a.k.a. LD, RMB, smp\_rmb)是一条告诉处理器在执行任何的加载前，先应用所有

已经在失效队列中的失效操作的指令。

1  void  executedOnCpu0 () \{

2  value  =  10 ;

3  // 在更新数据之前必须将所有存储缓存（ store buffer ）中的指令执行完毕。

4  storeMemoryBarrier ();

5  finished  =  true ;

6  \}

7  void  executedOnCpu1 () \{

8  while ( ! finished);

9  // 在读取之前将所有失效队列中关于该数据的指令执行完毕。

10  loadMemoryBarrier ();

11  assert  value  ==  10 ;

12  \}

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/ee1a56a77ba444f3b07ab9be83b86f4e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/37b6f5733dd146408f705528cca31f91.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/1044271a9dda4ff4ad9c0063eca2aa15.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/15c1d1003afc4706bd332e0d0913d90d.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_17_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/c3987204e20b4f63b05dc25e394e62a5.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/89924aa2800546eba710f3024d21dd1e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220828/1b38cbcdcb794d4da63f707f5ecd99de.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 6]: /images/20220828/4fe180d421b047bb8185f5d5003e764f.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 7]: /images/20220828/4054843acd134707af4a7c93e79bf660.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2h1aXh1ZTI0_size_20_color_FFFFFF_t_70_g_se_x_16 8]: /images/20220828/1d2d4b061ffd4de7a5f0c439a3c73c0c.png