Java記憶體模型深度解析：基礎部分

並發程式設計模型的分類

在並發程式設計中，我們需要處理兩個關鍵問題：執行緒之間如何通訊及執行緒之間如何同步（這裡的執行緒是指並發執行的活動實體）。通訊是指線程之間以何種機制來交換資訊。在命令式程式設計中，執行緒之間的通訊機制有兩種：共享記憶體和訊息傳遞。

在共享記憶體的並發模型裡，線程之間共享程式的公共狀態，線程之間透過寫-讀記憶體中的公共狀態來隱式進行通訊。在訊息傳遞的並發模型裡，線程之間沒有公共狀態，線程之間必須透過明確的發送訊息來明確地進行通訊。

同步是指程式用來控制不同執行緒之間操作發生相對順序的機制。在共享記憶體並發模型裡，同步是明確進行的。程式設計師必須明確指定某個方法或某段程式碼需要在執行緒之間互斥執行。在訊息傳遞的並發模型裡，由於訊息的發送必須在訊息的接收之前，因此同步是隱式進行的。

Java的同時採用的是共享記憶體模型，Java執行緒之間的通訊總是隱式地進行，整個通訊過程對程式設計師完全透明。如果編寫多執行緒程式的Java程式設計師不理解隱式進行的執行緒之間通訊的工作機制，很可能會遇到各種奇怪的記憶體可見性問題。

Java記憶體模型的抽象

在java中，所有實例域、靜態域和陣列元素儲存在堆記憶體中，堆內存在執行緒之間共享（本文使用「共享變數」這個術語代指實例域，靜態域和數組元素）。局部變數（Local variables），方法定義參數（java語言規格稱為formal method parameters）和異常處理器參數（exception handler parameters）不會在執行緒之間共享，它們不會有記憶體可見性問題，也不受記憶體模型的影響。

Java執行緒之間的通訊由Java記憶體模型（本文簡稱JMM）控制，JMM決定一個執行緒對共享變數的寫入何時對另一個執行緒可見。從抽象的角度來看，JMM定義了線程和主記憶體之間的抽象關係：線程之間的共享變數儲存在主記憶體（main memory）中，每個執行緒都有一個私有的本地記憶體（local memory） ，本地記憶體中儲存了該線程以讀/寫共享變數的副本。本地記憶體是JMM的一個抽象概念，並不真實存在。它涵蓋了緩存，寫入緩衝區，寄存器以及其他的硬體和編譯器最佳化。 Java記憶體模型的抽象示意圖如下：

從上圖來看，線程A與線程B之間如要通信的話，必須要經歷下面2個步驟：
首先，線程A把本地內存A中更新過的共享變數刷新到主記憶體中去。
然後，線程B到主記憶體中去讀取線程A之前已更新過的共享變數。

下面透過示意圖說明這兩個步驟：

如上圖所示，本地記憶體A和B有主記憶體中共享變數x的副本。假設初始時，這三個記憶體中的x值都為0。線程A執行時，把更新後的x值（假設值為1）暫時存放在自己的本機記憶體A中。當線程A和線程B需要通訊時，線程A首先會把自己本地記憶體中修改後的x值刷新到主記憶體中，此時主記憶體中的x值變成1。隨後，線程B到主記憶體中去讀取線程A更新後的x值，此時線程B的本地記憶體的x值也變成了1。

從整體來看，這兩個步驟實質上是線程A在向線程B發送訊息，而且這個通訊過程必須要經過主記憶體。 JMM透過控制主記憶體與每個執行緒的本地記憶體之間的交互，來為java程式設計師提供記憶體可見性保證。

重排序

在執行程式時為了提高效能，編譯器和處理器常常會對指令做重排序。重排序分為三種：
編譯器最佳化的重排序。編譯器在不改變單執行緒程式語意的前提下，可以重新安排語句的執行順序。
指令級並行的重排序。現代處理器採用了指令級平行技術（Instruction-Level Parallelism， ILP）來將多條指令重疊執行。如果不存在資料依賴性，處理器可以改變語句對應機器指令的執行順序。
記憶體系統的重新排序。由於處理器使用快取和讀取/寫入緩衝區，這使得載入和儲存操作看起來可能是在亂序執行。

從java原始碼到最終實際執行的指令序列，會分別經歷以下三種重新排序：

上述的1屬於編譯器重排序，2和3屬於處理器重新排序。這些重排序都可能會導致多執行緒程式出現記憶體可見性問題。對於編譯器，JMM的編譯器重新排序規則會禁止特定類型的編譯器重新排序（不是所有的編譯器重新排序都要禁止）。對於處理器重新排序，JMM的處理器重新排序規則會要求java編譯器在產生指令序列時，插入特定類型的記憶體屏障（memory barriers，intel稱為memory fence）指令，透過記憶體屏障指令來禁止特定類型的處理器重排序（不是所有的處理器重排序都要禁止）。

JMM屬於語言級的記憶體模型，它確保在不同的編譯器和不同的處理器平台之上，透過禁止特定類型的編譯器重排序和處理器重排序，為程式設計師提供一致的記憶體可見性保證。

處理器重新排序與記憶體屏障指令

現代的處理器使用寫入緩衝區來暫時保存向記憶體寫入的資料。寫入緩衝區可以保證指令管線持續運行，它可以避免由於處理器停頓下來等待向記憶體寫入資料而產生的延遲。同時，透過以批次的方式刷新寫入緩衝區，以及合併寫入緩衝區中對相同記憶體位址的多次寫，可以減少對記憶體匯流排的佔用。雖然寫入緩衝區有這麼多好處，但每個處理器上的寫入緩衝區，僅對它所在的處理器可見。這個特性會對記憶體操作的執行順序產生重要的影響：處理器對記憶體的讀/寫操作的執行順序，不一定與記憶體實際發生的讀/寫操作順序一致！為了具體說明，請看下面範例：
Processor A
Processor B
a = 1; //A1

