你清楚下面這幾個(gè)問題嗎？有了內(nèi)存，為什么還需要 CPU Cache？CPU 是怎么讀寫數(shù)據(jù)的？如何讓 CPU 能讀取數(shù)據(jù)較快一些？CPU 偽共享是如何發(fā)生的？又該如何避免？CPU 是如何調(diào)度任務(wù)的？如果你的任務(wù)對(duì)響應(yīng)要求很高，你希望它總是能被先調(diào)度，這該怎么辦？…這篇，我們就來回答這些問題。
CPU 如何讀寫數(shù)據(jù)的？
先來認(rèn)識(shí) CPU 的架構(gòu)，只有理解了 CPU 的 架構(gòu)，才能較好地理解 CPU 是如何讀寫數(shù)據(jù)的，對(duì)于現(xiàn)代 CPU 的架構(gòu)圖如下： 可以看到，一個(gè) CPU 里通常會(huì)有多個(gè) CPU **，比如上圖中的 1 號(hào)和 2 號(hào) CPU **，并且每個(gè) CPU **都有自己的 L1 Cache 和 L2 Cache，而 L1 Cache 通常分為 dCache（數(shù)據(jù)緩存） 和 iCache（指令緩存），L3 Cache 則是多個(gè)**共享的，這就是 CPU 典型的緩存層次。上面提到的都是 CPU 內(nèi)部的 Cache，放眼外部的話，還會(huì)有內(nèi)存和硬盤，這些存儲(chǔ)設(shè)備共同構(gòu)成了金字塔存儲(chǔ)層次。如下圖所示： 從上圖也可以看到，從上往下，存儲(chǔ)設(shè)備的容量會(huì)越大，而訪問速度會(huì)越慢。至于每個(gè)存儲(chǔ)設(shè)備的訪問延時(shí)，你可以看下圖的表格： 你可以看到， CPU 訪問 L1 Cache 速度比訪問內(nèi)存快 100 倍，這就是為什么 CPU 里會(huì)有 L1~L3 Cache 的原因，目的就是把 Cache 作為 CPU 與內(nèi)存之間的緩存層，以減少對(duì)內(nèi)存的訪問頻率。CPU 從內(nèi)存中讀取數(shù)據(jù)到 Cache 的時(shí)候，并不是一個(gè)字節(jié)一個(gè)字節(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é)。 那么對(duì)數(shù)組的加載， CPU 就會(huì)加載數(shù)組里面連續(xù)的多個(gè)數(shù)據(jù)到 Cache 里，因此我們應(yīng)該按照物理內(nèi)存地址分布的順序去訪問元素，這樣訪問數(shù)組元素的時(shí)候，Cache 命中率就會(huì)很高，于是就能減少從內(nèi)存讀取數(shù)據(jù)的頻率， 從而可提高程序的性能。但是，在我們不使用數(shù)組，而是使用單獨(dú)的變量的時(shí)候，則會(huì)有 Cache 偽共享的問題，Cache 偽共享問題上是一個(gè)性能**，我們應(yīng)該要規(guī)避它。接下來，就來看看 Cache 偽共享是什么？又如何避免這個(gè)問題？現(xiàn)在假設(shè)有一個(gè)雙**的 CPU，這兩個(gè) CPU **并行運(yùn)行著兩個(gè)不同的線程，它們同時(shí)從內(nèi)存中讀取兩個(gè)不同的數(shù)據(jù)，分別是類型為 long 的變量 A 和 B，這個(gè)兩個(gè)數(shù)據(jù)的地址在物理內(nèi)存上是連續(xù)的，如果 Cahce Line 的大小是 64 字節(jié)，并且變量 A 在 Cahce Line 的開頭位置，那么這兩個(gè)數(shù)據(jù)是位于同一個(gè) Cache Line 中，又因?yàn)?CPU Line 是 CPU 從內(nèi)存讀取數(shù)據(jù)到 Cache 的單位，所以這兩個(gè)數(shù)據(jù)會(huì)被同時(shí)讀入到了兩個(gè) CPU **中各自 Cache 中。 我們來思考一個(gè)問題，如果這兩個(gè)不同**的線程分別修改不同的數(shù)據(jù)，比如 1 號(hào) CPU **的線程只修改了 變量 A，或 2 號(hào) CPU **的線程的線程只修改了變量 B，會(huì)發(fā)生什么呢？
1、分析偽共享的問題
現(xiàn)在我們結(jié)合保證多核緩存一致的 MESI 協(xié)議，來說明這一整個(gè)的過程，如果你還不知道 MESI 協(xié)議，你可以看我這篇文章「10 張圖打開 CPU 緩存一致性的大門」。①. 較開始變量 A 和 B 都還不在 Cache 里面，假設(shè) 1 號(hào)**綁定了線程 A，2 號(hào)**綁定了線程 B，線程 A 只會(huì)讀寫變量 A，線程 B 只會(huì)讀寫變量 B。 ②. 1 號(hào)**讀取變量 A，由于 CPU 從內(nèi)存讀取數(shù)據(jù)到 Cache 的單位是 Cache Line，也正好變量 A 和 變量 B 的數(shù)據(jù)歸屬于同一個(gè) Cache Line，所以 A 和 B 的數(shù)據(jù)都會(huì)被加載到 Cache，并將此 Cache Line 標(biāo)記為「獨(dú)占」?fàn)顟B(tài)。 ③. 接著，2 號(hào)**開始從內(nèi)存里讀取變量 B，同樣的也是讀取 Cache Line 大小的數(shù)據(jù)到 Cache 中，此 Cache Line 中的數(shù)據(jù)也包含了變量 A 和 變量 B，此時(shí) 1 號(hào)和 2 號(hào)**的 Cache Line 狀態(tài)變?yōu)椤腹蚕怼範(fàn)顟B(tài)。 ④. 1 號(hào)**需要修改變量 A，發(fā)現(xiàn)此 Cache Line 的狀態(tài)是「共享」?fàn)顟B(tài)，所以先需要通過總線發(fā)送消息給 2 號(hào)**，通知 2 號(hào)**把 Cache 中對(duì)應(yīng)的 Cache Line 標(biāo)記為「已失效」?fàn)顟B(tài)，然后 1 號(hào)**對(duì)應(yīng)的 Cache Line 狀態(tài)變成「已修改」?fàn)顟B(tài)，并且修改變量 A。 ⑤. 之后，2 號(hào)**需要修改變量 B，此時(shí) 2 號(hào)**的 Cache 中對(duì)應(yīng)的 Cache Line 是已失效狀態(tài)，另外由于 1 號(hào)**的 Cache 也有此相同的數(shù)據(jù)，且狀態(tài)為「已修改」?fàn)顟B(tài)，所以要先把 1 號(hào)**的 Cache 對(duì)應(yīng)的 Cache Line 寫回到內(nèi)存，然后 2 號(hào)**再從內(nèi)存讀取 Cache Line 大小的數(shù)據(jù)到 Cache 中，最后把變量 B 修改到 2 號(hào)**的 Cache 中，并將狀態(tài)標(biāo)記為「已修改」?fàn)顟B(tài)。所以，可以發(fā)現(xiàn)如果 1 號(hào)和 2 號(hào) CPU **這樣持續(xù)交替的分別修改變量 A 和 B，就會(huì)重復(fù) ④ 和 ⑤ 這兩個(gè)步驟，Cache 并沒有起到緩存的效果，雖然變量 A 和 B 之間其實(shí)并沒有任何的關(guān)系，但是因?yàn)橥瑫r(shí)歸屬于一個(gè) Cache Line ，這個(gè) Cache Line 中的任意數(shù)據(jù)被修改后，都會(huì)相互影響，從而出現(xiàn) ④ 和 ⑤ 這兩個(gè)步驟。因此，這種因?yàn)槎鄠€(gè)線程同時(shí)讀寫同一個(gè) Cache Line 的不同變量時(shí)，而導(dǎo)致 CPU Cache 失效的現(xiàn)象稱為偽共享（False Sharing）。
2、避免偽共享的方法
因此，對(duì)于多個(gè)線程共享的熱點(diǎn)數(shù)據(jù)，即經(jīng)常會(huì)修改的數(shù)據(jù)，應(yīng)該避免這些數(shù)據(jù)剛好在同一個(gè) Cache Line 中，否則就會(huì)出現(xiàn)為偽共享的問題理解 CPU 是如何讀寫數(shù)據(jù)的前提，是要理解 CPU 的架構(gòu)，CPU 內(nèi)部的多個(gè) Cache + 外部的內(nèi)存和磁盤都就構(gòu)成了金字塔的存儲(chǔ)器結(jié)構(gòu)，在這個(gè)金字塔中，越往下，存儲(chǔ)器的容量就越大，但訪問速度就會(huì)小。CPU 讀寫數(shù)據(jù)的時(shí)候，并不是按一個(gè)一個(gè)字節(jié)為單位來進(jìn)行讀寫，而是以 CPU Line 大小為單位，CPU Line 大小一般是 64 個(gè)字節(jié)，也就意味著 CPU 讀寫數(shù)據(jù)的時(shí)候，每一次都是以 64 字節(jié)大小為一塊進(jìn)行操作。因此，如果我們操作的數(shù)據(jù)是數(shù)組，那么訪問數(shù)組元素的時(shí)候，按內(nèi)存分布的地址順序進(jìn)行訪問，這樣能充分利用到 Cache，程序的性能得到提升。但如果操作的數(shù)據(jù)不是數(shù)組，而是普通的變量，并在多核 CPU 的情況下，我們還需要避免 Cache Line 偽共享的問題。所謂的 Cache Line 偽共享問題就是，多個(gè)線程同時(shí)讀寫同一個(gè) Cache Line 的不同變量時(shí)，而導(dǎo)致 CPU Cache 失效的現(xiàn)象。那么對(duì)于多個(gè)線程共享的熱點(diǎn)數(shù)據(jù)，即經(jīng)常會(huì)修改的數(shù)據(jù)，應(yīng)該避免這些數(shù)據(jù)剛好在同一個(gè) Cache Line 中，避免的方式一般有 Cache Line 大小字節(jié)對(duì)齊，以及字節(jié)填充等方法。系統(tǒng)中需要運(yùn)行的多線程數(shù)一般都會(huì)大于 CPU **，這樣就會(huì)導(dǎo)致線程排隊(duì)等待 CPU，這可能會(huì)產(chǎn)生一定的延時(shí)，如果我們的任務(wù)對(duì)延時(shí)容忍度很低，則可以通過一些人為手段干預(yù) Linux 的默認(rèn)調(diào)度策略和**級(jí)。 吳江區(qū)芯博源電子商行專注于回收芯片,回收電容,回收IC等
