CPU讀寫內存，炸了！

是人性的扭曲，還是道德的淪喪，好好的CPU變成了這樣：

CPU讀寫內存時，到底經歷了什么？

如果你覺得這是一個非常簡單的問題，那么你真應該好好讀讀本文，我敢保證這個問題絕沒有你想象的那么簡單。

注意，一定要完本文，否則可能會得出錯誤的結論。

閑話少說，讓我們來看看CPU在讀寫內存時底層究竟發(fā)生了什么。

誰來告訴CPU讀寫內存

我們第一個要搞清楚的問題是：誰來告訴CPU去讀寫內存？

答案很明顯，是程序員，更具體的是編譯器。

CPU只是按照指令按部就班的執(zhí)行，機器指令從哪里來的呢？是編譯器生成的，程序員通過高級語言編寫程序，編譯器將其翻譯為機器指令，機器指令來告訴CPU去讀寫內存。

在精簡指令集架構下會有特定的機器指令，Load/Store指令來讀寫內存，以x86為代表的復雜指令集架構下沒有特定的訪存指令。

精簡指令集下，一條機器指令操作的數據必須來存放在寄存器中，不能直接操作內存數據，因此RISC下，數據必須先從內存搬運到寄存器，這就是為什么RISC下會有特定的Load/Store訪存指令，明白了吧。

而x86下無此限制，一條機器指令操作的數據可以來自于寄存器也可以來自內存，因此這樣一條機器指令在執(zhí)行過程中會首先從內存中讀取數據。

關于復雜指令集以及精簡指令集你可以參考這兩篇文章《CPU進化論：復雜指令集》與《不懂精簡指令集還敢說自己是程序員？》

兩種內存讀寫

現在我們知道了，是特定的機器指令告訴CPU要去訪問內存。

不過，值得注意的是，不管是RISC下特定的Load/Store指令還是x86下包含在一條指令內部的訪存操作，這里讀寫的都是內存中的數據，除此之外還要意識到，CPU除了從內存中讀寫數據外，還要從內存中讀取下一條要執(zhí)行的機器指令。

畢竟，我們的計算設備都遵從馮諾依曼架構：程序和數據一視同仁，都可以存放在內存中。

現在，我們清楚了CPU讀寫內存其實是由兩個因素來驅動的：

1. 程序執(zhí)行過程中需要讀寫來自內存中的數據

2. CPU需要訪問內存讀取下一條要執(zhí)行的機器指令

然后CPU根據機器指令中包含的內存地址或者PC寄存器中下一條機器指令的地址訪問內存。

這不就完了嗎？有了內存地址，CPU利用硬件通路直接讀內存就好了，你可能也是這樣的想的。

真的是這樣嗎？別著急，我們接著往下看，這兩節(jié)只是開胃菜，正餐才剛剛開始。

急性子吃貨 VS 慢性子廚師

假設你是一個整天無所事事的吃貨，整天無所事事，唯一的愛好就是找一家餐廳吃吃喝喝，由于你是職業(yè)吃貨，因此吃起來非常職業(yè)，1分鐘就能吃完一道菜，但這里的廚師就沒有那么職業(yè)了，炒一道菜速度非常慢，大概需要1小時40分鐘才能炒出一道菜，速度比你慢了100倍，如果你是這個吃貨，大概率會瘋掉的。

而CPU恰好就是這樣一個吃貨，內存就是這樣一個慢吞吞的廚師，而且隨著時間的推移這兩者的速度差異正在越來越大：

在這種速度差異下，CPU執(zhí)行一條涉及內存讀寫指令時需要等“很長一段時間“數據才能”緩緩的“從內存讀取到CPU中，在這種情況你還認為CPU應該直接讀寫內存嗎？

無處不在的28定律

28定律我想就不用多介紹了吧，在《不懂精簡指令集還敢說自己是程序員》這篇文章中也介紹過，CPU執(zhí)行指令符合28定律，大部分時間都在執(zhí)行那一少部分指令，這一現象的發(fā)現奠定了精簡指令集設計的基礎。

