Java內存區域與Java內存模型

• Java內存區域 
   
  
  • Java虛擬機在運行程序時會把其自動管理的內存劃分爲以上幾個區域，每一個區域都有其用途以及建立銷燬的時機，其中藍色部分表明的是全部線程共享的數據區域，而綠色部分表明的是每一個線程的私有數據區域。 
    
    1. 方法區（Method Area）：方法區屬於線程共享的內存區域，又稱Non-Heap（非堆），主要用於存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等數據，根據Java 虛擬機規範的規定，當方法區沒法知足內存分配需求時，將拋出OutOfMemoryError 異常。值得注意的是在方法區中存在一個叫運行時常量池(Runtime Constant Pool）的區域，它主要用於存放編譯器生成的各類字面量和符號引用，這些內容將在類加載後存放到運行時常量池中，以便後續使用。
    2. Java堆（Java Heap）：Java 堆也是屬於線程共享的內存區域，它在虛擬機啓動時建立，是Java 虛擬機所管理的內存中最大的一塊，主要用於存放對象實例，幾乎全部的對象實例都在這裏分配內存，注意Java 堆是垃圾收集器管理的主要區域，所以不少時候也被稱作GC 堆，若是在堆中沒有內存知足實例分配需求，而且堆也沒法再擴展時，將會拋出OutOfMemoryError 異常。
    3. 程序計數器（Program Counter Register）：屬於線程私有的數據區域，是一小塊內存空間，主要表明當前線程所執行的字節碼行號指示器。字節碼解釋器工做時，經過改變這個計數器的值來選取下一條須要執行的字節碼指令，分支、循環、跳轉、異常處理、線程恢復等基礎功能都須要依賴這個計數器來完成。
    4. 虛擬機棧(Java Virtual Machine Stacks)：屬於線程私有的數據區域，與線程同時建立，總數與線程關聯，表明Java方法執行的內存模型。每一個方法執行時都會建立一個棧楨來存儲方法的的變量表、操做數棧、動態連接方法、返回值、返回地址等信息。每一個方法從調用直結束就對於一個棧楨在虛擬機棧中的入棧和出棧過程，以下（圖有誤，應該爲棧楨）： 
       
    5. 本地方法棧(Native Method Stacks)：本地方法棧屬於線程私有的數據區域，這部分主要與虛擬機用到的 Native 方法相關，通常狀況下，咱們無需關心此區域。
• Java內存模型 
  
  • Java內存模型(即Java Memory Model，簡稱JMM)自己是一種抽象的概念，並不真實存在，它描述的是一組規則或規範，經過這組規範定義了程序中各個變量（包括實例字段，靜態字段和構成數組對象的元素）的訪問方式。因爲JVM運行程序的實體是線程，而每一個線程建立時JVM都會爲其建立一個工做內存(有些地方稱爲棧空間)，用於存儲線程私有的數據，而Java內存模型中規定全部變量都存儲在主內存，主內存是共享內存區域，全部線程均可以訪問，但線程對變量的操做(讀取賦值等)必須在工做內存中進行，首先要將變量從主內存拷貝的本身的工做內存空間，而後對變量進行操做，操做完成後再將變量寫回主內存，不能直接操做主內存中的變量，工做內存中存儲着主內存中的變量副本拷貝，前面說過，工做內存是每一個線程的私有數據區域，所以不一樣的線程間沒法訪問對方的工做內存，線程間的通訊(傳值)必須經過主內存來完成，其簡要訪問過程以下圖： 
    
  • 須要注意的是，JMM與Java內存區域的劃分是不一樣的概念層次，更恰當說JMM描述的是一組規則，經過這組規則控制程序中各個變量在共享數據區域和私有數據區域的訪問方式，JMM是圍繞原子性，有序性、可見性展開的(稍後會分析)。JMM與Java內存區域惟一類似點，都存在共享數據區域和私有數據區域，在JMM中主內存屬於共享數據區域，從某個程度上講應該包括了堆和方法區，而工做內存數據線程私有數據區域，從某個程度上講則應該包括程序計數器、虛擬機棧以及本地方法棧。或許在某些地方，咱們可能會看見主內存被描述爲堆內存，工做內存被稱爲線程棧，實際上他們表達的都是同一個含義。關於JMM中的主內存和工做內存說明以下： 
    
    1. 主內存：主要存儲的是Java實例對象，全部線程建立的實例對象都存放在主內存中，無論該實例對象是成員變量仍是方法中的本地變量(也稱局部變量)，固然也包括了共享的類信息、常量、靜態變量。因爲是共享數據區域，多條線程對同一個變量進行訪問可能會發現線程安全問題。
    2. 工做內存：主要存儲當前方法的全部本地變量信息(工做內存中存儲着主內存中的變量副本拷貝)，每一個線程只能訪問本身的工做內存，即線程中的本地變量對其它線程是不可見的，就算是兩個線程執行的是同一段代碼，它們也會各自在本身的工做內存中建立屬於當前線程的本地變量，固然也包括了字節碼行號指示器、相關Native方法的信息。注意因爲工做內存是每一個線程的私有數據，線程間沒法相互訪問工做內存，所以存儲在工做內存的數據不存在線程安全問題。
  • 弄清楚主內存和工做內存後，接瞭解一下主內存與工做內存的數據存儲類型以及操做方式，根據虛擬機規範，對於一個實例對象中的成員方法而言，若是方法中包含本地變量是基本數據類型，將直接存儲在工做內存的幀棧結構中，但假若本地變量是引用類型，那麼該變量的引用會存儲在功能內存的幀棧中，而對象實例將存儲在主內存(共享數據區域，堆)中。但對於實例對象的成員變量，無論它是基本數據類型仍是引用類型，都會被存儲到堆區。至於static變量以及類自己相關信息將會存儲在主內存中。須要注意的是，在主內存中的實例對象能夠被多線程共享，假若兩個線程同時調用了同一個對象的同一個方法，那麼兩條線程會將要操做的數據拷貝一份到本身的工做內存中，執行完成操做後才刷新到主內存，簡單示意圖以下所示： 
    
• Java線程與硬件處理器 
  
  • 瞭解完硬件的內存架構後，接着瞭解JVM中線程的實現原理，理解線程的實現原理，有助於咱們瞭解Java內存模型與硬件內存架構的關係，在Window系統和Linux系統上，Java線程的實現是基於一對一的線程模型，所謂的一對一模型，實際上就是經過語言級別層面程序去間接調用系統內核的線程模型，即咱們在使用Java線程時，Java虛擬機內部是轉而調用當前操做系統的內核線程來完成當前任務。這裏須要瞭解一個術語，內核線程(Kernel-Level Thread，KLT)，它是由操做系統內核(Kernel)支持的線程，這種線程是由操做系統內核來完成線程切換，內核經過操做調度器進而對線程執行調度，並將線程的任務映射到各個處理器上。每一個內核線程能夠視爲內核的一個分身,這也就是操做系統能夠同時處理多任務的緣由。因爲咱們編寫的多線程程序屬於語言層面的，程序通常不會直接去調用內核線程，取而代之的是一種輕量級的進程(Light Weight Process)，也是一般意義上的線程，因爲每一個輕量級進程都會映射到一個內核線程，所以咱們能夠經過輕量級進程調用內核線程，進而由操做系統內核將任務映射到各個處理器，這種輕量級進程與內核線程間1對1的關係就稱爲一對一的線程模型。以下圖： 
    
  • 如圖所示，每一個線程最終都會映射到CPU中進行處理，若是CPU存在多核，那麼一個CPU將能夠並行執行多個線程任務。
• Java內存模型與硬件內存架構的關係 
  
  • 經過對前面的硬件內存架構、Java內存模型以及Java多線程的實現原理的瞭解，咱們應該已經意識到，多線程的執行最終都會映射到硬件處理器上進行執行，但Java內存模型和硬件內存架構並不徹底一致。對於硬件內存來講只有寄存器、緩存內存、主內存的概念，並無工做內存(線程私有數據區域)和主內存(堆內存)之分，也就是說Java內存模型對內存的劃分對硬件內存並無任何影響，由於JMM只是一種抽象的概念，是一組規則，並不實際存在，無論是工做內存的數據仍是主內存的數據，對於計算機硬件來講都會存儲在計算機主內存中，固然也有可能存儲到CPU緩存或者寄存器中，所以整體上來講，Java內存模型和計算機硬件內存架構是一個相互交叉的關係，是一種抽象概念劃分與真實物理硬件的交叉。（注意對於Java內存區域劃分也是一樣的道理） 
    
• JMM存在的必要性 
  
  • 在明白了Java內存區域劃分、硬件內存架構、Java多線程的實現原理與Java內存模型的具體關係後，接着來談談Java內存模型存在的必要性。因爲JVM運行程序的實體是線程，而每一個線程建立時JVM都會爲其建立一個工做內存(有些地方稱爲棧空間)，用於存儲線程私有的數據，線程與主內存中的變量操做必須經過工做內存間接完成，主要過程是將變量從主內存拷貝的每一個線程各自的工做內存空間，而後對變量進行操做，操做完成後再將變量寫回主內存，若是存在兩個線程同時對一個主內存中的實例對象的變量進行操做就有可能誘發線程安全問題。以下圖，主內存中存在一個共享變量x，如今有A和B兩條線程分別對該變量x=1進行操做，A/B線程各自的工做內存中存在共享變量副本x。假設如今A線程想要修改x的值爲2，而B線程卻想要讀取x的值，那麼B線程讀取到的值是A線程更新後的值2仍是更新前的值1呢？答案是，不肯定，即B線程有可能讀取到A線程更新前的值1，也有可能讀取到A線程更新後的值2，這是由於工做內存是每一個線程私有的數據區域，而線程A變量x時，首先是將變量從主內存拷貝到A線程的工做內存中，而後對變量進行操做，操做完成後再將變量x寫回主內，而對於B線程的也是相似的，這樣就有可能形成主內存與工做內存間數據存在一致性問題，假如A線程修改完後正在將數據寫回主內存，而B線程此時正在讀取主內存，即將x=1拷貝到本身的工做內存中，這樣B線程讀取到的值就是x=1，但若是A線程已將x=2寫回主內存後，B線程纔開始讀取的話，那麼此時B線程讀取到的就是x=2，但究竟是哪一種狀況先發生呢？這是不肯定的，這也就是所謂的線程安全問題。 
     
    爲了解決相似上述的問題，JVM定義了一組規則，經過這組規則來決定一個線程對共享變量的寫入什麼時候對另外一個線程可見，這組規則也稱爲Java內存模型（即JMM），JMM是圍繞着程序執行的原子性、有序性、可見性展開的，下面咱們看看這三個特性。
• Java內存模型的承諾 
  
  • 這裏咱們先來了解幾個概念，即原子性？可見性？有序性？最後再闡明JMM是如何保證這3個特性。 
    
    1. 原子性：原子性指的是一個操做是不可中斷的，即便是在多線程環境下，一個操做一旦開始就不會被其餘線程影響。好比對於一個靜態變量int x，兩條線程同時對他賦值，線程A賦值爲1，而線程B賦值爲2，無論線程如何運行，最終x的值要麼是1，要麼是2，線程A和線程B間的操做是沒有干擾的，這就是原子性操做，不可被中斷的特色。有點要注意的是，對於32位系統的來講，long類型數據和double類型數據(對於基本數據類型，byte,short,int,float,boolean,char讀寫是原子操做)，它們的讀寫並不是原子性的，也就是說若是存在兩條線程同時對long類型或者double類型的數據進行讀寫是存在相互干擾的，由於對於32位虛擬機來講，每次原子讀寫是32位的，而long和double則是64位的存儲單元，這樣會致使一個線程在寫時，操做完前32位的原子操做後，輪到B線程讀取時，剛好只讀取到了後32位的數據，這樣可能會讀取到一個既非原值又不是線程修改值的變量，它多是「半個變量」的數值，即64位數據被兩個線程分紅了兩次讀取。但也沒必要太擔憂，由於讀取到「半個變量」的狀況比較少見，至少在目前的商用的虛擬機中，幾乎都把64位的數據的讀寫操做做爲原子操做來執行，所以對於這個問題沒必要太在乎，知道這麼回事便可。 
       
       • 理解指令重排 
         
         • 計算機在執行程序時，爲了提升性能，編譯器和處理器的經常會對指令作重排，通常分如下3種： 
           
           1. 編譯器優化的重排：編譯器在不改變單線程程序語義的前提下，能夠從新安排語句的執行順序。
           2. 指令並行的重排：現代處理器採用了指令級並行技術來將多條指令重疊執行。若是不存在數據依賴性(即後一個執行的語句無需依賴前面執行的語句的結果)，處理器能夠改變語句對應的機器指令的執行順序。
           3. 內存系統的重排：因爲處理器使用緩存和讀寫緩存衝區，這使得加載(load)和存儲(store)操做看上去多是在亂序執行，由於三級緩存的存在，致使內存與緩存的數據同步存在時間差。
         • 其中編譯器優化的重排屬於編譯期重排，指令並行的重排和內存系統的重排屬於處理器重排，在多線程環境中，這些重排優化可能會致使程序出現內存可見性問題。
    2. 可見性：理解了指令重排現象後，可見性容易了，可見性指的是當一個線程修改了某個共享變量的值，其餘線程是否可以立刻得知這個修改的值。對於串行程序來講，可見性是不存在的，由於咱們在任何一個操做中修改了某個變量的值，後續的操做中都能讀取這個變量值，而且是修改過的新值。但在多線程環境中可就不必定了，前面咱們分析過，因爲線程對共享變量的操做都是線程拷貝到各自的工做內存進行操做後才寫回到主內存中的，這就可能存在一個線程A修改了共享變量x的值，還未寫回主內存時，另一個線程B又對主內存中同一個共享變量x進行操做，但此時A線程工做內存中共享變量x對線程B來講並不可見，這種工做內存與主內存同步延遲現象就形成了可見性問題，另外指令重排以及編譯器優化也可能致使可見性問題，經過前面的分析，咱們知道不管是編譯器優化仍是處理器優化的重排現象，在多線程環境下，確實會致使程序輪序執行的問題，從而也就致使可見性問題。
    3. 有序性：有序性是指對於單線程的執行代碼，咱們老是認爲代碼的執行是按順序依次執行的，這樣的理解並無毛病，畢竟對於單線程而言確實如此，但對於多線程環境，則可能出現亂序現象，由於程序編譯成機器碼指令後可能會出現指令重排現象，重排後的指令與原指令的順序未必一致，要明白的是，在Java程序中，假若在本線程內，全部操做都視爲有序行爲，若是是多線程環境下，一個線程中觀察另一個線程，全部操做都是無序的，前半句指的是單線程內保證串行語義執行的一致性，後半句則指指令重排現象和工做內存與主內存同步延遲現象。
• JMM提供的解決方案 
  
  • 在理解了原子性，可見性以及有序性問題後，看看JMM是如何保證的，在Java內存模型中都提供一套解決方案供Java工程師在開發過程使用，如原子性問題，除了JVM自身提供的對基本數據類型讀寫操做的原子性外，對於方法級別或者代碼塊級別的原子性操做，可使用synchronized關鍵字或者重入鎖(ReentrantLock)保證程序執行的原子性。而工做內存與主內存同步延遲現象致使的可見性問題，可使用synchronized關鍵字或者volatile關鍵字解決，它們均可以使一個線程修改後的變量當即對其餘線程可見。對於指令重排致使的可見性問題和有序性問題，則能夠利用volatile關鍵字解決，由於volatile的另一個做用就是禁止重排序優化。除了靠sychronized和volatile關鍵字來保證原子性、可見性以及有序性外，JMM內部還定義一套happens-before 原則來保證多線程環境下兩個操做間的原子性、可見性以及有序性。
• 理解JMM中的happens-before 原則 
  
  • 假若在程序開發中，僅靠sychronized和volatile關鍵字來保證原子性、可見性以及有序性，那麼編寫併發程序可能會顯得十分麻煩，幸運的是，在Java內存模型中，還提供了happens-before 原則來輔助保證程序執行的原子性、可見性以及有序性的問題，它是判斷數據是否存在競爭、線程是否安全的依據，happens-before 原則內容以下： 
    
    1. 程序順序原則，即在一個線程內必須保證語義串行性，也就是說按照代碼順序執行。
    2. 鎖規則 解鎖(unlock)操做必然發生在後續的同一個鎖的加鎖(lock)以前，也就是說，若是對於一個鎖解鎖後，再加鎖，那麼加鎖的動做必須在解鎖動做以後(同一個鎖)。
    3. volatile規則 volatile變量的寫，先發生於讀，這保證了volatile變量的可見性，簡單的理解就是，volatile變量在每次被線程訪問時，都強迫從主內存中讀該變量的值，而當該變量發生變化時，又會強迫將最新的值刷新到主內存，任什麼時候刻，不一樣的線程老是可以看到該變量的最新值。
    4. 線程啓動規則 線程的start()方法先於它的每個動做，即若是線程A在執行線程B的start方法以前修改了共享變量的值，那麼當線程B執行start方法時，線程A對共享變量的修改對線程B可見。
    5. 線程終止規則 線程的全部操做先於線程的終結，Thread.join()方法的做用是等待當前執行的線程終止。假設在線程B終止以前，修改了共享變量，線程A從線程B的join方法成功返回後，線程B對共享變量的修改將對線程A可見。
    6. 線程中斷規則 對線程 interrupt()方法的調用先行發生於被中斷線程的代碼檢測到中斷事件的發生，能夠經過Thread.interrupted()方法檢測線程是否中斷。
    7. 對象終結規則 對象的構造函數執行，結束先於finalize()方法
    8. 傳遞性 A先於B ，B先於C 那麼A必然先於C。
  • 上述8條原則無需手動添加任何同步手段(synchronized|volatile)便可達到效果。