CPU 如何讀寫數(shù)據(jù)的？

先來認識 CPU 的架構(gòu)，只有理解了 CPU 的 架構(gòu)，才能更好地理解 CPU 是如何讀寫數(shù)據(jù)的，對于現(xiàn)代 CPU 的架構(gòu)圖如下：可以看到，一個 CPU 里通常會有多個 CPU 核心，比如上圖中的 1 號和 2 號 CPU 核心，并且每個 CPU 核心都有自己的 L1 Cache 和 L2 Cache，而 L1 Cache 通常分為 dCache（數(shù)據(jù)緩存） 和 iCache（指令緩存），L3 Cache 則是多個核心共享的，這就是 CPU 典型的緩存層次。上面提到的都是 CPU 內(nèi)部的 Cache，放眼外部的話，還會有內(nèi)存和硬盤，這些存儲設(shè)備共同構(gòu)成了金字塔存儲層次從上圖也可以看到，從上往下，存儲設(shè)備的容量會越大，而訪問速度會越慢。至于每個存儲設(shè)備的訪問延時，你可以看下圖的表格：你可以看到， CPU 訪問 L1 Cache 速度比訪問內(nèi)存快 100 倍，這就是為什么 CPU 里會有 L1~L3 Cache 的原因，目的就是把 Cache 作為 CPU 與內(nèi)存之間的緩存層，以減少對內(nèi)存的訪問頻率。CPU 從內(nèi)存中讀取數(shù)據(jù)到 Cache 的時候，并不是一個字節(jié)一個字節(jié)讀取，而是一塊一塊的方式來讀取數(shù)據(jù)的，這一塊一塊的數(shù)據(jù)被稱為 CPU Line（緩存行），所以 CPU Line 是 CPU 從內(nèi)存讀取數(shù)據(jù)到 Cache 的單位。至于 CPU Line 大小，在 Linux 系統(tǒng)可以用下面的方式查看到，你可以看我服務(wù)器的 L1 Cache Line 大小是 64 字節(jié)，也就意味著 L1 Cache 一次載入數(shù)據(jù)的大小是 64 字節(jié)。那么對數(shù)組的加載， CPU 就會加載數(shù)組里面連續(xù)的多個數(shù)據(jù)到 Cache 里，因此我們應(yīng)該按照物理內(nèi)存地址分布的順序去訪問元素，這樣訪問數(shù)組元素的時候，Cache 命中率就會很高，于是就能減少從內(nèi)存讀取數(shù)據(jù)的頻率， 從而可提高程序的性能。但是，在我們不使用數(shù)組，而是使用單獨的變量的時候，則會有 Cache 偽共享的問題，Cache 偽共享問題上是一個性能殺手，我們應(yīng)該要規(guī)避它。接下來，就來看看 Cache 偽共享是什么？又如何避免這個問題？現(xiàn)在假設(shè)有一個雙核心的 CPU，這兩個 CPU 核心并行運行著兩個不同的線程，它們同時從內(nèi)存中讀取兩個不同的數(shù)據(jù)，分別是類型為 long 的變量 A 和 B，這個兩個數(shù)據(jù)的地址在物理內(nèi)存上是連續(xù)的，如果 Cahce Line 的大小是 64 字節(jié)，并且變量 A 在 Cahce Line 的開頭位置，那么這兩個數(shù)據(jù)是位于同一個 Cache Line 中，又因為 CPU Line 是 CPU 從內(nèi)存讀取數(shù)據(jù)到 Cache 的單位，所以這兩個數(shù)據(jù)會被同時讀入到了兩個 CPU 核心中各自 Cache 中。我們來思考一個問題，如果這兩個不同核心的線程分別修改不同的數(shù)據(jù)，比如 1 號 CPU 核心的線程只修改了 變量 A，或 2 號 CPU 核心的線程的線程只修改了變量 B，會發(fā)生什么呢？

1、分析偽共享的問題

現(xiàn)在我們結(jié)合保證多核緩存一致的 MESI 協(xié)議，來說明這一整個的過程，如果你還不知道 MESI 協(xié)議，你可以看我這篇文章「10 張圖打開 CPU 緩存一致性的大門」。①. 最開始變量 A 和 B 都還不在 Cache 里面，假設(shè) 1 號核心綁定了線程 A，2 號核心綁定了線程 B，線程 A 只會讀寫變量 A，線程 B 只會讀寫變量 B。