而程序操作的數據也符合類似的定律，只不過不叫28定律，而是叫principle of locality，程序局部性原理。

如果我們訪問內存中的一個數據A，那么很有可能接下來再次訪問到，同時還很有可能訪問與數據A相鄰的數據B，這分別叫做時間局部性和空間局部性。

如圖所示，該程序占據的內存空間只有一少部分在程序執(zhí)行過程經常用到。

有了這個發(fā)現重點就來了，既然只用到很少一部分，那么我們能不能把它們集中起來呢？就像這樣：

集中起來然后呢？放到哪里呢？

當然是放到一種比內存速度更快的存儲介質上，這種介質就是我們熟悉的SRAM，普通內存一般是DRAM，這種讀寫速度更快的介質充當CPU和內存之間的Cache，這就是所謂的緩存。

四兩撥千斤

我們把經常用到的數據放到cache中存儲，CPU訪問內存時首先查找cache，如果能找到，也就是命中，那么就賺到了，直接返回即可，找不到再去查找內存并更新cache。

我們可以看到，有了cache，CPU不再直接與內存打交道了。

但cache的快速讀寫能力是有代價的，代價就是Money，造價不菲，因此我們不能把內存完全替換成cache的SRAM，那樣的計算機你我都是買不起的。

因此cache的容量不會很大，但由于程序局部性原理，因此很小的cache也能有很高的命中率，從而帶來性能的極大提升，有個詞叫四兩撥千斤，用到cache這里再合適不過。

天下沒有免費的午餐

雖然小小的cache能帶來性能的極大提升，但，這也是有代價的。

這個代價出現在寫內存時。

當CPU需要寫內存時該怎么辦呢？

現在有了cache，CPU不再直接與內存打交道，因此CPU直接寫cache，但此時就會有一個問題，那就是cache中的值更新了，但內存中的值還是舊的，這就是所謂的不一致問題，inconsistent.

就像下圖這樣，cache中變量的值是4，但內存中的值是2。

同步緩存更新

常用 redis 的同學應該很熟悉這個問題，可是你知道嗎？這個問題早就在你讀這篇文章用的計算設備其包含的CPU中已經遇到并已經解決了。

最簡單的方法是這樣的，當我們更新cache時一并把內存也更新了，這種方法被稱為 write-through，很形象吧。

可是如果當CPU寫cache時，cache中沒有相應的內存數據該怎么呢？這就有點麻煩了，首先我們需要把該數據從內存加載到cache中，然后更新cache，再然后更新內存。

這種實現方法雖然簡單，但有一個問題，那就是性能問題，在這種方案下寫內存就不得不訪問內存，上文也提到過CPU和內存可是有很大的速度差異哦，因此這種方案性能比較差。

有辦法解決嗎？答案是肯定的。

異步更新緩存

這種方法性能差不是因為寫內存慢，寫內存確實是慢，更重要的原因是CPU在同步等待，因此很自然的，這類問題的統一解法就是把同步改為異步。

關于同步和異步的話題，你可以參考這篇文章《從小白到高手，你需要理解同步和異步》。

異步的這種方法是這樣的，當CPU寫內存時，直接更新cache，然后，注意，更新完cache后CPU就可以認為寫內存的操作已經完成了，盡管此時內存中保存的還是舊數據。

當包含該數據的cache塊被剔除時再更新到內存中，這樣CPU更新cache與更新內存就解耦了，也就是說，CPU更新cache后不再等待內存更新，這就是異步，這種方案也被稱之為write-back，這種方案相比write-through來說更復雜，但很顯然，性能會更好。

現在你應該能看到，添加cache后會帶來一系列問題，更不用說cache的替換算法，畢竟cache的容量有限，當cache已滿時，增加一項新的數據就要剔除一項舊的數據，那么該剔除誰就是一個非常關鍵的問題，限于篇幅就不在這里詳細講述了，你可以參考《深入理解操作系統》第7章有關于該策略的講解。

多級cache

