議與偽共享實(shí)戰(zhàn))
上一篇把Cache的基本組織、讀命中與缺失的路徑都梳理了一遍這篇繼續(xù)往下走聊寫路徑和一致性協(xié)議MESI。很多初學(xué)者在這里會明顯感覺到難度上了一個臺階讀路徑再復(fù)雜核心問題無非是“數(shù)據(jù)在不在Cache里、從哪一層取”但寫路徑要決策的東西突然變多——修改后的數(shù)據(jù)到底什么時候落主存寫缺失時要不要先把整個塊加載進(jìn)來更重要的問題是多核對同一個地址的副本各持己見時誰說了算這篇就圍繞寫策略和MESI展開用“問題是什么、為什么這么設(shè)計(jì)、工程上怎么用”的思路把知識點(diǎn)串成一條完整的邏輯鏈。寫這篇的前提是你已經(jīng)了解Cache的基本概念比如行、組、命中與缺失。如果還沒讀過上一篇建議先補(bǔ)上否則下面講寫分配、狀態(tài)轉(zhuǎn)換時會覺得缺了一層。適合的人群很明確搞多線程開發(fā)、高性能計(jì)算、底層系統(tǒng)性能優(yōu)化的同學(xué)以及所有想知道“MESI這四個字母到底在解決什么”的人。1. Cache寫策略先分清寫直達(dá)與寫回在爭什么1.1 寫直達(dá)Write Through每次寫都同步到主存寫直達(dá)的策略非常樸素?zé)o論寫命中還是寫缺失數(shù)據(jù)在更新Cache的同時也會同步寫到下一級存儲一路刷到主存。這樣主存里的數(shù)據(jù)永遠(yuǎn)是最新的任何其他設(shè)備直接讀主存即可不用關(guān)心Cache里是什么狀態(tài)。好處是簡單、可靠、實(shí)現(xiàn)成本低甚至不需要復(fù)雜的“臟位”管理——因?yàn)樗袛?shù)據(jù)都和主存一致根本不存在被修改過但沒落主存的塊。但代價(jià)也很直白每一次寫操作都要走內(nèi)存總線。在CPU寫吞吐量很高的場景下總線會成為瓶頸。想象一下一個變量在循環(huán)里被反復(fù)修改寫直達(dá)意味著每次修改都在向主存做一次全量寫入內(nèi)存訪問的延遲和功耗非常難看。我通常用記賬來類比寫直達(dá)像是每一筆支出都實(shí)時登記到總賬本賬永遠(yuǎn)是對的但每買一瓶水都要跑一趟財(cái)務(wù)室寫回則是先記在自己的小本上月底集中對賬。小本子就是Cache月底對賬就是替換時寫回主存。1.2 寫回Write Back先攢著替換時再同步寫回策略要求Cache行里額外維護(hù)一個臟位Dirty Bit表示這行數(shù)據(jù)被CPU修改過、和主存不一致。寫命中時只更新Cache不立即寫主存只有當(dāng)這個臟行被替換出去時才把整行寫回主存。寫回的核心優(yōu)勢在于利用局部性一個Cache行通常是64字節(jié)如果程序在短時間內(nèi)反復(fù)修改同一行內(nèi)的數(shù)據(jù)寫回策略只需要在最后把整個行寫回一次而寫直達(dá)等于每次都同步白白浪費(fèi)總線帶寬。這正是現(xiàn)代處理器普遍選擇寫回的原因——實(shí)測下來大多數(shù)程序?qū)ν粌?nèi)存區(qū)域的寫入會集中在某段時間內(nèi)寫回策略能顯著減少主存訪問次數(shù)。代價(jià)是什么一是硬件變復(fù)雜需要在狀態(tài)里區(qū)分“干凈行”和“臟行”二是主存中的數(shù)據(jù)不再一直是最新狀態(tài)如果其他設(shè)備比如DMA控制器直接讀主存可能讀到舊數(shù)據(jù)。工程里解決這個問題的辦法通常是額外的同步與Cache沖刷操作。1.3 寫分配與寫不分配寫缺失時才顯山露水寫命中時策略主要在“是否同步到主存”上做取舍。寫缺失時CPU要先決定另一件事要不要把這個缺失的塊加載進(jìn)Cache這就引出了寫分配Write Allocate和寫不分配Write No-Allocate。寫分配指的是寫缺失時先把對應(yīng)內(nèi)存塊加載到Cache然后再在Cache里完成寫入寫不分配則是直接在下一級存儲上執(zhí)行寫入不把塊加載進(jìn)來。這兩種策略通常會結(jié)合前面的命中策略使用常見搭配是寫回加寫分配寫直達(dá)加寫不分配。這背后的邏輯很合理。寫回已經(jīng)默認(rèn)數(shù)據(jù)讀進(jìn)Cache之后會被多次訪問那么寫缺失時把整個塊加載進(jìn)來后續(xù)對這個塊的讀寫都能命中收益大于加載開銷。而寫直達(dá)反正每次都要寫到主存用寫分配加載塊進(jìn)來的收益很低反而白白占用Cache容量所以寫直達(dá)更傾向搭配寫不分配。注意這不是絕對規(guī)則也有實(shí)現(xiàn)會使用寫回加寫不分配的組合但主流思路以上述搭配為主。策略組合寫命中行為寫缺失行為適用場景寫回 寫分配更新Cache標(biāo)記臟加載塊到Cache再更新主流處理器各級Cache寫直達(dá) 寫不分配更新Cache并同步主存直接在下一級寫入不加載塊早期簡單實(shí)現(xiàn)、部分寫緩沖場景寫回 寫不分配更新Cache標(biāo)記臟直接寫下一級不加載塊寫入量大但局部性弱的特殊流式場景1.4 寫緩沖Write Buffer與寫合并寫策略背后的加速器寫直達(dá)和寫回都存在一個共同問題寫操作不能無限等待主存或下一級Cache返回。為了不讓CPU停頓幾乎所有實(shí)現(xiàn)都會在寫路徑上插入一個寫緩沖Write Buffer。CPU把寫請求放進(jìn)緩沖后可以繼續(xù)執(zhí)行由緩沖異步把數(shù)據(jù)刷到下一級。寫緩沖還有一個衍生功能叫寫合并Write Combining。如果程序連續(xù)寫了相鄰的地址這些請求會在寫緩沖中合并成一個更大的事務(wù)。我舉個更直觀的例子往映射到顯存的地址連續(xù)寫入像素?cái)?shù)據(jù)如果每次寫4字節(jié)都單獨(dú)走一遍總線效率極低但有了寫合并幾十個連續(xù)寫請求可以合并為一次突發(fā)傳輸速度差距可以達(dá)到數(shù)倍甚至一個數(shù)量級。不過寫緩沖也帶來了亂序問題后續(xù)的讀操作可能先于緩沖中的寫操作完成導(dǎo)致程序觀測到“寫入還沒生效”的假象。這個問題在第5章詳細(xì)展開。這里先記住一點(diǎn)Cache本身是一致性問題的溫床寫緩沖又是另一層亂序來源兩者疊加才逼出了我們后面要聊的內(nèi)存屏障。2. 緩存一致性問題的根源與兩類協(xié)議框架2.1 單核沒這個問題多核就有了單核CPU中Cache和主存之間雖然也有多級層次但只有CPU一個訪問者不存在“兩個處理器看到同一數(shù)據(jù)的不同版本”這個問題。所有數(shù)據(jù)都是順序流經(jīng)各級存儲程序觀察到的結(jié)果不會因?yàn)镃ache的存在而出現(xiàn)分歧。多核則完全不同。兩個核各自擁有私有Cache卻共享同一份物理內(nèi)存。核A改了本地Cache中的一行數(shù)據(jù)核B如果在自己的Cache里保留著舊副本那么B讀到舊數(shù)據(jù)、主存里也還是舊數(shù)據(jù)程序就可能違反順序一致性。問題不再是個體緩存層的數(shù)據(jù)新鮮度而是多個緩存副本之間的相互可見性。這時候需要一套規(guī)則來約束所有Cache和總線或互聯(lián)網(wǎng)絡(luò)的交互讓所有核對同一地址的訪問結(jié)果達(dá)成共識。這套規(guī)則就是緩存一致性協(xié)議。2.2 寫無效與寫更新傳播寫入的兩種極端一致性協(xié)議要解決的第一個問題是當(dāng)某個核寫入數(shù)據(jù)時其他核的舊副本怎么辦業(yè)界有兩條路線。寫更新協(xié)議Write Update寫操作發(fā)生時把新數(shù)據(jù)廣播給所有緩存了這個行的核讓它們的副本同步更新。思路很簡單但有一個致命問題——總線流量會被廣播操作迅速打爆。哪怕CPU只寫一個字節(jié)也得把整條數(shù)據(jù)發(fā)到所有位置。多核規(guī)模越大這個方案越不可行。寫無效協(xié)議Write Invalidate寫操作發(fā)生時先向其他核發(fā)送無效通知讓它們的副本狀態(tài)變?yōu)镮nvalid而不是直接更新數(shù)據(jù)。需要讀時再通過總線重新拉取最新數(shù)據(jù)。雖然一次寫入也需要廣播但廣播的只是一個無效標(biāo)記數(shù)據(jù)只在總線上傳輸一次流量遠(yuǎn)小于寫更新。這也是MESI一類方案的基礎(chǔ)直覺不追求所有副本實(shí)時同步而是保證舊副本被“作廢”讓最先使用該數(shù)據(jù)的核自己把最新數(shù)據(jù)拉過去。2.3 總線嗅探與目錄怎么知道該通知誰在確定給其他核發(fā)通知后還需要解決“通知誰”的問題。這里有兩類架構(gòu)?？偩€嗅探Bus Snooping設(shè)想所有處理器共享一條總線。每個Cache控制器都監(jiān)聽總線上的所有事務(wù)如果發(fā)現(xiàn)總線上有人在讀寫自己不關(guān)心的地址則無視如果發(fā)現(xiàn)這個地址自己的Cache里有副本則根據(jù)協(xié)議規(guī)則做出響應(yīng)。優(yōu)點(diǎn)是簡單、天然有序——總線本身就是串行的。缺點(diǎn)是廣播式通信核數(shù)越多、總線越擁擠可擴(kuò)展性差。目錄協(xié)議Directory-based則是換一種思路維護(hù)一個目錄結(jié)構(gòu)記錄每個緩存行被哪些核共享、處于什么狀態(tài)。某個核想寫一行缺失的數(shù)據(jù)時先查詢目錄只向持有該行副本的核發(fā)送失效消息而不是向所有人廣播。這樣避免了無差別廣播適合插槽數(shù)量多、跨片通信昂貴的大規(guī)模NUMA體系結(jié)構(gòu)。目錄協(xié)議本質(zhì)上仍然是MESI這類狀態(tài)機(jī)的實(shí)現(xiàn)框架區(qū)別只在于控制消息的分發(fā)方式。后面第4章會再展開。3. MESI狀態(tài)機(jī)逐狀態(tài)拆解手把手推演一次完整讀寫3.1 四種狀態(tài)的含義M、E、S、I分別代表什么MESI是Modified、Exclusive、Shared、Invalid四個狀態(tài)的縮寫分別描述一個緩存行在這顆核心私有Cache中的身份狀態(tài)含義主存副本是否最新副本數(shù)目ModifiedM本核獨(dú)占且已修改否Cache中的是最新僅本核一份ExclusiveE本核獨(dú)占且與主存一致是僅本核一份SharedS多核共享與主存一致是可以有多個核InvalidI該行無效或不在本核Cache中不關(guān)心無有效副本M和E的差異值得多琢磨。兩者都是“本核獨(dú)占”區(qū)別在于M狀態(tài)的數(shù)據(jù)已經(jīng)被本核修改過、主存滯后而E狀態(tài)的數(shù)據(jù)和主存完全一致。正因?yàn)镋狀態(tài)下沒有其他核持有副本本核要寫這行數(shù)據(jù)時可以直接從E轉(zhuǎn)到M而無需在總線上發(fā)送任何通知——因?yàn)椴淮嬖谛枰鲝U的副本。這個細(xì)節(jié)是MESI優(yōu)于樸素一致性方案的性能關(guān)鍵。S狀態(tài)表示可能有多個核心同時持有同一行的副本并且大家看到的都是和主存一致的數(shù)據(jù)。任何核心想寫S狀態(tài)的行必須先向其他核發(fā)送升級請求把它們的狀態(tài)置為I然后自己變成M。3.2 總線消息MESI的“語言”狀態(tài)轉(zhuǎn)換不是憑空發(fā)生的它依靠以下總線消息驅(qū)動。不同處理器實(shí)現(xiàn)對消息的命名略有差異但高度對應(yīng)以下五類總線消息含義引發(fā)場景BusRd讀請求本核讀缺失時發(fā)出BusRdX讀獨(dú)占請求后續(xù)要寫本核寫缺失時發(fā)出BusUpgrade升級請求不拉數(shù)據(jù)本核持S/E狀態(tài)想寫時需要作廢其他副本Flush將臟數(shù)據(jù)寫回M狀態(tài)行響應(yīng)遠(yuǎn)端讀/寫請求時FlushOpt可選地轉(zhuǎn)發(fā)數(shù)據(jù)某些優(yōu)化變體中M狀態(tài)行直接把最新數(shù)據(jù)轉(zhuǎn)發(fā)給請求方為什么存在BusUpgrade這種不拉數(shù)據(jù)的消息因?yàn)镃PU要寫的行已經(jīng)在自己的Cache中只是處于Shared狀態(tài)。它不需要別人再給自己傳一份數(shù)據(jù)只需要通知其他持有副本的核你們手里的副本作廢吧。這樣就不必把數(shù)據(jù)從內(nèi)存再讀一遍大大節(jié)省了延遲。3.3 狀態(tài)轉(zhuǎn)換表一句話記住每個轉(zhuǎn)移下面列一張簡化的狀態(tài)轉(zhuǎn)換表聚焦事件發(fā)生時的主要動作不需要背表重點(diǎn)理解每類事件的觸發(fā)條件當(dāng)前狀態(tài)事件目標(biāo)狀態(tài)核心動作I本地讀BusRdE 或 S無其他副本則到E有則到SI本地寫B(tài)usRdXM作廢其他核副本E本地讀E無總線操作E本地寫B(tài)usUpgradeM無其他副本需要作廢故無廣播S本地讀S無總線操作S本地寫B(tài)usUpgradeM廣播作廢其他副本M本地讀/寫M無總線操作E遠(yuǎn)端讀S自己降級為共享S遠(yuǎn)端讀S保持共享即可M遠(yuǎn)端讀S需要沖刷臟數(shù)據(jù)到主存或傳給請求方M遠(yuǎn)端寫I沖刷后無效S遠(yuǎn)端寫I直接無效E遠(yuǎn)端寫I直接無效一個容易忽略的細(xì)節(jié)是M狀態(tài)行被遠(yuǎn)端讀請求擊中時不一定要同時寫主存。更高效的做法是直接把最新數(shù)據(jù)傳給請求方FlushOpt由請求方更新自己的Cache同時保留M狀態(tài)核的數(shù)據(jù)并降級為S。這樣避免了不必要的內(nèi)存訪問是后續(xù)MOESI/Owned思想的雛形。3.4 兩個完整推演從場景角度理解狀態(tài)機(jī)場景一核A寫數(shù)據(jù)核B隨后讀初始狀態(tài)核A持I核B持S。核A要寫一個變量發(fā)出BusRdX請求。核B收到這個請求后發(fā)現(xiàn)自己持有的副本是Shared狀態(tài)于是置為Invalid并響應(yīng)總線。核A拿到獨(dú)占權(quán)把數(shù)據(jù)變?yōu)镸odified完成寫入。隨后核B要讀這個變量發(fā)BusRd請求。此時總線上的其他核中核A持有Modified副本它會感知并應(yīng)答把自己的臟數(shù)據(jù)沖刷到總線同時狀態(tài)降級為Shared。核B獲得數(shù)據(jù)后也進(jìn)入Shared主存得到?jīng)_刷后數(shù)據(jù)。整個過程沒有讓核B讀到舊值。場景二兩個核心同時持有S副本其中一個要寫核A和核B都緩存了同一行都處于Shared狀態(tài)。核A執(zhí)行寫操作發(fā)出BusUpgrade請求并不要求數(shù)據(jù)本身——因?yàn)楹薃已經(jīng)持有數(shù)據(jù)?？偩€上核B收到升級請求后把自己的副本置為Invalid。核A收到所有失效完成信號后狀態(tài)由S轉(zhuǎn)為M接著正常寫數(shù)據(jù)。這個流程比BusRdX少了數(shù)據(jù)加載環(huán)節(jié)所以寫命中Shared狀態(tài)的延遲很低。3.5 偽共享開始冒頭狀態(tài)機(jī)里藏著的性能炸彈從上面的場景二能嗅到一絲不對勁核A只是修改自己私有的一小片數(shù)據(jù)卻會把核B整個緩存行作廢。如果核B也恰好頻繁修改另一片位于同一行內(nèi)的獨(dú)立數(shù)據(jù)就會出現(xiàn)兩個核完全沒有共享邏輯數(shù)據(jù)卻在一致協(xié)議層面反復(fù)競爭同一個行的情況。這就是偽共享False Sharing第4.3節(jié)會專門解決它。這里先記住一點(diǎn)一致性協(xié)議操作的粒度是整個緩存行而不是行內(nèi)的一個字節(jié)。4. 從MESI到工程實(shí)踐變體協(xié)議與偽共享排查4.1 MOESI與MESIFMESI的兩種重要改良純MESI有一個繞不開的性能痛點(diǎn)M狀態(tài)的數(shù)據(jù)要響應(yīng)其他核的讀請求時必須先寫回主存或通過總線轉(zhuǎn)發(fā)而這兩種操作都會帶來額外延遲。MOESI增加了一個OwnedO狀態(tài)允許數(shù)據(jù)在擁有者與主存之間“名不正言不順”地存在O狀態(tài)行保存最新數(shù)據(jù)但主存副本也允許是次新的這樣其他核讀數(shù)據(jù)時可以由O狀態(tài)核直接轉(zhuǎn)發(fā)不必先把數(shù)據(jù)寫回主存。減少一次內(nèi)存訪問對多寫少讀場景非常友好。MESIF則引入ForwardF狀態(tài)用來解決另一個問題當(dāng)多個核同時處于Shared狀態(tài)時如果有某個缺失核發(fā)出讀請求理論上所有S狀態(tài)核都可以響應(yīng)但總線上有多個響應(yīng)者就會造成混亂。F狀態(tài)指定唯一一個“轉(zhuǎn)發(fā)責(zé)任人”只有它負(fù)責(zé)把數(shù)據(jù)發(fā)給請求方其他核保持安靜。這能顯著降低總線監(jiān)聽和響應(yīng)開銷在某些多核互聯(lián)設(shè)計(jì)中較為常見。這些變體并不改變MESI的基本狀態(tài)框架它們只是在特定工程場景下做增補(bǔ)。理解MESI之后再去看MOESI、MESIF會發(fā)現(xiàn)邏輯非常順暢。4.2 目錄協(xié)議在大規(guī)模系統(tǒng)里落地MESI前面講過總線嗅探是廣播式的而目錄協(xié)議把“全喊一嗓子”改為“按名單點(diǎn)名”。目錄項(xiàng)里保存著每個緩存行的狀態(tài)以及持有該行的核心列表。以寫請求為例目錄控制器查到列表只給列表上的核發(fā)無效消息而不是廣播到所有節(jié)點(diǎn)。這樣的代價(jià)是每次內(nèi)存訪問都要先查目錄目錄成為熱點(diǎn)而且從請求發(fā)起到目錄應(yīng)答再到失效完成鏈路比總線嗅探長。但在多路處理器的NUMA系統(tǒng)中跨節(jié)點(diǎn)的消息比片內(nèi)緩存一致性總線昂貴得多廣播式方案通常無法擴(kuò)展到幾十個核心以上。工程上常見做法是片內(nèi)用總線嗅探或較短的一致域跨片用目錄協(xié)議整體上對操作系統(tǒng)和應(yīng)用程序仍然是透明一致的。4.3 偽共享再深挖為什么說它是MESI最隱蔽的敵人這里必須展開講因?yàn)閭喂蚕硎荕ESI對性能影響最直接的體現(xiàn)。假設(shè)有兩個線程分別和兩個不同的int變量交互這兩個int在源碼中的地址恰好相鄰?，F(xiàn)代Cache行大小普遍是64字節(jié)兩個int落在同一行內(nèi)。于是線程A每次寫自己的intMESI都會讓線程B持有的整個行失效線程B再訪問自己的int時需要重新拉取這行數(shù)據(jù)盡管那個int根本沒有被線程A碰過。從結(jié)果看兩個線程實(shí)際是在交替讀寫同一行產(chǎn)生大量的總線流量、緩存缺失和延遲等待。最可氣的是邏輯上兩個變量完全無關(guān)問題完全出在內(nèi)存布局上。我見過一個多線程累加計(jì)數(shù)器的Benchmark線程數(shù)加到16時偽共享版本的耗時可以比消除偽共享版本高出三到五倍而功能上兩者完全等價(jià)。檢查代碼時你未必能直接看到偽共享因?yàn)樗淮嬖跀?shù)據(jù)競爭或邏輯錯誤程序輸出完全正確只有性能曲線會異常。這也是這類問題最坑的地方——它不會讓程序出錯只會讓程序莫名變慢。4.4 實(shí)測偽共享的一個參考做法寫一段示意邏輯來說明如何測量和定位struct counter { int value; }; struct counter counters[4];四個核分別更新counters[0].value、counters[1].value……如果這些struct counter在數(shù)組里是連續(xù)挨著的多個核就會互相作廢整行。把結(jié)構(gòu)體改成struct counter { int value; char padding[60]; // 湊夠64字節(jié)的Cache行 };再跑一次同樣負(fù)載時間差異會非常直觀。實(shí)際定位時用性能分析工具監(jiān)控cache-misses和總線周期數(shù)通常能看到cache-miss率在偽共享版本上顯著偏高。注意不同平臺的Cache行大小可能不同x86主流桌面和服務(wù)器目前普遍是64字節(jié)有些ARM平臺是64字節(jié)也有個別平臺是128字節(jié)。如果做跨平臺優(yōu)化建議用運(yùn)行時讀取或編譯期探測不要硬編碼。5. 從MESI到內(nèi)存模型寫緩沖與內(nèi)存屏障才是最后一環(huán)5.1 MESI保證了一致性但沒有保證順序很多初學(xué)者會有一種錯覺既然MESI保證所有核看到的緩存行最終一致那程序里的普通變量讀寫是不是天然就是順序一致的呢答案是否定的。MESI只負(fù)責(zé)緩存行副本之間的相互同步但它沒有約束CPU執(zhí)行指令的亂序能力也沒有消除寫緩沖帶來的延后寫入問題。一個指令序列在實(shí)際CPU上可以被重排或者說在另一個核的視角下觀察到的是與程序編寫順序不同的效果。MESI保證的是“當(dāng)我讀到某個地址的最新版本時我讀到的確實(shí)是某個全局最新版本”但無法保證“我讀到版本A時必然也看到了版本A之前的所有寫入”。后者屬于內(nèi)存模型問題。5.2 store buffer引發(fā)的經(jīng)典亂序現(xiàn)象典型例子是兩個線程通過共享狀態(tài)變量通信線程1設(shè)置data 1設(shè)置flag 1線程2循環(huán)等待flag 1然后讀取data直覺上線程2看到flag 1時data應(yīng)該已經(jīng)被設(shè)置為1。但在缺乏屏障的情況下線程2可能讀到flag 1但data 0。原因是線程1的兩個store可能被CPU重排或者data 1還在store buffer中排隊(duì)而flag 1已經(jīng)刷出。MESI確實(shí)保證flag對應(yīng)的緩存行一旦變成Modified其他核會看到這個值但它管不了flag和data這兩個不同地址的寫入順序。在并發(fā)編程里這種“可見順序”需要用內(nèi)存屏障或帶屏障語義的原語比如CAS、原子交換來強(qiáng)制。5.3 volatile與內(nèi)存屏障在MESI體系里的定位現(xiàn)在可以比較完整地理解volatile的作用它告訴編譯器和CPU該變量的訪問不能被重排到某些邊界之外必須從內(nèi)存中讀取最新值并且寫入要及時對其他線程可見。物理層面MESI保證了緩存副本會因總線消息而失效邏輯層面需要屏障指令防止CPU和編譯器打亂訪問順序。工程中的常見做法是不加修飾的共享變量僅用于單線程或已知同步保護(hù)的場景跨線程同步用鎖、原子變量等帶有獲取/釋放語義的原語。直接裸寫普通變量volatile來構(gòu)建鎖幾乎一定會踩到內(nèi)存序的坑。記住一條經(jīng)驗(yàn)MESI解決的是緩存一致問題內(nèi)存屏障解決的是順序一致問題兩者配合才能構(gòu)成并發(fā)正確性的地基絕不是同一件事。6. 實(shí)戰(zhàn)排查記錄幾個與Cache相關(guān)的經(jīng)典問題6.1 多線程程序隨線程數(shù)增加反而變慢的排查思路這類問題出現(xiàn)時我通常按下面順序走一遍先跑性能分析工具觀察cache-misses是否異常升高、總線周期占比是否過高。檢查共享變量在內(nèi)存中的布局是不是多個線程頻繁修改的地址落在同一個緩存行內(nèi)。檢查鎖競爭如果多個線程在同一把鎖上忙等鎖對象的緩存行會成為一個天然的串行化點(diǎn)。配合核心負(fù)載與親和性設(shè)置確認(rèn)線程是否真的在計(jì)劃運(yùn)行的核上執(zhí)行。前兩步最常見也是偽共享的典型征兆。如果確認(rèn)是偽共享對齊與padding即可解決不用改任何同步邏輯。6.2 幾個容易忽略的工程細(xì)節(jié)malloc分配的堆對象并非全都孤立連續(xù)分配的小對象經(jīng)常落在同一緩存行。用對齊分配或把熱數(shù)據(jù)放進(jìn)獨(dú)立結(jié)構(gòu)體能有效減少這種沖突。原子變量的操作并不自動消除偽共享。兩個線程各自對同一個行上的不同原子變量做無鎖更新依然會被MESI拖住。大多數(shù)現(xiàn)代平臺中Cache行包含了字節(jié)、字等所有粒度的一致狀態(tài)控制所以“我只改了1個字節(jié)為什么需要淘汰整個行”的疑問是對的但這正是硬件的實(shí)現(xiàn)限制。對齊不是銀彈。過度padding會增加內(nèi)存占用、降低容量命中率只應(yīng)在壓測確認(rèn)熱點(diǎn)后再使用。跨平臺的Cache行大小、一致性協(xié)議細(xì)節(jié)可能存在差異把優(yōu)化封裝在平臺適配層里不要直接散落在業(yè)務(wù)代碼各處。6.3 對一致性知識的落地理解嚴(yán)格來說普通應(yīng)用代碼開發(fā)者不需要直接操作MESI狀態(tài)但它決定了你寫的并發(fā)程序性能好不好、bug難不難查。當(dāng)你理解了寫回、寫無效、偽共享、store buffer這些概念之后再看很多性能優(yōu)化技巧比如無鎖隊(duì)列為什么用緩存行填充、單寫者多讀者為什么比多寫者更快、為什么某些共享計(jì)數(shù)器需要分批累加會豁然開朗。我在實(shí)際工作中有一個體會可以先在紙上推導(dǎo)一遍MESI狀態(tài)轉(zhuǎn)換再寫一個簡單的多線程Benchmark驗(yàn)證偽共享影響把這個“理論到實(shí)驗(yàn)”的過程走通之后這些知識基本就很難忘了。最后再分享一個我自己踩過的坑有一階段在做多線程統(tǒng)計(jì)模塊時把每個線程的計(jì)數(shù)結(jié)果挨個放在一個共享結(jié)構(gòu)體里結(jié)果隨著線程數(shù)增加耗時不但沒下降反而節(jié)節(jié)攀升。排查了很久才發(fā)現(xiàn)是同一個緩存行內(nèi)兩個相鄰計(jì)數(shù)器在互相作廢加了一行padding后性能立刻恢復(fù)。從那以后我對每個多線程熱路徑上的共享數(shù)據(jù)都默認(rèn)帶上了“緩存行邊界”這層意識。Cache相關(guān)的坑就是這樣你不知道時它讓你欲哭無淚你摸清規(guī)律后它就會變成手里最順手的一把性能優(yōu)化利器。 多核緩存一致性基石：寫策略、MESI協(xié)議與偽共享實(shí)戰(zhàn)
上一篇把Cache的基本組織、讀命中與缺失的路徑都梳理了一遍這篇繼續(xù)往下走聊寫路徑和一致性協(xié)議MESI。很多初學(xué)者在這里會明顯感覺到難度上了一個臺階讀路徑再復(fù)雜核心問題無非是“數(shù)據(jù)在不在Cache里、從哪一層取”但寫路徑要決策的東西突然變多——修改后的數(shù)據(jù)到底什么時候落主存寫缺失時要不要先把整個塊加載進(jìn)來更重要的問題是多核對同一個地址的副本各持己見時誰說了算這篇就圍繞寫策略和MESI展開用“問題是什么、為什么這么設(shè)計(jì)、工程上怎么用”的思路把知識點(diǎn)串成一條完整的邏輯鏈。寫這篇的前提是你已經(jīng)了解Cache的基本概念比如行、組、命中與缺失。如果還沒讀過上一篇建議先補(bǔ)上否則下面講寫分配、狀態(tài)轉(zhuǎn)換時會覺得缺了一層。適合的人群很明確搞多線程開發(fā)、高性能計(jì)算、底層系統(tǒng)性能優(yōu)化的同學(xué)以及所有想知道“MESI這四個字母到底在解決什么”的人。1. Cache寫策略先分清寫直達(dá)與寫回在爭什么1.1 寫直達(dá)Write Through每次寫都同步到主存寫直達(dá)的策略非常樸素?zé)o論寫命中還是寫缺失數(shù)據(jù)在更新Cache的同時也會同步寫到下一級存儲一路刷到主存。這樣主存里的數(shù)據(jù)永遠(yuǎn)是最新的任何其他設(shè)備直接讀主存即可不用關(guān)心Cache里是什么狀態(tài)。好處是簡單、可靠、實(shí)現(xiàn)成本低甚至不需要復(fù)雜的“臟位”管理——因?yàn)樗袛?shù)據(jù)都和主存一致根本不存在被修改過但沒落主存的塊。但代價(jià)也很直白每一次寫操作都要走內(nèi)存總線。在CPU寫吞吐量很高的場景下總線會成為瓶頸。想象一下一個變量在循環(huán)里被反復(fù)修改寫直達(dá)意味著每次修改都在向主存做一次全量寫入內(nèi)存訪問的延遲和功耗非常難看。我通常用記賬來類比寫直達(dá)像是每一筆支出都實(shí)時登記到總賬本賬永遠(yuǎn)是對的但每買一瓶水都要跑一趟財(cái)務(wù)室寫回則是先記在自己的小本上月底集中對賬。小本子就是Cache月底對賬就是替換時寫回主存。1.2 寫回Write Back先攢著替換時再同步寫回策略要求Cache行里額外維護(hù)一個臟位Dirty Bit表示這行數(shù)據(jù)被CPU修改過、和主存不一致。寫命中時只更新Cache不立即寫主存只有當(dāng)這個臟行被替換出去時才把整行寫回主存。寫回的核心優(yōu)勢在于利用局部性一個Cache行通常是64字節(jié)如果程序在短時間內(nèi)反復(fù)修改同一行內(nèi)的數(shù)據(jù)寫回策略只需要在最后把整個行寫回一次而寫直達(dá)等于每次都同步白白浪費(fèi)總線帶寬。這正是現(xiàn)代處理器普遍選擇寫回的原因——實(shí)測下來大多數(shù)程序?qū)ν粌?nèi)存區(qū)域的寫入會集中在某段時間內(nèi)寫回策略能顯著減少主存訪問次數(shù)。代價(jià)是什么一是硬件變復(fù)雜需要在狀態(tài)里區(qū)分“干凈行”和“臟行”二是主存中的數(shù)據(jù)不再一直是最新狀態(tài)如果其他設(shè)備比如DMA控制器直接讀主存可能讀到舊數(shù)據(jù)。工程里解決這個問題的辦法通常是額外的同步與Cache沖刷操作。1.3 寫分配與寫不分配寫缺失時才顯山露水寫命中時策略主要在“是否同步到主存”上做取舍。寫缺失時CPU要先決定另一件事要不要把這個缺失的塊加載進(jìn)Cache這就引出了寫分配Write Allocate和寫不分配Write No-Allocate。寫分配指的是寫缺失時先把對應(yīng)內(nèi)存塊加載到Cache然后再在Cache里完成寫入寫不分配則是直接在下一級存儲上執(zhí)行寫入不把塊加載進(jìn)來。這兩種策略通常會結(jié)合前面的命中策略使用常見搭配是寫回加寫分配寫直達(dá)加寫不分配。這背后的邏輯很合理。寫回已經(jīng)默認(rèn)數(shù)據(jù)讀進(jìn)Cache之后會被多次訪問那么寫缺失時把整個塊加載進(jìn)來后續(xù)對這個塊的讀寫都能命中收益大于加載開銷。而寫直達(dá)反正每次都要寫到主存用寫分配加載塊進(jìn)來的收益很低反而白白占用Cache容量所以寫直達(dá)更傾向搭配寫不分配。注意這不是絕對規(guī)則也有實(shí)現(xiàn)會使用寫回加寫不分配的組合但主流思路以上述搭配為主。策略組合寫命中行為寫缺失行為適用場景寫回 寫分配更新Cache標(biāo)記臟加載塊到Cache再更新主流處理器各級Cache寫直達(dá) 寫不分配更新Cache并同步主存直接在下一級寫入不加載塊早期簡單實(shí)現(xiàn)、部分寫緩沖場景寫回 寫不分配更新Cache標(biāo)記臟直接寫下一級不加載塊寫入量大但局部性弱的特殊流式場景1.4 寫緩沖Write Buffer與寫合并寫策略背后的加速器寫直達(dá)和寫回都存在一個共同問題寫操作不能無限等待主存或下一級Cache返回。為了不讓CPU停頓幾乎所有實(shí)現(xiàn)都會在寫路徑上插入一個寫緩沖Write Buffer。CPU把寫請求放進(jìn)緩沖后可以繼續(xù)執(zhí)行由緩沖異步把數(shù)據(jù)刷到下一級。寫緩沖還有一個衍生功能叫寫合并Write Combining。如果程序連續(xù)寫了相鄰的地址這些請求會在寫緩沖中合并成一個更大的事務(wù)。我舉個更直觀的例子往映射到顯存的地址連續(xù)寫入像素?cái)?shù)據(jù)如果每次寫4字節(jié)都單獨(dú)走一遍總線效率極低但有了寫合并幾十個連續(xù)寫請求可以合并為一次突發(fā)傳輸速度差距可以達(dá)到數(shù)倍甚至一個數(shù)量級。不過寫緩沖也帶來了亂序問題后續(xù)的讀操作可能先于緩沖中的寫操作完成導(dǎo)致程序觀測到“寫入還沒生效”的假象。這個問題在第5章詳細(xì)展開。這里先記住一點(diǎn)Cache本身是一致性問題的溫床寫緩沖又是另一層亂序來源兩者疊加才逼出了我們后面要聊的內(nèi)存屏障。2. 緩存一致性問題的根源與兩類協(xié)議框架2.1 單核沒這個問題多核就有了單核CPU中Cache和主存之間雖然也有多級層次但只有CPU一個訪問者不存在“兩個處理器看到同一數(shù)據(jù)的不同版本”這個問題。所有數(shù)據(jù)都是順序流經(jīng)各級存儲程序觀察到的結(jié)果不會因?yàn)镃ache的存在而出現(xiàn)分歧。多核則完全不同。兩個核各自擁有私有Cache卻共享同一份物理內(nèi)存。核A改了本地Cache中的一行數(shù)據(jù)核B如果在自己的Cache里保留著舊副本那么B讀到舊數(shù)據(jù)、主存里也還是舊數(shù)據(jù)程序就可能違反順序一致性。問題不再是個體緩存層的數(shù)據(jù)新鮮度而是多個緩存副本之間的相互可見性。這時候需要一套規(guī)則來約束所有Cache和總線或互聯(lián)網(wǎng)絡(luò)的交互讓所有核對同一地址的訪問結(jié)果達(dá)成共識。這套規(guī)則就是緩存一致性協(xié)議。2.2 寫無效與寫更新傳播寫入的兩種極端一致性協(xié)議要解決的第一個問題是當(dāng)某個核寫入數(shù)據(jù)時其他核的舊副本怎么辦業(yè)界有兩條路線。寫更新協(xié)議Write Update寫操作發(fā)生時把新數(shù)據(jù)廣播給所有緩存了這個行的核讓它們的副本同步更新。思路很簡單但有一個致命問題——總線流量會被廣播操作迅速打爆。哪怕CPU只寫一個字節(jié)也得把整條數(shù)據(jù)發(fā)到所有位置。多核規(guī)模越大這個方案越不可行。寫無效協(xié)議Write Invalidate寫操作發(fā)生時先向其他核發(fā)送無效通知讓它們的副本狀態(tài)變?yōu)镮nvalid而不是直接更新數(shù)據(jù)。需要讀時再通過總線重新拉取最新數(shù)據(jù)。雖然一次寫入也需要廣播但廣播的只是一個無效標(biāo)記數(shù)據(jù)只在總線上傳輸一次流量遠(yuǎn)小于寫更新。這也是MESI一類方案的基礎(chǔ)直覺不追求所有副本實(shí)時同步而是保證舊副本被“作廢”讓最先使用該數(shù)據(jù)的核自己把最新數(shù)據(jù)拉過去。2.3 總線嗅探與目錄怎么知道該通知誰在確定給其他核發(fā)通知后還需要解決“通知誰”的問題。這里有兩類架構(gòu)?？偩€嗅探Bus Snooping設(shè)想所有處理器共享一條總線。每個Cache控制器都監(jiān)聽總線上的所有事務(wù)如果發(fā)現(xiàn)總線上有人在讀寫自己不關(guān)心的地址則無視如果發(fā)現(xiàn)這個地址自己的Cache里有副本則根據(jù)協(xié)議規(guī)則做出響應(yīng)。優(yōu)點(diǎn)是簡單、天然有序——總線本身就是串行的。缺點(diǎn)是廣播式通信核數(shù)越多、總線越擁擠可擴(kuò)展性差。目錄協(xié)議Directory-based則是換一種思路維護(hù)一個目錄結(jié)構(gòu)記錄每個緩存行被哪些核共享、處于什么狀態(tài)。某個核想寫一行缺失的數(shù)據(jù)時先查詢目錄只向持有該行副本的核發(fā)送失效消息而不是向所有人廣播。這樣避免了無差別廣播適合插槽數(shù)量多、跨片通信昂貴的大規(guī)模NUMA體系結(jié)構(gòu)。目錄協(xié)議本質(zhì)上仍然是MESI這類狀態(tài)機(jī)的實(shí)現(xiàn)框架區(qū)別只在于控制消息的分發(fā)方式。后面第4章會再展開。3. MESI狀態(tài)機(jī)逐狀態(tài)拆解手把手推演一次完整讀寫3.1 四種狀態(tài)的含義M、E、S、I分別代表什么MESI是Modified、Exclusive、Shared、Invalid四個狀態(tài)的縮寫分別描述一個緩存行在這顆核心私有Cache中的身份狀態(tài)含義主存副本是否最新副本數(shù)目ModifiedM本核獨(dú)占且已修改否Cache中的是最新僅本核一份ExclusiveE本核獨(dú)占且與主存一致是僅本核一份SharedS多核共享與主存一致是可以有多個核InvalidI該行無效或不在本核Cache中不關(guān)心無有效副本M和E的差異值得多琢磨。兩者都是“本核獨(dú)占”區(qū)別在于M狀態(tài)的數(shù)據(jù)已經(jīng)被本核修改過、主存滯后而E狀態(tài)的數(shù)據(jù)和主存完全一致。正因?yàn)镋狀態(tài)下沒有其他核持有副本本核要寫這行數(shù)據(jù)時可以直接從E轉(zhuǎn)到M而無需在總線上發(fā)送任何通知——因?yàn)椴淮嬖谛枰鲝U的副本。這個細(xì)節(jié)是MESI優(yōu)于樸素一致性方案的性能關(guān)鍵。S狀態(tài)表示可能有多個核心同時持有同一行的副本并且大家看到的都是和主存一致的數(shù)據(jù)。任何核心想寫S狀態(tài)的行必須先向其他核發(fā)送升級請求把它們的狀態(tài)置為I然后自己變成M。3.2 總線消息MESI的“語言”狀態(tài)轉(zhuǎn)換不是憑空發(fā)生的它依靠以下總線消息驅(qū)動。不同處理器實(shí)現(xiàn)對消息的命名略有差異但高度對應(yīng)以下五類總線消息含義引發(fā)場景BusRd讀請求本核讀缺失時發(fā)出BusRdX讀獨(dú)占請求后續(xù)要寫本核寫缺失時發(fā)出BusUpgrade升級請求不拉數(shù)據(jù)本核持S/E狀態(tài)想寫時需要作廢其他副本Flush將臟數(shù)據(jù)寫回M狀態(tài)行響應(yīng)遠(yuǎn)端讀/寫請求時FlushOpt可選地轉(zhuǎn)發(fā)數(shù)據(jù)某些優(yōu)化變體中M狀態(tài)行直接把最新數(shù)據(jù)轉(zhuǎn)發(fā)給請求方為什么存在BusUpgrade這種不拉數(shù)據(jù)的消息因?yàn)镃PU要寫的行已經(jīng)在自己的Cache中只是處于Shared狀態(tài)。它不需要別人再給自己傳一份數(shù)據(jù)只需要通知其他持有副本的核你們手里的副本作廢吧。這樣就不必把數(shù)據(jù)從內(nèi)存再讀一遍大大節(jié)省了延遲。3.3 狀態(tài)轉(zhuǎn)換表一句話記住每個轉(zhuǎn)移下面列一張簡化的狀態(tài)轉(zhuǎn)換表聚焦事件發(fā)生時的主要動作不需要背表重點(diǎn)理解每類事件的觸發(fā)條件當(dāng)前狀態(tài)事件目標(biāo)狀態(tài)核心動作I本地讀BusRdE 或 S無其他副本則到E有則到SI本地寫B(tài)usRdXM作廢其他核副本E本地讀E無總線操作E本地寫B(tài)usUpgradeM無其他副本需要作廢故無廣播S本地讀S無總線操作S本地寫B(tài)usUpgradeM廣播作廢其他副本M本地讀/寫M無總線操作E遠(yuǎn)端讀S自己降級為共享S遠(yuǎn)端讀S保持共享即可M遠(yuǎn)端讀S需要沖刷臟數(shù)據(jù)到主存或傳給請求方M遠(yuǎn)端寫I沖刷后無效S遠(yuǎn)端寫I直接無效E遠(yuǎn)端寫I直接無效一個容易忽略的細(xì)節(jié)是M狀態(tài)行被遠(yuǎn)端讀請求擊中時不一定要同時寫主存。更高效的做法是直接把最新數(shù)據(jù)傳給請求方FlushOpt由請求方更新自己的Cache同時保留M狀態(tài)核的數(shù)據(jù)并降級為S。這樣避免了不必要的內(nèi)存訪問是后續(xù)MOESI/Owned思想的雛形。3.4 兩個完整推演從場景角度理解狀態(tài)機(jī)場景一核A寫數(shù)據(jù)核B隨后讀初始狀態(tài)核A持I核B持S。核A要寫一個變量發(fā)出BusRdX請求。核B收到這個請求后發(fā)現(xiàn)自己持有的副本是Shared狀態(tài)于是置為Invalid并響應(yīng)總線。核A拿到獨(dú)占權(quán)把數(shù)據(jù)變?yōu)镸odified完成寫入。隨后核B要讀這個變量發(fā)BusRd請求。此時總線上的其他核中核A持有Modified副本它會感知并應(yīng)答把自己的臟數(shù)據(jù)沖刷到總線同時狀態(tài)降級為Shared。核B獲得數(shù)據(jù)后也進(jìn)入Shared主存得到?jīng)_刷后數(shù)據(jù)。整個過程沒有讓核B讀到舊值。場景二兩個核心同時持有S副本其中一個要寫核A和核B都緩存了同一行都處于Shared狀態(tài)。核A執(zhí)行寫操作發(fā)出BusUpgrade請求并不要求數(shù)據(jù)本身——因?yàn)楹薃已經(jīng)持有數(shù)據(jù)?？偩€上核B收到升級請求后把自己的副本置為Invalid。核A收到所有失效完成信號后狀態(tài)由S轉(zhuǎn)為M接著正常寫數(shù)據(jù)。這個流程比BusRdX少了數(shù)據(jù)加載環(huán)節(jié)所以寫命中Shared狀態(tài)的延遲很低。3.5 偽共享開始冒頭狀態(tài)機(jī)里藏著的性能炸彈從上面的場景二能嗅到一絲不對勁核A只是修改自己私有的一小片數(shù)據(jù)卻會把核B整個緩存行作廢。如果核B也恰好頻繁修改另一片位于同一行內(nèi)的獨(dú)立數(shù)據(jù)就會出現(xiàn)兩個核完全沒有共享邏輯數(shù)據(jù)卻在一致協(xié)議層面反復(fù)競爭同一個行的情況。這就是偽共享False Sharing第4.3節(jié)會專門解決它。這里先記住一點(diǎn)一致性協(xié)議操作的粒度是整個緩存行而不是行內(nèi)的一個字節(jié)。4. 從MESI到工程實(shí)踐變體協(xié)議與偽共享排查4.1 MOESI與MESIFMESI的兩種重要改良純MESI有一個繞不開的性能痛點(diǎn)M狀態(tài)的數(shù)據(jù)要響應(yīng)其他核的讀請求時必須先寫回主存或通過總線轉(zhuǎn)發(fā)而這兩種操作都會帶來額外延遲。MOESI增加了一個OwnedO狀態(tài)允許數(shù)據(jù)在擁有者與主存之間“名不正言不順”地存在O狀態(tài)行保存最新數(shù)據(jù)但主存副本也允許是次新的這樣其他核讀數(shù)據(jù)時可以由O狀態(tài)核直接轉(zhuǎn)發(fā)不必先把數(shù)據(jù)寫回主存。減少一次內(nèi)存訪問對多寫少讀場景非常友好。MESIF則引入ForwardF狀態(tài)用來解決另一個問題當(dāng)多個核同時處于Shared狀態(tài)時如果有某個缺失核發(fā)出讀請求理論上所有S狀態(tài)核都可以響應(yīng)但總線上有多個響應(yīng)者就會造成混亂。F狀態(tài)指定唯一一個“轉(zhuǎn)發(fā)責(zé)任人”只有它負(fù)責(zé)把數(shù)據(jù)發(fā)給請求方其他核保持安靜。這能顯著降低總線監(jiān)聽和響應(yīng)開銷在某些多核互聯(lián)設(shè)計(jì)中較為常見。這些變體并不改變MESI的基本狀態(tài)框架它們只是在特定工程場景下做增補(bǔ)。理解MESI之后再去看MOESI、MESIF會發(fā)現(xiàn)邏輯非常順暢。4.2 目錄協(xié)議在大規(guī)模系統(tǒng)里落地MESI前面講過總線嗅探是廣播式的而目錄協(xié)議把“全喊一嗓子”改為“按名單點(diǎn)名”。目錄項(xiàng)里保存著每個緩存行的狀態(tài)以及持有該行的核心列表。以寫請求為例目錄控制器查到列表只給列表上的核發(fā)無效消息而不是廣播到所有節(jié)點(diǎn)。這樣的代價(jià)是每次內(nèi)存訪問都要先查目錄目錄成為熱點(diǎn)而且從請求發(fā)起到目錄應(yīng)答再到失效完成鏈路比總線嗅探長。但在多路處理器的NUMA系統(tǒng)中跨節(jié)點(diǎn)的消息比片內(nèi)緩存一致性總線昂貴得多廣播式方案通常無法擴(kuò)展到幾十個核心以上。工程上常見做法是片內(nèi)用總線嗅探或較短的一致域跨片用目錄協(xié)議整體上對操作系統(tǒng)和應(yīng)用程序仍然是透明一致的。4.3 偽共享再深挖為什么說它是MESI最隱蔽的敵人這里必須展開講因?yàn)閭喂蚕硎荕ESI對性能影響最直接的體現(xiàn)。假設(shè)有兩個線程分別和兩個不同的int變量交互這兩個int在源碼中的地址恰好相鄰?，F(xiàn)代Cache行大小普遍是64字節(jié)兩個int落在同一行內(nèi)。于是線程A每次寫自己的intMESI都會讓線程B持有的整個行失效線程B再訪問自己的int時需要重新拉取這行數(shù)據(jù)盡管那個int根本沒有被線程A碰過。從結(jié)果看兩個線程實(shí)際是在交替讀寫同一行產(chǎn)生大量的總線流量、緩存缺失和延遲等待。最可氣的是邏輯上兩個變量完全無關(guān)問題完全出在內(nèi)存布局上。我見過一個多線程累加計(jì)數(shù)器的Benchmark線程數(shù)加到16時偽共享版本的耗時可以比消除偽共享版本高出三到五倍而功能上兩者完全等價(jià)。檢查代碼時你未必能直接看到偽共享因?yàn)樗淮嬖跀?shù)據(jù)競爭或邏輯錯誤程序輸出完全正確只有性能曲線會異常。這也是這類問題最坑的地方——它不會讓程序出錯只會讓程序莫名變慢。4.4 實(shí)測偽共享的一個參考做法寫一段示意邏輯來說明如何測量和定位struct counter { int value; }; struct counter counters[4];四個核分別更新counters[0].value、counters[1].value……如果這些struct counter在數(shù)組里是連續(xù)挨著的多個核就會互相作廢整行。把結(jié)構(gòu)體改成struct counter { int value; char padding[60]; // 湊夠64字節(jié)的Cache行 };再跑一次同樣負(fù)載時間差異會非常直觀。實(shí)際定位時用性能分析工具監(jiān)控cache-misses和總線周期數(shù)通常能看到cache-miss率在偽共享版本上顯著偏高。注意不同平臺的Cache行大小可能不同x86主流桌面和服務(wù)器目前普遍是64字節(jié)有些ARM平臺是64字節(jié)也有個別平臺是128字節(jié)。如果做跨平臺優(yōu)化建議用運(yùn)行時讀取或編譯期探測不要硬編碼。5. 從MESI到內(nèi)存模型寫緩沖與內(nèi)存屏障才是最后一環(huán)5.1 MESI保證了一致性但沒有保證順序很多初學(xué)者會有一種錯覺既然MESI保證所有核看到的緩存行最終一致那程序里的普通變量讀寫是不是天然就是順序一致的呢答案是否定的。MESI只負(fù)責(zé)緩存行副本之間的相互同步但它沒有約束CPU執(zhí)行指令的亂序能力也沒有消除寫緩沖帶來的延后寫入問題。一個指令序列在實(shí)際CPU上可以被重排或者說在另一個核的視角下觀察到的是與程序編寫順序不同的效果。MESI保證的是“當(dāng)我讀到某個地址的最新版本時我讀到的確實(shí)是某個全局最新版本”但無法保證“我讀到版本A時必然也看到了版本A之前的所有寫入”。后者屬于內(nèi)存模型問題。5.2 store buffer引發(fā)的經(jīng)典亂序現(xiàn)象典型例子是兩個線程通過共享狀態(tài)變量通信線程1設(shè)置data 1設(shè)置flag 1線程2循環(huán)等待flag 1然后讀取data直覺上線程2看到flag 1時data應(yīng)該已經(jīng)被設(shè)置為1。但在缺乏屏障的情況下線程2可能讀到flag 1但data 0。原因是線程1的兩個store可能被CPU重排或者data 1還在store buffer中排隊(duì)而flag 1已經(jīng)刷出。MESI確實(shí)保證flag對應(yīng)的緩存行一旦變成Modified其他核會看到這個值但它管不了flag和data這兩個不同地址的寫入順序。在并發(fā)編程里這種“可見順序”需要用內(nèi)存屏障或帶屏障語義的原語比如CAS、原子交換來強(qiáng)制。5.3 volatile與內(nèi)存屏障在MESI體系里的定位現(xiàn)在可以比較完整地理解volatile的作用它告訴編譯器和CPU該變量的訪問不能被重排到某些邊界之外必須從內(nèi)存中讀取最新值并且寫入要及時對其他線程可見。物理層面MESI保證了緩存副本會因總線消息而失效邏輯層面需要屏障指令防止CPU和編譯器打亂訪問順序。工程中的常見做法是不加修飾的共享變量僅用于單線程或已知同步保護(hù)的場景跨線程同步用鎖、原子變量等帶有獲取/釋放語義的原語。直接裸寫普通變量volatile來構(gòu)建鎖幾乎一定會踩到內(nèi)存序的坑。記住一條經(jīng)驗(yàn)MESI解決的是緩存一致問題內(nèi)存屏障解決的是順序一致問題兩者配合才能構(gòu)成并發(fā)正確性的地基絕不是同一件事。6. 實(shí)戰(zhàn)排查記錄幾個與Cache相關(guān)的經(jīng)典問題6.1 多線程程序隨線程數(shù)增加反而變慢的排查思路這類問題出現(xiàn)時我通常按下面順序走一遍先跑性能分析工具觀察cache-misses是否異常升高、總線周期占比是否過高。檢查共享變量在內(nèi)存中的布局是不是多個線程頻繁修改的地址落在同一個緩存行內(nèi)。檢查鎖競爭如果多個線程在同一把鎖上忙等鎖對象的緩存行會成為一個天然的串行化點(diǎn)。配合核心負(fù)載與親和性設(shè)置確認(rèn)線程是否真的在計(jì)劃運(yùn)行的核上執(zhí)行。前兩步最常見也是偽共享的典型征兆。如果確認(rèn)是偽共享對齊與padding即可解決不用改任何同步邏輯。6.2 幾個容易忽略的工程細(xì)節(jié)malloc分配的堆對象并非全都孤立連續(xù)分配的小對象經(jīng)常落在同一緩存行。用對齊分配或把熱數(shù)據(jù)放進(jìn)獨(dú)立結(jié)構(gòu)體能有效減少這種沖突。原子變量的操作并不自動消除偽共享。兩個線程各自對同一個行上的不同原子變量做無鎖更新依然會被MESI拖住。大多數(shù)現(xiàn)代平臺中Cache行包含了字節(jié)、字等所有粒度的一致狀態(tài)控制所以“我只改了1個字節(jié)為什么需要淘汰整個行”的疑問是對的但這正是硬件的實(shí)現(xiàn)限制。對齊不是銀彈。過度padding會增加內(nèi)存占用、降低容量命中率只應(yīng)在壓測確認(rèn)熱點(diǎn)后再使用。跨平臺的Cache行大小、一致性協(xié)議細(xì)節(jié)可能存在差異把優(yōu)化封裝在平臺適配層里不要直接散落在業(yè)務(wù)代碼各處。6.3 對一致性知識的落地理解嚴(yán)格來說普通應(yīng)用代碼開發(fā)者不需要直接操作MESI狀態(tài)但它決定了你寫的并發(fā)程序性能好不好、bug難不難查。當(dāng)你理解了寫回、寫無效、偽共享、store buffer這些概念之后再看很多性能優(yōu)化技巧比如無鎖隊(duì)列為什么用緩存行填充、單寫者多讀者為什么比多寫者更快、為什么某些共享計(jì)數(shù)器需要分批累加會豁然開朗。我在實(shí)際工作中有一個體會可以先在紙上推導(dǎo)一遍MESI狀態(tài)轉(zhuǎn)換再寫一個簡單的多線程Benchmark驗(yàn)證偽共享影響把這個“理論到實(shí)驗(yàn)”的過程走通之后這些知識基本就很難忘了。最后再分享一個我自己踩過的坑有一階段在做多線程統(tǒng)計(jì)模塊時把每個線程的計(jì)數(shù)結(jié)果挨個放在一個共享結(jié)構(gòu)體里結(jié)果隨著線程數(shù)增加耗時不但沒下降反而節(jié)節(jié)攀升。排查了很久才發(fā)現(xiàn)是同一個緩存行內(nèi)兩個相鄰計(jì)數(shù)器在互相作廢加了一行padding后性能立刻恢復(fù)。從那以后我對每個多線程熱路徑上的共享數(shù)據(jù)都默認(rèn)帶上了“緩存行邊界”這層意識。Cache相關(guān)的坑就是這樣你不知道時它讓你欲哭無淚你摸清規(guī)律后它就會變成手里最順手的一把性能優(yōu)化利器。