JVM-內存管理

對於Java程序員來講，在虛擬機自動內存管理機制幫助下，不須要爲每個new操做去寫配對的delete／free代碼，不容易出現內存泄漏和溢出方面的問題。一旦出現內存泄漏和溢出問題，若是不瞭解虛擬機怎樣使用內存的，那麼排查錯誤將會成爲一項異常艱難的工做。

運行時數據區域

Java虛擬機在執行Java程序的過程當中會把它所管理的內存劃分爲若干個不一樣的數據區域。根據《Java虛擬機規範（Java SE 7版）》的規定，Java虛擬機所管理的內存將會包括如下幾個運行時數據區域，如圖所示：

程序計數器

程序計數器（Program Counter Register）是一塊較小的內存區域，能夠把它看做是當前線程所執行的字節碼的行號的指示器。在虛擬機概念模型中，字節碼解釋器工做時就是經過改變程序計數器的值來選取下一條須要執行的字節碼指令，分支，循環、跳轉、異常處理、線程恢復等基礎功能都須要依賴這個計數器來完成。

因爲Java虛擬機的多線程是經過線程輪流切換並分配處理器所執行時間的方式來實現的，在任何一個時刻，一個處理器（相對於多核處理器）都只會執行一條線程中的指令。所以，爲了線程切換後可以恢復到正確的執行位置，每條線程須要有一個獨立的程序計數器，各線程之間計數器互相不影響，獨立存儲，咱們稱這類內存區域爲「線程私有」的內存。

若是線程正在執行的是一個Java方法，計數器記錄的是正在執行的虛擬機字節碼指令的地址；若是正在執行的是Native方法，計數器值則爲空。此內存區域是惟一一個在Java虛擬機規範中沒有規定任何OutOfMemeryError狀況的區域。

Java虛擬機棧

Java虛擬機棧（Java Virtual Machine Stacks）也是線程私有的，它的生命週期與線程相同。虛擬機棧描述的是Java方法執行的內存模型；每一個方法在執行的同時都會建立一個棧幀（Stack Frame）用於存儲局部變量表、操做數棧、動態連接、方法出口等信息。每個方法從調用直到執行完成的過程，就對應着一個棧幀在虛擬機棧中入棧到出棧的過程。

在java虛擬機規範中，對這個區域規定了兩種異常狀況情況：若是線程請求的棧深度大於虛擬機所容許的深度，將拋出StackOverflowError異常；若是虛擬機能夠動態擴展（大部分Java虛擬機均可動態擴展，同時也容許固定長度的虛擬機棧），若是擴展時沒法申請到足夠的內存，就會拋出OutOfMemoryError異常。

本地方法棧

本地方法棧是爲虛擬機執行Native方法服務。在虛擬機規範中對本地方法棧使用的語言、使用方式與數據結構並無強制規定，所以具體的虛擬機能夠自由實現它。

Sun HotSpot虛擬機將本地方法棧和虛擬機棧合二爲一。與虛擬機棧同樣，本地方法棧也會拋出StackOverflowError和OutOfMemoryError異常。

Java堆

對於大多數應用來講，Java堆（Java Heap）是Java虛擬機所管理的內存中最大的一塊。Java堆是被全部線程共享的一塊內存區域，在虛擬機啓動時建立，幾乎全部的對象實例和數組都在這裏分配。Java堆是垃圾收集器管理的主要區域，所以不少時候也稱作「GC堆」。

根據Java虛擬機規範的規定，Java堆能夠處於物理上不連續的內存空間中，只要邏輯上連續的便可。在實現時，便可實現成固定大小的，也能夠是可擴展的，不過當前主流的虛擬機都是按照擴展來實現的（經過-Xmx和-Xms控制）。若是在堆中沒有內存完成實例分配，而且堆也沒法擴展時，將會拋出OutOfMemoryError異常。

方法區

方法區（Method Area）是各個線程共享的內存區域，它用於存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等數據。雖然Java虛擬機規範把方法區描述爲堆的一個邏輯部分，但它卻有一個別名叫作「Non-Heap（非堆）」，目的應該是與Java堆區分開來。