現代CPU為了增加CPU讀寫內存性能，已經在CPU和內存之間增加了多級cache，典型的有三級，L1、L2和L3，CPU讀內存時首先從L1 cache找起，能找到直接返回，否則就要在L2 cache中找，L2 cache中找不到就要到L3 cache中找，還找不到就不得不訪問內存了。

因此我們可以看到，現代計算機系統CPU和內存之間其實是有一個cache的層級結構的。

越往上，存儲介質速度越快，造價越高容量也越小；越往下，存儲介質速度越慢，造價越低但容量也越大。

現代操作系統巧妙的利用cache，以最小的代價獲得了最大的性能。

但是，注意這里的但是，要想獲得極致性能是有前提的，那就是程序員寫的程序必須具有良好的局部性，充分利用緩存。

高性能程序在充分利用緩存這一環(huán)節(jié)可謂絞盡腦汁煞費苦心，關于這一話題值得單獨成篇，關注公眾號“碼農的荒島求生”，并回復“todo”，你可以看到之前所有挖坑的進展如何。

鑒于cache的重要性，現在增大cache已經成為提升CPU性能的重要因素，因此你去看當今的CPU布局，其很大一部分面積都用在了cache上。

你以為這就完了嗎？

哈哈，哪有這么容易的，否則也不會是終面題目了。

那么當CPU讀寫內存時除了面臨上述問題外還需要處理哪些問題呢？

多核，多問題

當摩爾定律漸漸失效后雞賊的人類換了另一種提高CPU性能的方法，既然單個CPU性能不好提升了，我們還可以堆數量啊，這樣，CPU進入多核時代，程序員開始進入苦逼時代。

擁有一堆核心的CPU其實是沒什么用的，關鍵需要有配套的多線程程序才能真正發(fā)揮多核的威力，但寫過多線程程序的程序員都知道，能寫出來不容易，能寫出來并且能正確運行更不容易，關于多線程與多線程編程的詳細闡述請參見《深入理解操作系統》第5、6兩章(關注公眾號“碼農的荒島求生”并回復“操作系統”)。

CPU開始擁有多個核心后不但苦逼了軟件工程師，硬件工程師也不能幸免。

前文提到過，為提高CPU 訪存性能，CPU和內存之間會有一個層cache，但當CPU有多個核心后新的問題來了：

現在假設內存中有一變量X，初始值為2。

系統中有兩個CPU核心C1和C2，現在C1和C2要分別讀取內存中X的值，根據cache的工作原理，首次讀取X不能命中cache，因此從內存中讀取到X后更新相應的cache，現在C1 cache和C2 cache中都有變量X了，其值都是2。

接下來C1需要對X執(zhí)行+2操作，同樣根據cache的工作原理，C1從cache中拿到X的值+2后更新cache，在然后更新內存，此時C1 cache和內存中的X值都變?yōu)榱?。

然后C2也許需要對X執(zhí)行加法操作，假設需要+4，同樣根據cache的工作原理，C2從cache中拿到X的值+4后更新cache，此時cache中的值變?yōu)榱?（2+4），再更新內存，此時C2 cache和內存中的X值都變?yōu)榱?。

看出問題在哪里了嗎？

一個初始值為2的變量，在分別+2和+4后正確的結果應該是2+2+4 = 8，但從上圖可以看出內存中X的值卻為6，問題出在哪了呢？

多核cache一致性

有的同學可能已經發(fā)現了，問題出在了內存中一個X變量在C1和C2的cache中有共計兩個副本，當C1更新cache時沒有同步修改C2 cache中X的值。

解決方法是什么呢？

顯然，如果一個cache中待更新的變量同樣存在于其它核心的cache，那么你需要一并將其它cache也更新好。

現在你應該看到，CPU更新變量時不再簡單的只關心自己的cache和內存，你還需要知道這個變量是不是同樣存在于其它核心中的cache，如果存在需要一并更新。

當然，這還只是簡單的讀，寫就更加復雜了，實際上，現代CPU中有一套協議來專門維護緩存的一致性，比較經典的包括MESI協議等。