②. 1 號核心讀取變量 A，由于 CPU 從內(nèi)存讀取數(shù)據(jù)到 Cache 的單位是 Cache Line，也正好變量 A 和 變量 B 的數(shù)據(jù)歸屬于同一個 Cache Line，所以 A 和 B 的數(shù)據(jù)都會被加載到 Cache，并將此 Cache Line 標記為「獨占」狀態(tài)。③.  接著，2 號核心開始從內(nèi)存里讀取變量 B，同樣的也是讀取 Cache Line 大小的數(shù)據(jù)到 Cache 中，此 Cache Line 中的數(shù)據(jù)也包含了變量 A 和 變量 B，此時 1 號和 2 號核心的 Cache Line 狀態(tài)變?yōu)椤腹蚕怼範顟B(tài)。④. 1 號核心需要修改變量 A，發(fā)現(xiàn)此 Cache Line 的狀態(tài)是「共享」狀態(tài)，所以先需要通過總線發(fā)送消息給 2 號核心，通知 2 號核心把 Cache 中對應(yīng)的 Cache Line 標記為「已失效」狀態(tài)，然后 1 號核心對應(yīng)的 Cache Line 狀態(tài)變成「已修改」狀態(tài)，并且修改變量 A。⑤. 之后，2 號核心需要修改變量 B，此時 2 號核心的 Cache 中對應(yīng)的 Cache Line 是已失效狀態(tài)，另外由于 1 號核心的 Cache 也有此相同的數(shù)據(jù)，且狀態(tài)為「已修改」狀態(tài)，所以要先把 1 號核心的 Cache 對應(yīng)的 Cache Line 寫回到內(nèi)存，然后 2 號核心再從內(nèi)存讀取 Cache Line 大小的數(shù)據(jù)到 Cache 中，最后把變量 B 修改到 2 號核心的 Cache 中，并將狀態(tài)標記為「已修改」狀態(tài)。所以，可以發(fā)現(xiàn)如果 1 號和 2 號 CPU 核心這樣持續(xù)交替的分別修改變量 A 和 B，就會重復(fù) ④ 和 ⑤ 這兩個步驟，Cache 并沒有起到緩存的效果，雖然變量 A 和 B 之間其實并沒有任何的關(guān)系，但是因為同時歸屬于一個 Cache Line ，這個 Cache Line 中的任意數(shù)據(jù)被修改后，都會相互影響，從而出現(xiàn) ④ 和 ⑤ 這兩個步驟。因此，這種因為多個線程同時讀寫同一個 Cache Line 的不同變量時，而導(dǎo)致 CPU Cache 失效的現(xiàn)象稱為偽共享（False Sharing）。

2、避免偽共享的方法

因此，對于多個線程共享的熱點數(shù)據(jù)，即經(jīng)常會修改的數(shù)據(jù)，應(yīng)該避免這些數(shù)據(jù)剛好在同一個 Cache Line 中，否則就會出現(xiàn)為偽共享的問題。接下來，看看在實際項目中是用什么方式來避免偽共享的問題的。在 Linux 內(nèi)核中存在 __cacheline_aligned_in_smp 宏定義，是用于解決偽共享的問題。

從上面的宏定義，我們可以看到：

如果在多核（MP）系統(tǒng)里，該宏定義是 __cacheline_aligned，也就是 Cache Line 的大小；

而如果在單核系統(tǒng)里，該宏定義是空的；

因此，針對在同一個 Cache Line 中的共享的數(shù)據(jù)，如果在多核之間競爭比較嚴重，為了防止偽共享現(xiàn)象的發(fā)生，可以采用上面的宏定義使得變量在 Cache Line 里是對齊的。舉個例子，有下面這個結(jié)構(gòu)體：

結(jié)構(gòu)體里的兩個成員變量 a 和 b 在物理內(nèi)存地址上是連續(xù)的，于是它們可能會位于同一個 Cache Line 中，如下圖：所以，為了防止前面提到的 Cache 偽共享問題，我們可以使用上面介紹的宏定義，將 b 的地址設(shè)置為 Cache Line 對齊地址。