Java虛擬機規範對方法區的限制很是寬鬆，除了和Java堆同樣不須要連續的內存和能夠選擇固定大小或者可擴展外，還能夠選擇不實現垃圾收集。這區域的內存回收目標主要針對常量池的回收和對類型卸載，通常來講，這個區域的回收「成績」比較難以使人滿意，尤爲是類型的卸載，條件至關苛刻，可是這部分區域的回收確實是必要的。

根據Java虛擬機規範的規定，當方法區沒法知足內存分配需求時，將拋出OutOfMemoryError異常。

運行時常量池

運行時常量池（Runtime Constant Pool）是方法區的一部分。Class文件中除了有類的版本、字段、方法、接口等描述信息外，還有一項信息是常量池（Constant Pool Table），用於存放編譯期生成的各類字面量和符號引用，這部份內容將在類加載後進入方法區的運行常量池中存放。

運行時常量池是具有動態性，Java語言並不要求常量必定只有編譯器才能產生，也就是並不是預置入Class文件中常量池的內容才能進入方法區運行時常量池，運行期間也可能將新的常量放入池中，這種特性被開發人員利用比較可能是String類的intern()方法。

直接內存

直接內存（Direct Memory）並非虛擬機運行時數據區的一部分，也不是Java虛擬機規範中定義的內存區域，可是這部份內存也被頻繁地使用，並且也可能致使OutOfMemoryError異常。

在JDK 1.4中新加入了NIO類，引入了一種基於通道（Channel）與緩存區（Buffer）的I／O方式，它可使用Native函數庫直接分配堆外內存，而後一個存儲在Java堆中的DirectByteBuffer對象做爲這塊內存的引用進行操做。這樣能在一些場景中顯著提升性能，由於避免了在Java堆和Native堆中來回複製數據。

顯然，本機直接內存的分配不會受到Java堆大小的限制，可是，既然是內存，確定仍是會受到本機總內存大小以及處理器尋址空間的限制。

若是各個內存區域總和大於物理內存限制，從而致使動態擴展時出現OutOfMemoryError異常。

HotSpot虛擬機如何處理對象分配、佈局和訪問

對象分配

虛擬機遇到一條new指令時，首先將去檢查這個指令的參數是否能在子常量池中定位到一個類的符號引用，而且檢查這個符號引用表明的類是否已被加載、解析和初始化過。若是沒有，那必須先執行相應的類加載過程。在類加載檢查經過後，虛擬機將爲新生對象分配內存。對象所需內存的大小在類加載完成後即可徹底肯定，爲對象分配空間的任務等同於把一塊肯定大小的內存從Java堆中劃分出來。

對象內存分配方式:

一、指針碰撞

假設Java堆中內存是絕對規整的，全部用過的內存都放在一邊，空閒的內存放在另外一邊，中間放着一個指針做爲分界點的指示器，那所分配內存就僅僅是把那個指針向空閒空間那邊挪動一段與對象大小相等的距離。

二、空閒列表

若是Java堆中內存並非規整的，已使用的內存和空閒的內存相互交錯，虛擬機就必須維護一個列表，記錄上那些內存塊是可用的，在分配的時候從列表中找到一個足夠大的空間劃分給對象實例，並更新列表上的記錄。

選擇哪一種分配方式由Java堆是否規整決定，而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。所以，在使用Serial、ParNew等帶Compact過程的收集器時，系統採用的分配算法是指針碰撞；而使用CMS這種基於Mark-Sweep算法的收集器時，一般採用空閒列表。

分配過程當中如何解決線程安全：

在併發狀況下可能出現正在給對象A分配內存，指針還沒來得及修改，對象B又同時使用了原來的指針來分配內存的狀況。虛擬機經過如下兩種方式解決線程安全問題：

一、對分配內存空間的動做進行同步處理——實際上虛擬機採用CAS配上失敗重試的方式保證更新操做的原子性；