為什么程序員需要關心這個問題呢？原因很簡單，你最好寫出對cache一致性協議友好的程序，因為cache頻繁維護一致性也是有性能代價的。

同樣的，限于篇幅，這個話題不再詳細闡述，該主題同樣值得單獨成篇，敬請期待。

夠復雜了吧！

怎么樣？到目前為止，是不是CPU讀寫內存沒有看上去那么簡單？

現代計算機中CPU和內存之間有多級cache，CPU讀寫內存時不但要維護cache和內存的一致性，同樣需要維護多核間cache的一致性。

你以為這就完了，NONO，最大的謎團其實是接下來要講的。

你以為的不是你以為的

現代程序員寫程序基本上不需要關心內存是不是足夠這個問題，但這個問題在遠古時代絕對是困擾程序員的一大難題。

如果你去想一想，其實現代計算機內存也沒有足夠大的讓我們隨便申請的地步，但是你在寫程序時是不是基本上沒有考慮過內存不足該怎么辦？

為什么我們在內存資源依然處于匱乏的現代可以做到申請內存時卻進入內存極大豐富的共產主義理想社會了呢？

原來這背后的功臣是我們熟悉的操作系統。

操作系統對每個進程都維護一個假象，即，每個進程獨占系統內存資源；同時給程序員一個承諾，讓程序員可以認為在寫程序時有一大塊連續(xù)的內存可以使用。

這當然是不可能不現實的，因此操作系統給進程的地址空間必然不是真的，但我們又不好將其稱之為“假的地址空間”，這會讓人誤以為計算機科學界里騙子橫行，因此就換了一個好聽的名字，虛擬內存，一個“假的地址空間”更高級的叫法。

進程其實一直活在操作系統精心維護的幻覺當中，就像《盜夢空間》一樣，關于虛擬內存的詳盡闡述請參見《深入理解操作系統》第七章(關注公眾號“碼農的荒島求生”并回復“操作系統”)。

從這個角度看，其實最擅長包裝的是計算機科學界，哦，對了，他們不但擅長包裝還擅長抽象。

天真的CPU

CPU真的是很傻很天真的存在。

上一節(jié)講的操作系統施加的障眼法把CPU也蒙在鼓里。

CPU執(zhí)行機器指令時，指令指示CPU從內存地址A中取出數據，然后CPU執(zhí)行機器指令時下發(fā)命令：“給我從地址A中取出數據”，盡管真的能從地址A中取出數據，但這個地址A不是真的，不是真的，不是真的。

因為這個地址A屬于虛擬內存，也就是那個“假的地址空間”，現代CPU內部有一個叫做MMU的模塊將這假的地址A轉換為真的地址B，將地址A轉換為真實的地址B之后才是本文之前講述的關于cache的那一部分。

你以為這終于應該講完了吧！

NONO！

CPU給出內存地址，此后該地址被轉為真正的物理內存地址，接下來查L1 cache，L1 cache不命中查L2 cache，L2 cache不命中查L3 cache，L3 cache不能命中查內存。

各單位注意，各單位注意，到查內存時還不算完，現在有了虛擬內存，內存其實也是一層cache，是磁盤的cache，也就是說查內存也有可能不會命中，因為內存中的數據可能被虛擬內存系統放到磁盤中了，如果內存也不能命中就要查磁盤。

So crazy，限于篇幅這個過程不再展開，《深入理解操作系統》第七章有完整的講述。

至此，CPU讀寫內存時完整的過程闡述完畢。

總結

現在你還認為CPU讀寫內存非常簡單嗎？

這一過程涉及到的硬件以及硬件邏輯包括：L1 cache、L2 cache、L3 cache、多核緩存一致性協議、MMU、內存、磁盤；軟件主要包括操作系統。

這一看似簡單的操作涉及幾乎所有計算機系統中的核心組件，需要軟件以及硬件密切配合才能完成。

這個過程給程序員的啟示是：

1)，現代計算機系統是非常復雜的；

2)，你需要寫出對cache友好的程序。