Java 記憶體模型(JMM)描述了 JVM 如何使用計算機的記憶體(RAM),JVM 是一個完整計算機的模型,因此該模型包含了記憶體模型的設計 —— JMM,
如果要正確地設計并發程式,了解 JMM 非常重要,JMM 描述了不同執行緒間如何以及何時可以看到其它執行緒寫入共享變數的值,以及如何在必要時同步訪問共享變數,
最初的 JMM 設計不充分,因此 JMM 在 Java 1.5 進行了修訂,此版本的 JMM 仍在 Java 8 中使用,
Java Memory Model 內部實作
JVM 內部使用的 JMM 將記憶體劃分為執行緒堆疊和堆,下圖從邏輯角度說明了 JMM:
在 JVM 中運行的每個執行緒都有它自己的執行緒堆疊,執行緒堆疊包含了執行緒呼叫了哪些方法以到達當前執行點的資訊,我們把它成為“呼叫堆疊(Call Stack)“,當執行緒執行其代碼時,呼叫堆疊會發生變化,
執行緒堆疊還包含了正在執行的每個方法的所有的區域變數(呼叫堆疊上的所有方法),一個執行緒只能訪問它自己的執行緒堆疊,由執行緒創建的區域變數對于創建它的執行緒以外的所有其他執行緒都是不可見的,即使兩個執行緒正在執行完全相同的代碼,兩個執行緒仍將在各自的執行緒堆疊中創建自己的區域變數,因此,每個執行緒都有自己的每個區域變數的版本,
基本型別(boolean,byte,short,char,int,long,float,double)完全存盤在執行緒堆疊里,因此對其他執行緒是不可見的,一個執行緒可以將一個基本型別的變數副本傳遞給另一個執行緒,但它不能共享原始區域變數本身,
堆包含了 Java 應用程式中創建的所有物件,不管物件是哪個執行緒創建的,這包括基本型別的包裝版本(如 Byte,Integer,Long 等),無論物件是創建成區域變數,還是作為另一個物件的成員變數被創建,物件都存盤在堆中,
下圖說明了呼叫堆疊和區域變數存盤在執行緒堆疊中,而物件存盤在堆中,
區域變數如果是基本型別,這種情況下,變數完全存盤在執行緒堆疊上,
區域變數如果是物件的參考,這種情況下,參考(區域變數)存盤在執行緒堆疊上,但物件本身存盤在堆上,
物件中可能包含方法,而這些方法中可能包含區域變數,這種情況下,即使方法所屬的物件存盤在堆上,但這些區域變數卻是存盤在執行緒堆疊上的,
物件的成員變數與物件本身一起存盤在堆上,當成員變數是基本型別以及是物件的參考時都是如此,
靜態型別變數與類定義一起存盤在堆上,
所有執行緒通過擁有物件參考去訪問堆中的物件,當一個執行緒有權訪問一個物件時,它也能訪問該物件的成員變數,如果兩個執行緒同一時間呼叫同一物件的一個方法,它們都可以訪問該物件的成員變數,但每個執行緒都有自己區域變數的副本,
這是一個說明上述要點的圖表:
兩個執行緒各有一組區域變數,其中一個區域變數(Local Variable 2)指向堆中的共享物件(Object 3),兩個執行緒各自對同一各物件擁有不同的參考,它們的參考是區域變數,因此它們存盤在各自執行緒的執行緒堆疊中,但是,這兩個不同參考指向堆中的同一個物件,
請注意,共享物件(Object 3)將 Object 2 和 Object 4 作為成員變數參考(如從 Object 3 到 Object 2 和 Object 4 的箭頭所示),通過物件 3 中的這些成員變數參考,兩個執行緒可以訪問物件 2 和 物件 4,
上圖還顯示了一個區域變數指向堆中的兩個不同物件,這種情況下,參考指向兩個不同的物件(Object 1 和 Object 5),而不是同一個物件,理論上,如果兩個執行緒都參考了兩個物件,那兩個執行緒都可以訪問物件 1 和 物件 5,但在上圖中,每個執行緒只參考了兩個物件中的一個,Java學習圈子
那么,什么樣的 Java 代碼可以導致上面的記憶體圖?好吧,代碼就如下面的代碼一樣簡單:
如果兩個執行緒正在執行 run() 方法,則前面的結果就會出現,run() 方法會呼叫 methodOne(),而 methodOne() 會呼叫 methodTwo(),
方法 methodOne() 中宣告了一個基本型別的區域變數(localVariable1 型別 int)和一個物件參考的區域變數(localVariable2),
每個執行 methodOne() 的執行緒將在各自的執行緒堆疊上創建自己的 localVariable1 和 localVariable2 副本,localVariable 1 變數將完全分離,只存在于每個執行緒的執行緒堆疊中,一個執行緒無法看到另一個執行緒對其 localVariable 1 副本所做的更改,
執行 methodOne() 的每個執行緒還將創建它們自己的 localVariable2 副本,然而,localVariable 2 的兩個不同副本最終都指向堆上的同一個物件,代碼將 localVariable 2 設定為指向靜態變數參考的物件,靜態變數只有一個副本,這個副本存盤在堆上,因此,localVariable 2 的兩個副本最終都指向靜態變數所指向的 MySharedObject 的同一個實體,MySharedObject 實體也存盤在堆中,它對應于上圖中的物件 3,Java學習圈子???????
注意 MySharedObject 類也包含兩個成員變數,成員變數本身同物件一起存盤在堆中,這兩個成員變數指向另外兩個 Integer 物件,這些 Integer 物件對應于上圖中的物件 2和物件 4,
還要注意 methodTwo() 創建的一個名為 localVariable 1 的本地變數,這個區域變數是一個指向 Integer 物件的物件參考,該方法將 localVariable 1 參考設定為指向一個新的 Integer 實體,localVariable 1 參考將存盤在每個執行 methodTwo() 的執行緒的一個副本中,實體化的兩個 Integer 物件存盤在堆上,但是由于方法每次執行都會創建一個新的 Integer 物件,因此執行該方法的兩個執行緒將創建單獨的 Integer 實體,methodTwo() 中創建的 Integer 物件對應于上圖中的物件 1和物件 5,還要注意類 MySharedObject 中的兩個成員變數,它們的型別是 long,這是一個基本型別,由于這些變數是成員變數,所以它們仍然與物件一起存盤在堆中,只有本地變數存盤在執行緒堆疊中,
硬體記憶體架構
現代硬體記憶體架構與 Java 記憶體模型略有不同,了解硬體記憶體架構也很重要,以了解 Java 記憶體模型如何與其一起作業,本節介紹了常見的硬體記憶體架構,后面的部分將介紹 Java 記憶體模型如何與其配合使用,
這是現代計算機硬體架構的簡化圖:
現代計算機通常有兩個或更多的 CPU,其中一些 CPU 也可能有多個內核,關鍵是,在具有2個或更多 CPU 的現代計算機上,可以同時運行多個執行緒,每個 CPU 都能夠在任何給定時間運行一個執行緒,這意味著如果您的 Java 應用程式是多執行緒的,那么每個 CPU 可能同時(并發地)運行 Java 應用程式中的一個執行緒,
每個 CPU 包含一組暫存器,這些暫存器本質上是在 CPU 記憶體中,CPU 在這些暫存器上執行操作的速度要比在主記憶體中執行變數的速度快得多,這是因為 CPU 訪問這些暫存器的速度要比訪問主記憶體快得多,
每個 CPU 還可以有一個 CPU 快取記憶體層,事實上,大多數現代 CPU 都有某種大小的快取記憶體層,CPU 訪問快取記憶體的速度比主記憶體快得多,但通常沒有訪問內部暫存器的速度快,因此,CPU 高速快取存盤器介于內部暫存器和主存盤器的速度之間,某些 CPU 可能有多個快取層(L1 和 L2),但要了解 Java 記憶體模型如何與記憶體互動,這一點并不重要,重要的是要知道 CPU 可以有某種快取存盤層,
計算機還包含一個主記憶體區域(RAM),所有 CPU 都可以訪問主存,主記憶體區域通常比 CPU 的快取記憶體大得多,
通常,當 CPU 需要訪問主記憶體時,它會將部分主記憶體讀入 CPU 快取,它甚至可以將快取的一部分讀入內部暫存器,然后對其執行操作,當 CPU 需要將結果寫回主記憶體時,它會將值從內部暫存器重繪到快取記憶體,并在某個時候將值重繪回主記憶體,
當CPU需要在高速快取中存盤其他內容時,通常會將存盤在高速快取中的值重繪回主記憶體,CPU 快取可以一次將資料寫入一部分記憶體,并一次重繪一部分記憶體,它不必每次更新時都讀取/寫入完整的快取,通常,快取是在稱為“快取線(Cache Line)”的較小記憶體塊中更新的,可以將一潭訓多條高速快取線讀入高速快取記憶體,并將一潭訓多條高速快取線再次重繪回主記憶體,
JMM 和硬體記憶體結構之間的差別
如前所述,JMM 和硬體記憶體結構是不同的,硬體記憶體體系結構不區分執行緒堆疊和堆,在硬體上,執行緒堆疊和堆都位于主記憶體中,執行緒堆疊和堆的一部分有時可能存在于 CPU 高速快取和內部 CPU 暫存器中,如下圖所示:
當物件和變數可以存盤在計算機的不同記憶體區域時,可能會出現某些問題,主要有兩個問題:
- 執行緒更新(寫入)對共享變數的可見性
- 讀取、檢查和寫入共享變數時的競爭條件
這兩個問題將在下面幾節中進行解釋,Java學習圈子???????
共享物件的可見性
如果兩個或多個執行緒共享一個物件,而沒有正確使用 volatile 宣告或同步,那么一個執行緒對共享物件的更新可能對其他執行緒不可見,
假設共享物件最初存盤在主記憶體中,在 CPU 1 上運行的執行緒然后將共享物件讀入它的 CPU 快取,在這里,它對共享物件進行更改,只要沒有將 CPU 快取重繪回主記憶體,在其他 CPU 上運行的執行緒就不會看到共享物件的更改版本,這樣,每個執行緒都可能最終擁有自己的共享物件副本,每個副本位于不同的 CPU緩 存中,
下圖說明了大致的情況,在左 CPU 上運行的一個執行緒將共享物件復制到其 CPU 快取中,并將其 count 變數更改為2,此更改對運行在正確 CPU 上的其他執行緒不可見,因為尚未將更新重繪回主記憶體,
要解決這個問題,可以使用 Java 的 volatile 關鍵字,volatile 關鍵字可以確保直接從主記憶體讀取給定的變數,并在更新時始終將其寫回主記憶體,
競態條件
如果兩個或多個執行緒共享一個物件,且多個執行緒更新該共享物件中的變數,則可能出現競爭條件,
假設執行緒 A 將共享物件的變數計數讀入其 CPU 快取,再想象一下,執行緒 B 執行相同的操作,但是進入了不同的 CPU 快取,現在執行緒 A 向 count 加一,執行緒 B 也這樣做,現在 var1 已經增加了兩次,每次在每個 CPU 快取中增加一次,
如果按順序執行這些增量,變數計數將增加兩次,并將原始值 + 2 寫回主記憶體,
但是,這兩個增量是同時執行的,沒有適當的同步,無論哪個執行緒 A 和執行緒 B 將其更新版本的 count 寫回主記憶體,更新后的值只比原始值高1,盡管有兩個增量,
該圖說明了上述競態條件問題的發生情況:
要解決這個問題,可以使用 Java synchronized 塊,同步塊保證在任何給定時間只有一個執行緒可以進入代碼的給定臨界段,Synchronized 塊還保證在 Synchronized 塊中訪問的所有變數都將從主記憶體中讀入,當執行緒退出 Synchronized 塊時,所有更新的變數將再次重繪回主記憶體,而不管變數是否宣告為 volatile,
粉絲福利:
為粉絲講解福利資源:特講解免費教程教你如何學習 ,原始碼、分布式、微服務、性能優化、多執行緒并發,從0到1,帶你領略底層精髓,
如何學習:
上圖中的資料都是我精心錄制視頻,感興趣的可以加入我的Java學習圈子 免費獲取,希望能夠在你接下來即將應對的的面試程序中能夠盡到一份綿薄之力,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qianduan/18929.html
標籤:其他
下一篇:學習日志——2019/07/05