二、把內存分配的動做按照線程劃分在不一樣的空間之中進行，即每一個線程在Java堆中預先分配一小塊內存，稱爲本地線程分配緩衝（Thread Local Allocation Buffer，TLAB）。那個線程要分配內存，就在哪一個線程的TLAB上分配，只有TLAB用完並分配新的TLAB時，才須要同步鎖定。虛擬機是否使用TLAB，能夠經過-XX:+/-UseTLAB參數來設定。

內存分配完成後，虛擬機須要將分配到內存空間都初始化爲零值（不包括對象頭），若是使用TLAB，這一工做過程也能夠提早至TLAB分配時進行。這一步操做保證了對象的實例字段在Java代碼中能夠不賦初始值就直接使用，程序能訪問到這些字段的數據類型所對應的零值。

接下來，虛擬機要對對象進行必要的設置，例如這個對象是哪一個類的實例、如何才能找到類的元數據信息、對象的哈希碼、對象的GC分代年齡等信息。這些信息存放在對象的對象頭（Object Header）之中。根據虛擬機當前的運行狀態的不一樣，如是否啓用偏向鎖等，對象頭會有不一樣的設置方式。

在上面工做都完成以後，從虛擬機的視覺來看，一個新的對象已經產生了，但從Java程序的視圖來看，對象建立纔剛剛開始——init方法尚未執行，全部的字段都還爲零。通常類說（由字節碼中是否隨invokespecial指令所決定），執行new指令以後會接着執行init方法，把對象按照程序員的意願進行初始化，這樣一個真正可用的對象纔算徹底產生出來。

對象的內存佈局

在HotSpot虛擬機中，對象在內存中存儲的佈局能夠分爲3塊區域：對象頭（Header）、實例數據（Instance Data） 和對齊填充（Padding）。

對象頭

HotSpot虛擬機的對象頭包括兩部分信息，用於存儲對象自身的運行時數據和類型指針。

一、存儲對象自身的運行時數據

如哈希碼、GC分代年齡、鎖狀態標誌、線程持有的鎖、偏向線程ID、偏向時間戳等，這部分數據的長度在32位和64位的虛擬機（未開啓壓縮指針）中分別爲32bit和64bit，官方稱爲「Mark Word」。對象須要存儲的運行時數據不少，其實已經超出了32位和64位Bitmap結構所能記錄的限度，可是對象頭信息是與對象自身定義的數據無關的額外存儲成本，考慮到虛擬機的空間效率，Mark Word被設計成一個非固定的數據結構以便在極小的空間內存存儲儘可能多的信息，它會根據對象的狀態複用本身的存儲空間。

二、類型指針

即對象指向它的類元數據的指針，虛擬機經過這個指針來肯定這個對象是哪一個類的實例。並非全部的虛擬機實現都必須在對象數據上保留類型指針，換句話說，查找對象的元數據信息並不必定要通過對象自己。

實例數據

實例數據是對象真正存儲的有效信息，也是在程序代碼中所定義的各類類型的字段內容。不管是從父類繼承下來的，仍是在子類中定義的，都須要記錄起來 。這部分的存儲順序會受到虛擬機分配策略參數和字段在Java源碼中定義順序的影響。

對其填充

對其填充並非必然存在的，也沒有特別的含義，它僅僅起着佔位符的做用。因爲HotSpot VM的自動內存管理系統要求對象起始地址必須是8字節的整數倍，換句話說，就是對象的大小必須是8字節的整數倍。因爲對象頭部分正好是8字節的整數倍，所以，當對象實例數據部分沒有對齊時，就須要經過對齊填充來補全。

對象的訪問定位

創建對象是爲了使用對象，Java程序須要經過棧上的reference數據來操做堆上的具體對象。因爲reference類型在Java虛擬機規範中規定了一個指向對象的引用，並無定義這個引用應該經過何種方式去定位、訪問堆中對象的具體位置，因此對象訪問方式也是取決於虛擬機實現而定的。

目前主流的訪問方式有使用句柄和直接指針兩種。以下：

一、句柄訪問

Java堆中會劃分出一塊內存來做爲句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數據與類型數據各自的具體地址信息。

二、直接指針訪問

Java堆對象的佈局中就必須考慮如何放置類型數據的相關信息，而reference中存儲的直接就是對象地址。

