1. 程式人生 > >淺談Java內存模型

淺談Java內存模型

硬件架構 能說 概念 其他 java程序 總線 內存模型 for 屬於

Java內存模型雖說是一個老生常談的問題 ,也是大廠面試中繞不過的,甚至初級面試也會問到。但是真正要理解起來,還是相當困難,主要這個東西看不見,摸不著。網上已經有大量的博客,但是人家的終究是人家的,自己也要好好的去理解,去消化。今天我也來班門弄斧,說下Java內存模型。

說到Java內存模型,不得不說到 計算機硬件方面的知識。

計算機硬件體系

我們都知道CPU 和 內存是計算機中比較核心的兩個東西,它們之間會頻繁的交互,隨著CPU發展越來越快,內存的讀寫的速度遠遠不如CPU的處理速度,所以CPU廠商在CPU上加了一個 高速緩存,用來緩解這種問題。我們在看CPU硬件參數的時候,也會看到有這樣的參數:
技術分享圖片


一般高速緩存有3級:L1,L2,L3,CPU與內存的交互,就發生了變化,CPU不再與內存直接交互,CPU會先去L1中尋找數據,沒有的話,再去L2中尋找,然後是L3,最後才去內存尋找(更準確的來說,應該是CPU中的寄存器去尋找)。

我們可以畫一張圖來理解:
技術分享圖片

看起來一切都很美好,但是隨著科技的進步,CPU廠商們叒搞事了,推出了多核CPU,每個CPU上又有高速緩存,CPU與內存的交互就變成了下面這個樣子:
技術分享圖片

這樣就會引發一個問題:緩存不一致

為什麽會出現這個問題呢?

CPU需要修改某個數據,是先去Cache中找,如果Cache中沒有找到,會去內存中找,然後把數據復制到Cache中,下次就不需要再去內存中尋找了,然後進行修改操作。而修改操作的過程是這樣的:在Cache裏面修改數據,然後再把數據刷新到主內存。其他CPU需要讀取數據,也是先去Cache中去尋找,如果找到了就不會去內存找了。

所以當兩個CPU的Cache同時都擁有某個數據,其中一個CPU修改了數據,另外一個CPU是無感知的,並不知道這個數據已經不是最新的了,它要讀取數據還是從自己的Cache中讀取,這樣就導致了“緩存不一致”。

其實對於這樣的描述並不是十分準確,因為計算、讀取等操作都是在CPU的寄存器中進行的,這樣的描述是為了讓問題變得更簡單,相信學過計算機體系的人應該非常清楚整個流程,在這裏就簡單的描述下。

解決這個問題的方法有很多,比如:

  • 總線加鎖(此方法性能較低,現在已經不會再使用)
  • MESI協議
    這是Intel提出的,MESI協議也是相當復雜,在這裏我就簡單的說下:當一個CPU修改了Cache中的數據,會通知其他緩存了這個數據的CPU,其他CPU會把Cache中這份數據的Cache Line置為無效,要讀取數據的話,直接去內存中獲取,不會再從Cache中獲取了。

當然還有其他的解決方案,MESI協議是其中比較出名的。

Java線程與硬件處理器

其實,我們在Java中開啟一個線程,最終Java也會交給CPU去執行。
具體的流程是:我們在使用Java線程,內部會調用操作系統(OS)的內核線程(Kernel-Level Thread),這種線程是操作系統內核(Kernel)直接支持的,內核通過調度器,對線程進行調度,並將線程交給各個CPU內核去處理。

如下圖所示:
技術分享圖片

Java內存模型

看到標題,大家肯定會想:我靠,難道上面說的都和Java內存模型沒有關系嗎,從這裏才是真正介紹Java內存模型嗎?其實,並不是,Java內存模型是一個抽象的概念,其實並不存在,它描述的是一種規範,最終Java程序都會交給CPU去運行,所以上面是計算機硬件體系是基礎,有了上面的基礎,才有了Java內存模型,或者說Java的內存模型就是利用了計算機硬件體系。

