Java虛擬機內存管理

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

運行時數據區域

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

.

程序計數器

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

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

如果線程正在執行的是一個Java方法，計數器記錄的是正在執行的虛擬機位元組碼指令的地址；如果正在執行的是Native方法，計數器值則為空。此內存區域是唯一一個在Java虛擬機規範中沒有規定任何OutOfMemeryError情況的區域。

Java虛擬機棧

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

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

本地方法棧

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

SunHotSpot虛擬機直接就本地方法棧和虛擬機棧合二為一。與虛擬機棧一樣，本地方法棧也會拋出StackOverflowError和OutOfMemoryError異常。

Java堆

對於大多數應用來說，Java堆（JavaHeap）是Java虛擬機所管理的內存中最大的一塊。Java堆是被所有線程共享的一塊內存區域，在虛擬機啟動時創建，幾乎所有的對象實例和數組都在這裡分配。Java堆是垃圾收集器管理的主要區域，因此很多時候也稱做「GC堆」。

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

方法區

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

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

運行時常量池

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

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

直接內存

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

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

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

對象分配

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

對象內存分配方式:

1、指針碰撞

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

2、空閑列表

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

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

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

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

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

2、把內存分配的動作按照線程劃分在不同的空間之中進行，即每個線程在Java堆中預先分配一小塊內存，稱為本地線程分配緩衝（ThreadLocal AllocationBuffer，TLAB）。那個線程要分配內存，就在哪個線程的TLAB上分配，只有TLAB用完並分配新的TLAB時，才需要同步鎖定。虛擬機是否使用TLAB，可以通過-XX:+/-UseTLAB參數來設定。

內存分配完成後，虛擬機需要將分配到內存空間都初始化為零值（不包括對象頭），如果使用TLAB，這一工作過程也可以提前至TLAB分配時進行。這一步操作保證了對象的實例欄位在Java代碼中可以不賦初始值就直接使用，程序能訪問到這些欄位的數據類型所對應的零值。

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

在上面工作都完成之後，從虛擬機的視覺來看，一個新的對象已經產生了，但從Java程序的視圖來看，對象創建才剛剛開始——init方法還沒有執行，所有的欄位都還為零。一般類說（由位元組碼中是否隨invokespecial指令所決定），執行new指令之後會接著執行init方法，把對象按照程序員的意願進行初始化，這樣一個真正可用的對象才算完全產生出來。

對象的內存布局

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

對象頭

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

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

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

2、類型指針

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

實例數據

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

對其填充

對其填充並不是必然存在的，也沒有特別的含義，它僅僅起著佔位符的作用。由於HotSpotVM的自動內存管理系統要求對象起始地址必須是8位元組的整數倍，換句話說，就是對象的大小必須是8位元組的整數倍。由於對象頭部分正好是8位元組的整數倍，因此，當對象實例數據部分沒有對齊時，就需要通過對齊填充來補全。

對象的訪問定位

建立對象是為了使用對象，Java程序需要通過棧上的reference數據來操作堆上的具體對象。由於reference類型在Java虛擬機規範中規定了一個指向對象的引用，並沒有定義這個引用應該通過何種方式去定位、訪問堆中對象的具體位置，所以對象訪問方式也是取決於虛擬機實現而定的。

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

1、句柄訪問

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

.

2、直接指針訪問

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

.

使用句柄訪問的最大好處就是reference中存儲的是穩定的句柄地址，在對象被移動（垃圾收集時移動對象是非常普遍的）時只會改變句柄的實例數據指針，而reference本身不需要修改。

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

OutOfMemoryError異常

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

Java堆溢出

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

/**  * 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出來的堆轉儲快照進行分析，重點是確認內存中的對象是否是必要的，也就是要先分清楚到底是出現了內存泄漏還是內存溢出。如果是內存泄漏，可進一步通過工具查看泄漏對象到GCRoots的引用鏈。於是就能找到泄漏對象是通過怎樣的路徑與GCRoots相關聯並導致垃圾收集器無法自動回收它們的。如果不存在泄漏，就是內存中的對象確實都還必須存活著，那就應當檢查虛擬機的堆參數，與機器物理內存對比看是否還可以調大，從代碼上檢查是否存在某些對象生命周期過長、持有狀態時間過長的情況，嘗試減少程序運行期的內存消耗。

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

由於在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對象的引用。在JDK1.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 optionPermSize=10M; support was removed in 8.0

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

網上搜索資料找到如下一段內容，說明其原因：

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

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

作者：codersm