使用句柄訪問的最大好處就是reference中存儲的是穩定的句柄地址，在對象被移動（垃圾收集時移動對象是很是廣泛的）時只會改變句柄的實例數據指針，而reference自己不須要修改。

使用直接指針訪問的最大好處就是速度更快，節省了一次指針定位的時間開銷，因爲對象的訪問在Java中很是頻繁，所以也是一項很是客觀的執行成本。Sun HotSpot虛擬機採用直接指針進行對象訪問的。

OutOfMemoryError異常

在Java虛擬機規範的描述中，除了程序計數器外，虛擬機內存的其餘幾個運行時區域都發生OutOfMemoryError異常的可能。

Java堆溢出

Java堆用於存儲對象實例，只要不斷地建立對象，而且保證GC Roots到對象之間有可達路徑來避免垃圾回收機制清除這些對象，那麼在對象數量到達最大堆的容量限制後就會產生內存溢出異常。

/** * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError */
public class HeapOOM {

    static class OOMObject{}


    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<OOMObject>();

        while(true){
            list.add(new OOMObject());
        }
    }
}
複製代碼

運行結果：

要解決這個區域的異常，通常的手段是先經過內存映像分析工具對Dump出來的堆轉儲快照進行分析，重點是確認內存中的對象是不是必要的，也就是要先分清楚究竟是出現了內存泄漏仍是內存溢出。若是是內存泄漏，可進一步經過工具查看泄漏對象到GC Roots的引用鏈。因而就能找到泄漏對象是經過怎樣的路徑與GC Roots相關聯並致使垃圾收集器沒法自動回收它們的。若是不存在泄漏，就是內存中的對象確實都還必須存活着，那就應當檢查虛擬機的堆參數，與機器物理內存對比看是否還能夠調大，從代碼上檢查是否存在某些對象生命週期過長、持有狀態時間過長的狀況，嘗試減小程序運行期的內存消耗。

虛擬機棧和本地方法棧溢出

因爲在HotSpot虛擬機中並不區分虛擬機棧和本地方法棧，所以，對於HotSpot來講，雖然-Xoss參數（設置本地方法棧大小）存在，但其實是無效的，棧容器只由-Xss參數設定。

/** * VM Args；-Xss160k */
public class JavaVMStackSOF {

    private int stackLength = 1;

    public void stackLeak(){
        stackLength++;
        stackLeak();
    }

    public static void main(String[] args) {
        JavaVMStackSOF oom = new JavaVMStackSOF();
        oom.stackLeak();
    }

}
複製代碼

方法區和運行時常量池溢出

String.intern()是一個Native方法，它的做用是：若是字符串常量池中已經包含一個等於此String對象的字符串，則返回表明池中這個字符串的String對象；不然，將此String對象包含的字符串添加到常量池中，而且返回此String對象的引用。在JDK 1.6及以前的版本中，因爲常量池分配在永久代內，咱們能夠經過-XX:PermSize和-XX:MaxPermSize限制方法區大小，從而間接限制其中常量池的容量。

/** * VM Args：-XX:PermSize=10M -XX:MaxPermSize=10M */
public class RuntimeConstantPoolOOM {


    public static void main(String[] args) {

        List<String> list = new ArrayList<String>();

        int i = 0;
        while (true){
            list.add(String.valueOf(i).intern());
        }
    }
}
複製代碼

在JDK 1.8中運行出現以下提示,並無出現內存溢出：

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=10M; support was removed in 8.0

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=10M; support was removed in 8.0

網上搜索資料找到以下一段內容，說明其緣由：

類的元數據, 字符串池, 類的靜態變量將會從永久代移除, 放入Java heap或者native memory. 其中建議JVM的實現中將類的元數據放入native memory, 將字符串池和類的靜態變量放入java堆中. 這樣能夠加載多少類的元數據就不在由MaxPermSize控制, 而由系統的實際可用空間來控制。

根據上述的描述，能夠推測在JDK 1.8中測試方法區異常也是不會出現。

歡迎留言補充，共同交流。我的微信公衆號求關注：