愛生活,愛編碼,本文已收錄 架構技術專欄關注這個喜歡分享的地方。本文 架構技術專欄 已收錄,有各類JVM、多線程、源碼視頻、資料以及技術文章等你來拿
前兩天我搞了兩個每日一個知識點,對多線程併發的部分知識作了下歸納性的總結。但經過小夥伴的反饋是,那玩意寫的比較抽象,看的雲裏霧裏暈暈乎乎的。面試
因此又針對多線程底層這一塊再從新作下系統性的講解。
有興趣的朋友能夠先看下前兩節,能夠說是個籠統的概念版。緩存
好了,迴歸正題。在多線程併發的世界裏synchronized、volatile、JMM是咱們繞不過去的技術坎,而重排序、可見性、內存屏障又有時候搞得你一臉懵逼。有道是知其然知其因此然,瞭解了底層的原理性問題,不管是平常寫BUG仍是面試都是必備神器了。多線程
先看幾個問題點:架構
一、處理器與內存之間是怎麼交互的?併發
二、什麼是緩存一致性協議?異步
三、高速緩存內的消息是怎麼更新變化的?高併發
四、內存屏障又和他們有什麼關係?oop
若是上面的問題你都能滾瓜爛熟,那就去看看電影放鬆下吧!編碼
目前的處理器的處理能力要遠遠的勝於主內存(DRAM)訪問的效率,每每主內存執行一次讀寫操做所需的時間足夠處理器執行上百次指令。因此爲了填補處理器與主內存之間的差距,設計者們在主內存和處理器直接引入了高速緩存(Cache)。如圖:spa
其實在現代處理器中,會有多級高速緩存。通常咱們會成爲一級緩存(L1 Cache)、二級緩存(L2 Cache)、三級緩存(L3 Cache)等,其中一級緩存通常會被集成在CPU內核中。如圖:
高速緩存存在於每一個處理器內,處理器在執行讀、寫操做的時候並不須要直接與內存交互,而是經過高速緩存進行。
高速緩存內其實就是爲應用程序訪問的變量保存了一個數據副本。高速緩存至關於一個容量極小的散列表(Hash Table),其鍵是一個內存地址,值是內存數據的副本或是咱們準備寫入的數據。從其內部來看,其實至關於一個拉鍊散列表,也就是包含了不少桶,每一個桶上又能夠包含不少緩存條目(想一想HashMap),如圖:
在每一個緩存條目中,其實又包含了Tag、Data Block、Flag三個部分,我們來個小圖:
那麼,咱們的處理器又是怎麼尋找到咱們須要的變量呢?
很少說,上圖:
其實,在處理器執行內存訪問變量的操做時,會對內存地址進行解碼的(由高速緩存控制器執行)。而解碼後就會獲得tag、index 、offset三部分數據。
index : 咱們知道高速緩存內的結構是一個拉鍊散列表,因此index就是爲了幫咱們來定位究竟是哪一個緩存條目的。
tag : 很明顯和咱們緩存條目中的Tag 同樣,因此tag 至關於緩存條目的編號。主要用於,在同一個桶下的拉鍊中來尋找咱們的目標。
offset : 咱們要知道一個前提,就是一個緩存條目中的緩存行是能夠存儲不少變量的,因此offset的做用是用來肯定一個變量在緩存行中的起始位置。
因此,在若是在高速緩存內能找到緩存條目而且定位到了響應得緩存行,而此時緩存條目的Flag標識爲有效狀態,這時候也就是咱們所說的緩存命中(Cache Hit),不然就是緩存未命中(Cache Miss)。
緩存未命有包括讀未命中(Read Miss)和寫未命中(Write Miss)兩種,對應着對內存的讀寫操做。
而在讀未命中(Read Miss) 產生時,處理器所須要的數據會從主內存加載並被存入高速緩存對應的緩存行中,此過程會致使處理器停頓(Stall)而不能執行其餘指令。
在多線程進行共享變量訪問時,由於各個線程執行的處理器上的高速緩存中都會保存一份變量的副本數據,這樣就會有一個問題,那當一個副本更新後怎麼保證其它處理器能立刻的獲取到最新的數據。這其實就是緩存一致性的問題,其本質也就是怎麼防止數據的髒讀。
爲了解決這個問題,處理器間出現了一種通訊機制,也就是緩存一致性協議(Cache Coherence Protocol)。
緩存一致性協議有不少種,MESI(Modified-Exclusive-Shared-Invalid)協議實際上是目前使用很普遍的緩存一致性協議,x86處理器所使用的緩存一致性協議就是基於MESI的。
咱們能夠把MESI對內存數據訪問理解成咱們經常使用的讀寫鎖,它可使對同一內存地址的讀操做是併發的,而寫操做是獨佔的。因此在任什麼時候刻寫操做只能有一個處理器執行。而在MESI中,一個處理器要向內存寫數據時必須持有該數據的全部權。
MESI將緩存條目的狀態分爲了Modified、Exclusive、Shared、Invalid四種,並在此基礎上定義了一組消息用於處理器的讀、寫內存操做。如圖:
因此MESI其實就是使用四種狀態來標識了緩存條目當前的狀態,來保證了高速緩存內數據一致性的問題。那咱們來仔細的看下四種狀態
Modified :
表示高速緩存中相應的緩存行內的數據已經被更新了。因爲MESI協議中任意時刻只能有一個處理器對同一內存地址對應的數據進行更新,也就是說再多個處理器的高速緩存中相同Tag值得緩存條目只能有一個處於Modified狀態。處於此狀態的緩存條目中緩存行內的數據與主內存包含的數據不一致。
Exclusive:
表示高速緩存相應的緩存行內的數據副本與主內存中的數據同樣。而且,該緩存行以獨佔的方式保留了相應主內存地址的數據副本,此時其餘處理上高速緩存當前都不保留該數據的有效副本。
Shared:
表示當前高速緩存相應緩存行包含相應主內存地址對應的數據副本,且與主內存中的數據是一致的。若是緩存條目狀態是Shared的,那麼其餘處理器上若是也存在相同Tag的緩存條目,那這些緩存條目狀態確定也是Shared。
Invalid:
表示該緩存行中不包含任何主內存中的有效數據副本,這個狀態也是緩存條目的初始狀態。
前面說了那麼多,都是MESI的基礎理論,那麼,MESI協議究竟是怎麼來協調處理器進行內存的讀寫呢?
其實,想協調處理必然須要先和各個處理器進行通訊。因此MESI協議定義了一組消息機制用於協調各個處理器的讀寫操做。
咱們能夠參考HTTP協議來進行理解,能夠將MESI協議中的消息分爲請求和響應兩類。處理器在進行主內存讀寫的時候會往總線(Bus)中發請求消息,同時每一個處理器還會嗅探(Snoop)總線中由其餘處理器發出的請求消息並在必定條件下往總線中回覆響應得響應消息。
針對於消息的類型,有以下幾種:
瞭解完了基礎的消息類型,那麼咱們就來看看MESI協議是如何協助處理器實現內存讀寫的,看圖說話:
舉例:假如內存地址0xxx上的變量s 是CPU1 和CPU2共享的咱們先來講下CPU上讀取數據s
高速緩存內存在有效數據時:
CPU1會根據內存地址0xxx在高速緩存找到對應的緩存條目,並讀取緩存條目的Tag和Flag值。若是此時緩存條目的Flag 是M、E、S三種狀態的任何一種,那麼就直接從緩存行中讀取地址0xxx對應的數據,不會向總線中發送任何消息。
高速緩存內不存在有效數據時:
一、如CPU2 高速緩存內找到的緩存條目狀態爲I時,則說明此時CPU2的高速緩存中不包含數據s的有效數據副本。
二、CPU2向總線發送Read消息來讀取地址0xxx對應的數據s.
三、CPU1(或主內存)嗅探到Read消息,則須要回覆Read Response提供相應的數據。
四、CPU2接收到Read Response消息時,會將其中攜帶的數據s存入相應的緩存行並將對應的緩存條目狀態更新爲S。
從宏觀的角度看,就是上面的流程了,咱們再繼續深刻下,看看在緩存條目爲I的時候究竟是怎麼進行消息處理的
說完了讀取數據,咱們就在說下CPU1是怎麼寫入一個地址爲0xxx的數據s的
MESI協議解決了緩存一致性的問題,但其中有一個問題,那就是須要在等待其餘處理器所有回覆後才能進行下一步操做,這種等待明顯是不能接受的,下面就繼續來看看大神們是怎麼解決處理器等待的問題的。
由於MESI自身有個問題,就是在寫內存操做的時候必須等待其餘全部處理器將自身高速緩存內的相應數據副本都刪除後,並接收到這些處理器回覆的Invalidate Acknowledge/Read Response消息後才能將數據寫入高速緩存。
爲了不這種等待形成的寫操做延遲,硬件設計引入了寫緩衝器和無效化隊列。
在每一個處理器內都有本身獨立的寫緩衝器,寫緩衝器內部包含不少條目(Entry),寫緩衝器比高速緩存還要小點。
那麼,在引入了寫緩衝器後,處理器在執行寫入數據的時候會作什麼處理呢?還會直接發送消息到BUS嗎?
咱們來看幾個場景:
(注意x86處理器是無論相應的緩存條目是什麼狀態,都會直接將每個寫操做結果存入寫緩衝器)
一、若是此時緩存條目狀態是E或者M:
表明此時處理器已經獲取到數據全部權,那麼就會將數據直接寫入相應的緩存行內,而不會向總線發送消息。
二、若是此時緩存條目狀態是S
經過上面的場景描述咱們能夠看出,寫緩衝器幫助處理器實現了異步寫數據的能力,使得處理器處理指令的能力大大提高。
其實在處理器接到Invalidate類型的消息時,並不會刪除消息中指定地址對應的數據副本(也就是說不會去立刻修改緩存條目的狀態爲I),而是將消息存入無效化隊列以後就回復Invalidate Acknowledge消息了,主要緣由仍是爲了減小處理器等待的時間。
因此無論是寫緩衝器仍是無效化隊列,其實都是爲了減小處理器的等待時間,採用了空間換時間的方式來實現命令的異步處理。
總之就是,寫緩衝器解決了寫數據時要等待其餘處理器響應得問題,無效化隊列幫助解決了刪除數據等待的問題。
但既然是異步的,那必然又會帶來新的問題 -- 內存重排序和可見性問題。
因此,咱們繼續接着聊。
經過上面內容咱們知道了有了寫緩衝器後,處理器在寫數據時直接寫入緩衝器就直接返回了。
那麼問題就來了,當咱們寫完一個數據又要立刻進行讀取可咋辦呢?話很少說,我們仍是舉個例子來講,如圖:
此時第一步處理器將變量S的更新後的數據寫入到寫緩衝器返回,接着立刻執行了第二布進行S變量的讀取。因爲此時處理器對S變量的更新結果還停留在寫緩衝器中,所以從高速緩存緩存行中讀到的數據仍是變量S的舊值。
爲了解決這種問題,存儲轉發(Store Fowarding)這個概念上線了。其理論就是處理器在執行讀操做時會先根據相應的內存地址從寫緩衝器中查詢。若是查到了直接返回,不然處理器纔會從高速緩存中查找,這種從緩衝器中讀取的技術就叫作存儲轉發。看圖:
因爲寫緩衝器和無效化隊列的出現,處理器的執行都變成了異步操做。緩衝器是每一個處理器私有的,一個處理器所存儲的內容是沒法被其餘處理器讀取的。
舉個例子:
CPU1 更新變量到緩衝器中,而CPU2由於沒法讀取到CPU1緩衝器內容因此從高速緩存中讀取的仍然是該變量舊值。
其實這就是寫緩衝器致使StoreLoad重排序問題,而寫緩衝器還會致使StoreStore重排序問題等。
爲了使一個處理器上運行的線程對共享變量所作的更新被其餘處理器上運行的線程讀到,咱們必須將寫緩衝器的內容寫到其餘處理器的高速緩存上,從而使在緩存一致性協議做用下這次更新能夠被其餘處理器讀取到。
處理器在寫緩衝器滿、I/O指令被執行時會將寫緩衝器中的內容寫入高速緩存中。但從變量更新角度來看,處理器自己沒法保障這種更新的」及時「性。爲了保證處理器對共享變量的更新可被其餘處理器同步,編譯器等底層系統藉助一類稱爲內存屏障的特殊指令來實現。
內存屏障中的存儲屏障(Store Barrier)會使執行該指令的處理器將寫緩衝器內容寫入高速緩存。
內存屏障中的加載屏障(Load Barrier)會根據無效化隊列內容指定的內存地址,將相應處理器上的高速緩存中相應的緩存條目狀態標記爲I。
由於說了存儲屏障(Store Barrier)和加載屏障(Load Barrier) ,因此這裏再簡單的提下內存屏障的概念。
劃重點:(你細品)
處理器支持哪一種內存重排序(LoadLoad重排序、LoadStore重排序、StoreStore重排序、StoreLoad重排序),就會提供相對應可以禁止重排序的指令,而這些指令就被稱之爲內存屏障(LoadLoad屏障、LoadStore屏障、StoreStore屏障、StoreLoad屏障)
劃重點:
若是用X和Y來代替Load或Store,這類指令的做用就是禁止該指令左側的任何 X 操做與該指令右側的任何 Y 操做之間進行重排序(就是交換位置),確保指令左側的全部 X 操做都優先於指令右側的Y操做。
內存屏障的具體做用:
屏障名稱 | 示例 | 具體做用 |
---|---|---|
StoreLoad | Store1;Store2;Store3;StoreLoad;Load1;Load2;Load3 | 禁止StoreLoad重排序,確保屏障以前任何一個寫(如Store2)的結果都會在屏障後任意一個讀操做(如Load1)加載以前被寫入 |
StoreStore | Store1;Store2;Store3;StoreStore;Store4;Store5;Store6 | 禁止StoreStore重排序,確保屏障以前任何一個寫(如Store1)的結果都會在屏障後任意一個寫操做(如Store4)以前被寫入 |
LoadLoad | Load1;Load2;Load3;LoadLoad;Load4;Load5;Load6 | 禁止LoadLoad重排序,確保屏障以前任何一個讀(如Load1)的數據都會在屏障後任意一個讀操做(如Load4)以前被加載 |
LoadStore | Load1;Load2;Load3;LoadStore;Store1;Store2;Store3 | 禁止LoadStore重排序,確保屏障以前任何一個讀(如Load1)的數據都會在屏障後任意一個寫操做(如Store1)的結果被寫入高速緩存(或主內存)前被加載 |
其實從頭看到尾就會發現,一個技術點的出現每每是爲了填補另外一個的坑。
爲了解決處理器與主內存之間的速度鴻溝,引入了高速緩存,卻又致使了緩存一致性問題
爲了解決緩存一致性問題,引入瞭如MESI等技術,又致使了處理器等待問題
爲了解決處理器等待問題,引入了寫緩衝和無效化隊列,又致使了重排序和可見性問題
爲了解決重排序和可見性問題,引入了內存屏障,舒坦。。。
愛生活,愛編碼,本文已收錄 架構技術專欄關注這個喜歡分享的地方。本文 架構技術專欄 已收錄,有各類JVM、多線程、源碼視頻、資料以及技術文章等你來拿
往期推薦