x = b; //A2
b = 2; //B1

y = a; //B2
初始狀態：a = b = 0

處理器允許執行後得到結果：x = y = 0
假設處理器A和處理器B按程序的順序並行執行內存訪問，最終卻可能得到x = y = 0的結果。具體的原因如下圖：

這裡處理器A和處理器B可以同時把共享變數寫入自己的寫入緩衝區（A1，B1），然後從記憶體中讀取另一個共享變數（A2，B2），最後才把自己寫到快取區中儲存的髒資料刷新到記憶體中（A3，B3）。以這種時序執行時，程式就可以得到x = y = 0的結果。

從記憶體操作實際發生的順序來看，直到處理器A執行A3來刷新自己的寫入快取區，寫入操作A1才算真正執行了。雖然處理器A執行記憶體操作的順序為：A1->A2，但記憶體操作實際發生的順序卻是：A2->A1。此時，處理器A的記憶體操作順序被重新排序了（處理器B的狀況和處理器A一樣，這裡就不贅述了）。

這裡的關鍵是，由於寫入緩衝區僅對自己的處理器可見，它會導致處理器執行記憶體操作的順序可能會與記憶體實際的操作執行順序不一致。由於現代的處理器都會使用寫入緩衝區，因此現代的處理器都會允許對寫-讀操做重新排序。

下面是常見處理器允許的重排序類型的清單：
Load-Load
Load-Store
Store-Store
Store-Load
資料依賴
sparc-TSO
N
N
N
N
Y
N
ia64
Y
Y
Y
Y
N
PowerPC
Y
個操作重排序，「Y」表示允許重排序。

從上表我們可以看出：常見的處理器都允許Store-Load重新排序；常見的處理器都不允許對存在資料依賴的操作做重排序。 sparc-TSO和x86擁有相對較強的處理器記憶體模型，它們只允許對寫入-讀取操作做重寫排序（因為它們都使用了寫入緩衝區）。

※註1：sparc-TSO是指以TSO(Total Store Order)記憶體模型運作時，sparc處理器的特性。

※註2：上表中的x86包括x64及AMD64。

※註3：由於ARM處理器的記憶體模型與PowerPC處理器的記憶體模型非常類似，本文將忽略它。

※註4：資料依賴性後文會專門說明。

為了確保記憶體可見性，java編譯器在產生指令序列的適當位置會插入記憶體屏障指令來禁止特定類型的處理器重新排序。 JMM把記憶體屏障指令分為下列四類：
屏障類型
指令範例
說明
LoadLoad Barriers
Load1; LoadLoad; Load2
確保Load1資料的裝載，之前於Load2及所有後續裝載指令的裝載。
StoreStore Barriers
Store1; StoreStore; Store2
確保Store1資料對其他處理器可見（刷新到記憶體），之前於Store2及所有後續儲存指令的儲存。
LoadStore Barriers
Load1; LoadStore; Store2
確保Load1資料裝載，之前於Store2及所有後續的儲存指令刷新到記憶體。
StoreLoad Barriers
Store1; StoreLoad; Load2
確保Store1資料對其他處理器變得可見（指刷新到記憶體），之前於Load2及所有後續裝載指令的裝載。 StoreLoad Barriers會使該屏障之前的所有記憶體存取指令（儲存和裝載指令）完成之後，才執行該屏障之後的記憶體存取指令。
StoreLoad Barriers是一個「全能型」的屏障，它同時具有其他三個屏障的效果。現代的多處理器大都支援該屏障（其他類型的屏障不一定被所有處理器支援）。執行此屏障開銷會很昂貴，因為目前處理器通常要把寫入緩衝區中的資料全部刷新到記憶體中（buffer fully flush）。

happens-before

從JDK5開始，java使用新的JSR -133記憶體模型（本文除非特別說明，針對的都是JSR- 133記憶體模型）。 JSR-133提出了happens-before的概念，透過這個概念來闡述操作之間的記憶體可見性。如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必定存在happens-before關係。這裡提到的兩個操作既可以是在一個執行緒之內，也可以是在不同執行緒之間。 與程式設計師密切相關的happens-before規則如下：
程式順序規則：一個執行緒中的每個操作，happens- before 於該執行緒中的任意後續操作。
監視器鎖規則：對一個監視器鎖的解鎖，happens- before 於隨後對這個監視器鎖的加鎖。
volatile變數規則：對一個volatile域的寫，happens- before 於任意後續對這個volatile域的讀。
傳遞性：如果A happens- before B，且B happens- before C，那麼A happens- before C。

注意，兩個操作之間具有happens-before關係，並不意味著前一個操作必須要在後一個操作之前執行！ happens-before僅要求前一個操作（執行的結果）對後一個操作可見，且前一個操作按順序排在第二個操作之前（the first is visible to and ordered before the second）。 happens- before的定義很微妙，後文會具體說明happens-before為什麼要這麼定義。

happens-before與JMM的關係如下圖：

如上圖所示，一個happens-before規則通常對應於多個編譯器重排序規則和處理器重排序規則。對於java程式設計師來說，happens-before規則簡單易懂，它避免程式設計師為了理解JMM提供的記憶體可見性保證而去學習複雜的重排序規則以及這些規則的具體實作。

 以上就是Java記憶體模型深度解析：基礎部分的內容，更多相關內容請關注PHP中文網（m.sbmmt.com）！