還是從一張圖來入手:
技術分享圖片

本地內存:存放的是 私有變量 和 主內存數據的副本。如果私有變量是基本數據類型,則直接存放在本地內存,如果是引用類型變量,存放的是引用(指針),實際的數據存放在主內存。本地內存是不共享的,只有屬於它的線程可以訪問。也有好多人把 本地內存 稱之為 線程棧 或者 工作空間。

主內存:存放的是共享的數據,所有線程都可以訪問。當然它也有不少其他稱呼,比如 堆內存,共享內存等等。

Java內存模型規定了所有對共享變量的讀寫操作都必須在本地內存中進行,需要先從主內存中拿到數據,復制到本地內存,然後在本地內存中對數據進行修改,再刷新回主內存。

通過前面的鋪墊,我們應該認識到Java的執行最終還是會交給CPU去處理,但是Java的內存模型和硬件架構又不完全一致。對於硬件來說,只有CPU,Cache和主內存,並沒有Java內存模型中本地內存(線程棧、工作空間)或者主內存(共享內存,堆內存)的概念,所以不管是Java內存模型中的本地內存,還是主內存的數據,最終都會存儲在CPU(更準確的來說 是寄存器)、Cache、內存上。

所以,Java內存模型和計算機硬件架構存在這樣的關系:

技術分享圖片

Java內存模型就是為了解決多線程對共享數據的讀寫一致性問題。

並發編程中三個重要特性

原子性:

不可分割,同生共死。
i=1
具有原子性,直接 在本地內存中進行賦值操作。

i++;
不具有原子性,有三個步驟
1.把i讀取出來(原子性)
2.在本地內存中做自增運算(原子性)
3.再把值寫回i(原子性)

多個原子性操作組合在一起,就不具有原子性了。

一般情況下,基本數據類型的賦值,讀取都是具有原子性的。

可見性

一個線程在本地內存中修改了共享內存的數據,對於其他持有該數據的線程是“不可見”的。

有序性

代碼在運行的時候,執行順序可能並不是嚴格從上到下執行的,會進行指令重排。
根據CPU流水線作業,一般來說 簡單的操作會先執行,復雜的操作後執行。
指令重排會有兩個規則:

  • as-if-seria
    不管怎麽重排序,單線程的執行結果不能發生改變。正是由於這個特性,在單線程中,程序員一般無需理會重排序帶來的問題。
  • happens-before
    1. 程序次序規則
      一段代碼在單線程中執行的結果是有序的(感覺就是as-if-seria原則)
    2. volatile規則(以後會花一整節內容介紹,這裏不展開)
    3. 鎖定規則
      如果鎖處於Lock的狀態,必須等Unlock後,才能再次進行Lock操作。
    4. 傳遞規則
      A happens-before B , B happens-before C,那麽A happens-before C。

Java內存模型是個相當復雜的東西,我在這裏可能還說不上是談,只能說是“蜻蜓點水 ”般的介紹下。希望通過這篇文章,大家可以對Java模型有一個初步的了解。

以後,我也會介紹Synchronized 和 volatile關鍵字等等,我可能會再次提到本節中涵蓋的內容,並做進一步的補充說明。

好了,本文的內容到這裏就結束了,在寫之前,已經做好心理準備了,可能需要花上半天時間,但是實際上遠遠不止半天,在寫的過程中,翻閱了大量的文章,包括 知乎、博客園、簡書 等等,發現 如果要“較真”“擡杠”的話,文章與文章之間也有有沖突的地方,甚至一篇文章中,也有前後矛盾的地方。我也不奢求本文中介紹的所有內容都是正確的。為了不誤人子弟,如果大家發現有錯誤,希望可以及時向我提出,我也會盡快核實後修改。

感謝大家可以看到最後,再見。

淺談Java內存模型