上一篇把Cache的基本组织、读命中与缺失的路径都梳理了一遍这篇继续往下走聊写路径和一致性协议MESI。很多初学者在这里会明显感觉到难度上了一个台阶读路径再复杂核心问题无非是“数据在不在Cache里、从哪一层取”但写路径要决策的东西突然变多——修改后的数据到底什么时候落主存写缺失时要不要先把整个块加载进来更重要的问题是多核对同一个地址的副本各持己见时谁说了算这篇就围绕写策略和MESI展开用“问题是什么、为什么这么设计、工程上怎么用”的思路把知识点串成一条完整的逻辑链。写这篇的前提是你已经了解Cache的基本概念比如行、组、命中与缺失。如果还没读过上一篇建议先补上否则下面讲写分配、状态转换时会觉得缺了一层。适合的人群很明确搞多线程开发、高性能计算、底层系统性能优化的同学以及所有想知道“MESI这四个字母到底在解决什么”的人。1. Cache写策略先分清写直达与写回在争什么1.1 写直达Write Through每次写都同步到主存写直达的策略非常朴素无论写命中还是写缺失数据在更新Cache的同时也会同步写到下一级存储一路刷到主存。这样主存里的数据永远是最新的任何其他设备直接读主存即可不用关心Cache里是什么状态。好处是简单、可靠、实现成本低甚至不需要复杂的“脏位”管理——因为所有数据都和主存一致根本不存在被修改过但没落主存的块。但代价也很直白每一次写操作都要走内存总线。在CPU写吞吐量很高的场景下总线会成为瓶颈。想象一下一个变量在循环里被反复修改写直达意味着每次修改都在向主存做一次全量写入内存访问的延迟和功耗非常难看。我通常用记账来类比写直达像是每一笔支出都实时登记到总账本账永远是对的但每买一瓶水都要跑一趟财务室写回则是先记在自己的小本上月底集中对账。小本子就是Cache月底对账就是替换时写回主存。1.2 写回Write Back先攒着替换时再同步写回策略要求Cache行里额外维护一个脏位Dirty Bit表示这行数据被CPU修改过、和主存不一致。写命中时只更新Cache不立即写主存只有当这个脏行被替换出去时才把整行写回主存。写回的核心优势在于利用局部性一个Cache行通常是64字节如果程序在短时间内反复修改同一行内的数据写回策略只需要在最后把整个行写回一次而写直达等于每次都同步白白浪费总线带宽。这正是现代处理器普遍选择写回的原因——实测下来大多数程序对同一内存区域的写入会集中在某段时间内写回策略能显著减少主存访问次数。代价是什么一是硬件变复杂需要在状态里区分“干净行”和“脏行”二是主存中的数据不再一直是最新状态如果其他设备比如DMA控制器直接读主存可能读到旧数据。工程里解决这个问题的办法通常是额外的同步与Cache冲刷操作。1.3 写分配与写不分配写缺失时才显山露水写命中时策略主要在“是否同步到主存”上做取舍。写缺失时CPU要先决定另一件事要不要把这个缺失的块加载进Cache这就引出了写分配Write Allocate和写不分配Write No-Allocate。写分配指的是写缺失时先把对应内存块加载到Cache然后再在Cache里完成写入写不分配则是直接在下一级存储上执行写入不把块加载进来。这两种策略通常会结合前面的命中策略使用常见搭配是写回加写分配写直达加写不分配。这背后的逻辑很合理。写回已经默认数据读进Cache之后会被多次访问那么写缺失时把整个块加载进来后续对这个块的读写都能命中收益大于加载开销。而写直达反正每次都要写到主存用写分配加载块进来的收益很低反而白白占用Cache容量所以写直达更倾向搭配写不分配。注意这不是绝对规则也有实现会使用写回加写不分配的组合但主流思路以上述搭配为主。策略组合写命中行为写缺失行为适用场景写回 写分配更新Cache标记脏加载块到Cache再更新主流处理器各级Cache写直达 写不分配更新Cache并同步主存直接在下一级写入不加载块早期简单实现、部分写缓冲场景写回 写不分配更新Cache标记脏直接写下一级不加载块写入量大但局部性弱的特殊流式场景1.4 写缓冲Write Buffer与写合并写策略背后的加速器写直达和写回都存在一个共同问题写操作不能无限等待主存或下一级Cache返回。为了不让CPU停顿几乎所有实现都会在写路径上插入一个写缓冲Write Buffer。CPU把写请求放进缓冲后可以继续执行由缓冲异步把数据刷到下一级。写缓冲还有一个衍生功能叫写合并Write Combining。如果程序连续写了相邻的地址这些请求会在写缓冲中合并成一个更大的事务。我举个更直观的例子往映射到显存的地址连续写入像素数据如果每次写4字节都单独走一遍总线效率极低但有了写合并几十个连续写请求可以合并为一次突发传输速度差距可以达到数倍甚至一个数量级。不过写缓冲也带来了乱序问题后续的读操作可能先于缓冲中的写操作完成导致程序观测到“写入还没生效”的假象。这个问题在第5章详细展开。这里先记住一点Cache本身是一致性问题的温床写缓冲又是另一层乱序来源两者叠加才逼出了我们后面要聊的内存屏障。2. 缓存一致性问题的根源与两类协议框架2.1 单核没这个问题多核就有了单核CPU中Cache和主存之间虽然也有多级层次但只有CPU一个访问者不存在“两个处理器看到同一数据的不同版本”这个问题。所有数据都是顺序流经各级存储程序观察到的结果不会因为Cache的存在而出现分歧。多核则完全不同。两个核各自拥有私有Cache却共享同一份物理内存。核A改了本地Cache中的一行数据核B如果在自己的Cache里保留着旧副本那么B读到旧数据、主存里也还是旧数据程序就可能违反顺序一致性。问题不再是个体缓存层的数据新鲜度而是多个缓存副本之间的相互可见性。这时候需要一套规则来约束所有Cache和总线或互联网络的交互让所有核对同一地址的访问结果达成共识。这套规则就是缓存一致性协议。2.2 写无效与写更新传播写入的两种极端一致性协议要解决的第一个问题是当某个核写入数据时其他核的旧副本怎么办业界有两条路线。写更新协议Write Update写操作发生时把新数据广播给所有缓存了这个行的核让它们的副本同步更新。思路很简单但有一个致命问题——总线流量会被广播操作迅速打爆。哪怕CPU只写一个字节也得把整条数据发到所有位置。多核规模越大这个方案越不可行。写无效协议Write Invalidate写操作发生时先向其他核发送无效通知让它们的副本状态变为Invalid而不是直接更新数据。需要读时再通过总线重新拉取最新数据。虽然一次写入也需要广播但广播的只是一个无效标记数据只在总线上传输一次流量远小于写更新。这也是MESI一类方案的基础直觉不追求所有副本实时同步而是保证旧副本被“作废”让最先使用该数据的核自己把最新数据拉过去。2.3 总线嗅探与目录怎么知道该通知谁在确定给其他核发通知后还需要解决“通知谁”的问题。这里有两类架构。总线嗅探Bus Snooping设想所有处理器共享一条总线。每个Cache控制器都监听总线上的所有事务如果发现总线上有人在读写自己不关心的地址则无视如果发现这个地址自己的Cache里有副本则根据协议规则做出响应。优点是简单、天然有序——总线本身就是串行的。缺点是广播式通信核数越多、总线越拥挤可扩展性差。目录协议Directory-based则是换一种思路维护一个目录结构记录每个缓存行被哪些核共享、处于什么状态。某个核想写一行缺失的数据时先查询目录只向持有该行副本的核发送失效消息而不是向所有人广播。这样避免了无差别广播适合插槽数量多、跨片通信昂贵的大规模NUMA体系结构。目录协议本质上仍然是MESI这类状态机的实现框架区别只在于控制消息的分发方式。后面第4章会再展开。3. MESI状态机逐状态拆解手把手推演一次完整读写3.1 四种状态的含义M、E、S、I分别代表什么MESI是Modified、Exclusive、Shared、Invalid四个状态的缩写分别描述一个缓存行在这颗核心私有Cache中的身份状态含义主存副本是否最新副本数目ModifiedM本核独占且已修改否Cache中的是最新仅本核一份ExclusiveE本核独占且与主存一致是仅本核一份SharedS多核共享与主存一致是可以有多个核InvalidI该行无效或不在本核Cache中不关心无有效副本M和E的差异值得多琢磨。两者都是“本核独占”区别在于M状态的数据已经被本核修改过、主存滞后而E状态的数据和主存完全一致。正因为E状态下没有其他核持有副本本核要写这行数据时可以直接从E转到M而无需在总线上发送任何通知——因为不存在需要作废的副本。这个细节是MESI优于朴素一致性方案的性能关键。S状态表示可能有多个核心同时持有同一行的副本并且大家看到的都是和主存一致的数据。任何核心想写S状态的行必须先向其他核发送升级请求把它们的状态置为I然后自己变成M。3.2 总线消息MESI的“语言”状态转换不是凭空发生的它依靠以下总线消息驱动。不同处理器实现对消息的命名略有差异但高度对应以下五类总线消息含义引发场景BusRd读请求本核读缺失时发出BusRdX读独占请求后续要写本核写缺失时发出BusUpgrade升级请求不拉数据本核持S/E状态想写时需要作废其他副本Flush将脏数据写回M状态行响应远端读/写请求时FlushOpt可选地转发数据某些优化变体中M状态行直接把最新数据转发给请求方为什么存在BusUpgrade这种不拉数据的消息因为CPU要写的行已经在自己的Cache中只是处于Shared状态。它不需要别人再给自己传一份数据只需要通知其他持有副本的核你们手里的副本作废吧。这样就不必把数据从内存再读一遍大大节省了延迟。3.3 状态转换表一句话记住每个转移下面列一张简化的状态转换表聚焦事件发生时的主要动作不需要背表重点理解每类事件的触发条件当前状态事件目标状态核心动作I本地读BusRdE 或 S无其他副本则到E有则到SI本地写BusRdXM作废其他核副本E本地读E无总线操作E本地写BusUpgradeM无其他副本需要作废故无广播S本地读S无总线操作S本地写BusUpgradeM广播作废其他副本M本地读/写M无总线操作E远端读S自己降级为共享S远端读S保持共享即可M远端读S需要冲刷脏数据到主存或传给请求方M远端写I冲刷后无效S远端写I直接无效E远端写I直接无效一个容易忽略的细节是M状态行被远端读请求击中时不一定要同时写主存。更高效的做法是直接把最新数据传给请求方FlushOpt由请求方更新自己的Cache同时保留M状态核的数据并降级为S。这样避免了不必要的内存访问是后续MOESI/Owned思想的雏形。3.4 两个完整推演从场景角度理解状态机场景一核A写数据核B随后读初始状态核A持I核B持S。核A要写一个变量发出BusRdX请求。核B收到这个请求后发现自己持有的副本是Shared状态于是置为Invalid并响应总线。核A拿到独占权把数据变为Modified完成写入。随后核B要读这个变量发BusRd请求。此时总线上的其他核中核A持有Modified副本它会感知并应答把自己的脏数据冲刷到总线同时状态降级为Shared。核B获得数据后也进入Shared主存得到冲刷后数据。整个过程没有让核B读到旧值。场景二两个核心同时持有S副本其中一个要写核A和核B都缓存了同一行都处于Shared状态。核A执行写操作发出BusUpgrade请求并不要求数据本身——因为核A已经持有数据。总线上核B收到升级请求后把自己的副本置为Invalid。核A收到所有失效完成信号后状态由S转为M接着正常写数据。这个流程比BusRdX少了数据加载环节所以写命中Shared状态的延迟很低。3.5 伪共享开始冒头状态机里藏着的性能炸弹从上面的场景二能嗅到一丝不对劲核A只是修改自己私有的一小片数据却会把核B整个缓存行作废。如果核B也恰好频繁修改另一片位于同一行内的独立数据就会出现两个核完全没有共享逻辑数据却在一致协议层面反复竞争同一个行的情况。这就是伪共享False Sharing第4.3节会专门解决它。这里先记住一点一致性协议操作的粒度是整个缓存行而不是行内的一个字节。4. 从MESI到工程实践变体协议与伪共享排查4.1 MOESI与MESIFMESI的两种重要改良纯MESI有一个绕不开的性能痛点M状态的数据要响应其他核的读请求时必须先写回主存或通过总线转发而这两种操作都会带来额外延迟。MOESI增加了一个OwnedO状态允许数据在拥有者与主存之间“名不正言不顺”地存在O状态行保存最新数据但主存副本也允许是次新的这样其他核读数据时可以由O状态核直接转发不必先把数据写回主存。减少一次内存访问对多写少读场景非常友好。MESIF则引入ForwardF状态用来解决另一个问题当多个核同时处于Shared状态时如果有某个缺失核发出读请求理论上所有S状态核都可以响应但总线上有多个响应者就会造成混乱。F状态指定唯一一个“转发责任人”只有它负责把数据发给请求方其他核保持安静。这能显著降低总线监听和响应开销在某些多核互联设计中较为常见。这些变体并不改变MESI的基本状态框架它们只是在特定工程场景下做增补。理解MESI之后再去看MOESI、MESIF会发现逻辑非常顺畅。4.2 目录协议在大规模系统里落地MESI前面讲过总线嗅探是广播式的而目录协议把“全喊一嗓子”改为“按名单点名”。目录项里保存着每个缓存行的状态以及持有该行的核心列表。以写请求为例目录控制器查到列表只给列表上的核发无效消息而不是广播到所有节点。这样的代价是每次内存访问都要先查目录目录成为热点而且从请求发起到目录应答再到失效完成链路比总线嗅探长。但在多路处理器的NUMA系统中跨节点的消息比片内缓存一致性总线昂贵得多广播式方案通常无法扩展到几十个核心以上。工程上常见做法是片内用总线嗅探或较短的一致域跨片用目录协议整体上对操作系统和应用程序仍然是透明一致的。4.3 伪共享再深挖为什么说它是MESI最隐蔽的敌人这里必须展开讲因为伪共享是MESI对性能影响最直接的体现。假设有两个线程分别和两个不同的int变量交互这两个int在源码中的地址恰好相邻。现代Cache行大小普遍是64字节两个int落在同一行内。于是线程A每次写自己的intMESI都会让线程B持有的整个行失效线程B再访问自己的int时需要重新拉取这行数据尽管那个int根本没有被线程A碰过。从结果看两个线程实际是在交替读写同一行产生大量的总线流量、缓存缺失和延迟等待。最可气的是逻辑上两个变量完全无关问题完全出在内存布局上。我见过一个多线程累加计数器的Benchmark线程数加到16时伪共享版本的耗时可以比消除伪共享版本高出三到五倍而功能上两者完全等价。检查代码时你未必能直接看到伪共享因为它不存在数据竞争或逻辑错误程序输出完全正确只有性能曲线会异常。这也是这类问题最坑的地方——它不会让程序出错只会让程序莫名变慢。4.4 实测伪共享的一个参考做法写一段示意逻辑来说明如何测量和定位struct counter { int value; }; struct counter counters[4];四个核分别更新counters[0].value、counters[1].value……如果这些struct counter在数组里是连续挨着的多个核就会互相作废整行。把结构体改成struct counter { int value; char padding[60]; // 凑够64字节的Cache行 };再跑一次同样负载时间差异会非常直观。实际定位时用性能分析工具监控cache-misses和总线周期数通常能看到cache-miss率在伪共享版本上显著偏高。注意不同平台的Cache行大小可能不同x86主流桌面和服务器目前普遍是64字节有些ARM平台是64字节也有个别平台是128字节。如果做跨平台优化建议用运行时读取或编译期探测不要硬编码。5. 从MESI到内存模型写缓冲与内存屏障才是最后一环5.1 MESI保证了一致性但没有保证顺序很多初学者会有一种错觉既然MESI保证所有核看到的缓存行最终一致那程序里的普通变量读写是不是天然就是顺序一致的呢答案是否定的。MESI只负责缓存行副本之间的相互同步但它没有约束CPU执行指令的乱序能力也没有消除写缓冲带来的延后写入问题。一个指令序列在实际CPU上可以被重排或者说在另一个核的视角下观察到的是与程序编写顺序不同的效果。MESI保证的是“当我读到某个地址的最新版本时我读到的确实是某个全局最新版本”但无法保证“我读到版本A时必然也看到了版本A之前的所有写入”。后者属于内存模型问题。5.2 store buffer引发的经典乱序现象典型例子是两个线程通过共享状态变量通信线程1设置data 1设置flag 1线程2循环等待flag 1然后读取data直觉上线程2看到flag 1时data应该已经被设置为1。但在缺乏屏障的情况下线程2可能读到flag 1但data 0。原因是线程1的两个store可能被CPU重排或者data 1还在store buffer中排队而flag 1已经刷出。MESI确实保证flag对应的缓存行一旦变成Modified其他核会看到这个值但它管不了flag和data这两个不同地址的写入顺序。在并发编程里这种“可见顺序”需要用内存屏障或带屏障语义的原语比如CAS、原子交换来强制。5.3 volatile与内存屏障在MESI体系里的定位现在可以比较完整地理解volatile的作用它告诉编译器和CPU该变量的访问不能被重排到某些边界之外必须从内存中读取最新值并且写入要及时对其他线程可见。物理层面MESI保证了缓存副本会因总线消息而失效逻辑层面需要屏障指令防止CPU和编译器打乱访问顺序。工程中的常见做法是不加修饰的共享变量仅用于单线程或已知同步保护的场景跨线程同步用锁、原子变量等带有获取/释放语义的原语。直接裸写普通变量volatile来构建锁几乎一定会踩到内存序的坑。记住一条经验MESI解决的是缓存一致问题内存屏障解决的是顺序一致问题两者配合才能构成并发正确性的地基绝不是同一件事。6. 实战排查记录几个与Cache相关的经典问题6.1 多线程程序随线程数增加反而变慢的排查思路这类问题出现时我通常按下面顺序走一遍先跑性能分析工具观察cache-misses是否异常升高、总线周期占比是否过高。检查共享变量在内存中的布局是不是多个线程频繁修改的地址落在同一个缓存行内。检查锁竞争如果多个线程在同一把锁上忙等锁对象的缓存行会成为一个天然的串行化点。配合核心负载与亲和性设置确认线程是否真的在计划运行的核上执行。前两步最常见也是伪共享的典型征兆。如果确认是伪共享对齐与padding即可解决不用改任何同步逻辑。6.2 几个容易忽略的工程细节malloc分配的堆对象并非全都孤立连续分配的小对象经常落在同一缓存行。用对齐分配或把热数据放进独立结构体能有效减少这种冲突。原子变量的操作并不自动消除伪共享。两个线程各自对同一个行上的不同原子变量做无锁更新依然会被MESI拖住。大多数现代平台中Cache行包含了字节、字等所有粒度的一致状态控制所以“我只改了1个字节为什么需要淘汰整个行”的疑问是对的但这正是硬件的实现限制。对齐不是银弹。过度padding会增加内存占用、降低容量命中率只应在压测确认热点后再使用。跨平台的Cache行大小、一致性协议细节可能存在差异把优化封装在平台适配层里不要直接散落在业务代码各处。6.3 对一致性知识的落地理解严格来说普通应用代码开发者不需要直接操作MESI状态但它决定了你写的并发程序性能好不好、bug难不难查。当你理解了写回、写无效、伪共享、store buffer这些概念之后再看很多性能优化技巧比如无锁队列为什么用缓存行填充、单写者多读者为什么比多写者更快、为什么某些共享计数器需要分批累加会豁然开朗。我在实际工作中有一个体会可以先在纸上推导一遍MESI状态转换再写一个简单的多线程Benchmark验证伪共享影响把这个“理论到实验”的过程走通之后这些知识基本就很难忘了。最后再分享一个我自己踩过的坑有一阶段在做多线程统计模块时把每个线程的计数结果挨个放在一个共享结构体里结果随着线程数增加耗时不但没下降反而节节攀升。排查了很久才发现是同一个缓存行内两个相邻计数器在互相作废加了一行padding后性能立刻恢复。从那以后我对每个多线程热路径上的共享数据都默认带上了“缓存行边界”这层意识。Cache相关的坑就是这样你不知道时它让你欲哭无泪你摸清规律后它就会变成手里最顺手的一把性能优化利器。