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