JAVA 虛擬機器記憶體地區劃分詳解（1）

標籤：虛擬機器記憶體地區   jvm   程式計數器   方法區   

一、概述
對於 C 和 C++程式開發的開發人員來說，在記憶體管理領域，程式員對記憶體擁有絕對的使用權，但是也要主要到正確的使用和清理記憶體，這就要求程式員有較高的水平。

而對於 Java 程式員來說，在虛擬機器的自動記憶體管理機制的協助下，不再需要為每一個 new 操作去寫配對的 delete/free 代碼，而且不容易出現記憶體流失和記憶體溢出問題，看起來由虛擬機器管理記憶體一切都很美好。不過，也正是因為 Java 程式員把記憶體控制的權力交給了 JAVA 虛擬機器，一旦出現記憶體流失和溢出方面的問題，如果不瞭解虛擬機器是怎樣使用記憶體的，那排查錯誤將會成為一項異常艱難的工作。

二、Java運行時資料區域
我們一般在開發中認為JVM不過有堆和棧兩部分組成，但是實際的JAVA 虛擬機器在執行 Java 程式的過程中會把它所管理的記憶體劃分為若干個不同的資料區域。這些地區都有各自的用途，以及建立和銷毀的時間，有的地區隨著虛擬機器進程的啟動而存在，有些地區則是依賴使用者線程的啟動和結束而建立和銷毀。如：

下邊是網上摘下來的圖，僅供參考：

接下來詳細解說中的各地區的功能：
（1）程式計數器

如果學習過電腦群組成原理的應該很清楚，程式計數器就相當於身份證一樣，由於JVM也有自己的CPU，在執行多線程程式的時候，通過時間片輪轉的方式，根據程式計數器來調度線程的執行。
程式計數器（ Program Counter Register）是一塊較小的記憶體空間，它的作用可以看做是當前線程所執行的位元組碼的行號指標。在虛擬機器的概念性模型裡（僅是概念性模型，各種虛擬機器可能會通過一些更高效的方式去實現），位元組碼解譯器工作時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令，分支、迴圈、跳轉、異常處理、線程恢複等基礎功能都需要依賴這個計數器來完成。
由於 JAVA 虛擬機器的多線程是通過線程輪流切換並分配處理器執行時間的方式來實現的，在任何一個確定的時刻，一個處理器（對於多核處理器來說是一個核心）只會執行一條線程中的指令。因此，為了線程切換後能恢複到正確的執行位置，每條線程都需要有一個獨立的程式計數器，各條線程之間的計數器互不影響，隔離儲存區 (Isolated Storage)，我們稱這類記憶體地區為“線程私人”的記憶體。

如果線程正在執行的是一個 Java 方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是 Natvie 方法，這個計數器值則為空白（ Undefined）。此記憶體地區是唯一一個在JAVA 虛擬機器規範中沒有規定任何 OutOfMemoryError 情況的地區。

（2）JAVA 虛擬機器棧

與程式計數器一樣， JAVA 虛擬機器棧（ Java Virtual Machine Stacks）也是線程私人的，它的生命週期與線程相同。
虛擬機器棧描述的是 Java 方法執行的記憶體模型：每個方法被執行的時候都會同時建立一個棧幀（ Stack Frame①）用於儲存局部變數表、操作棧、動態連結、方法出口等資訊。每一個方法被調用直至執行完成的過程，就對應著一個棧幀在虛擬機器棧中從入棧到出棧的過程。

經常有人把 Java 記憶體區分為堆記憶體（ Heap）和棧記憶體（ Stack），這種分法比較粗糙， Java 記憶體地區的劃分實際上遠比這複雜。這種劃分方式的流行只能說明大多數程式員最關注的、與對象記憶體配置關係最密切的記憶體地區是這兩塊。其中所指的“堆”在後面會專門講述，而所指的“棧”就是現在講的虛擬機器棧，或者說是虛擬機器棧中的局部變數表部分。

局部變數表存放了編譯期可知的各種基礎資料型別 (Elementary Data Type)（ boolean、 byte、 char、 short、 int、 float、long、 double）、對象引用（ reference 類型，它不等同於對象本身，根據不同的虛擬機器實現，它可能是一個指向對象起始地址的引用指標，也可能指向一個代表對象的控制代碼或者其他與此對象相關的位置）和 returnAddress 類型（指向了一條位元組碼指令的地址）。

其中 64 位元長度的 long 和 double 類型的資料會佔用 2 個局部變數空間（Slot），其餘的資料類型只佔用 1 個。局部變數表所需的記憶體空間在編譯期間完成分配，當進入一個方法時，這個方法需要在幀中分配多大的局部變數空間是完全確定的，在方法運行期間不會改變局部變數表的大小。

在 JAVA 虛擬機器規範中，對這個地區規定了兩種異常狀況：如果線程請求的棧深度大於虛擬機器所允許的深度，將拋出 StackOverflowError 異常；如果虛擬機器棧可以動態擴充（當前大部分的 JAVA 虛擬機器都可動態擴充，只不過 JAVA 虛擬機器規範中也允許固定長度的虛擬機器棧），當擴充時無法申請到足夠的記憶體時會拋出 OutOfMemoryError 異常。

（3）本地方法棧

本地方法棧（ Native Method Stacks）與虛擬機器棧所發揮的作用是非常相似的，其區別不過是虛擬機器棧為虛擬機器執行 Java 方法（也就是位元組碼）服務，而本地方法棧則是為虛擬機器使用到的 Native方法服務。虛擬機器規範中對本地方法棧中的方法使用的語言、使用方式與資料結構並沒有強制規定，因此具體的虛擬機器可以自由實現它。甚至有的虛擬機器（譬如 Sun HotSpot 虛擬機器）直接就把本地方法
棧和虛擬機器棧合二為一。與虛擬機器棧一樣，本地方法棧地區也會拋出StackOverflowError 和OutOfMemoryError 異常。

（4）Java 堆

對於大多數應用來說， Java 堆（ Java Heap）是 JAVA 虛擬機器所管理的記憶體中最大的一塊。 Java堆是被所有線程共用的一塊記憶體地區，在虛擬機器啟動時建立。此記憶體地區的唯一目的就是存放對象執行個體，幾乎所有的對象執行個體都在這裡分配記憶體。這一點在 JAVA 虛擬機器規範中的描述是：所有的對象執行個體以及數組都要在堆上分配，但是隨著 JIT 編譯器的發展與逃逸分析技術的逐漸成熟，棧上分配、標量替換最佳化技術將會導致一些微妙的變化發生，所有的對象都分配在堆上也漸漸層得不是那麼“絕對”了。

Java 堆是垃圾收集器管理的主要區域，因此很多時候也被稱做“GC 堆（ ” Garbage Collected Heap，幸好國內沒翻譯成“垃圾堆”）。如果從記憶體回收的角度看，由於現在收集器基本都是採用的分代收集演算法，所以 Java 堆中還可以細分為：新生代和老年代；再細緻一點的有 Eden 空間、 From Survivor空間、 To Survivor 空間等。如果從記憶體配置的角度看，線程共用的 Java 堆中可能劃分出多個線程私人的分配緩衝區（ Thread Local Allocation Buffer， TLAB）。不過，無論如何劃分，都與存放內容無關，無論哪個地區，儲存的都仍然是對象執行個體，進一步劃分的目的是為了更好地回收記憶體，或者更快地分配記憶體。在本章中，我們僅僅針對記憶體地區的作用進行討論， Java 堆中的上述各個地區的分配
和回收等細節將會是下一章的主題。

根據 JAVA 虛擬機器規範的規定， Java 堆可以處於物理上不連續的記憶體空間中，只要邏輯上是連續的即可，就像我們的磁碟空間一樣。在實現時，既可以實現成固定大小的，也可以是可擴充的，不過當前主流的虛擬機器都是按照可擴充來實現的（通過-Xmx 和-Xms 控制）。如果在堆中沒有記憶體完成執行個體分配，並且堆也無法再擴充時，將會拋出 OutOfMemoryError 異常。

（5）方法區

方法區（ Method Area）與 Java 堆一樣，是各個線程共用的記憶體地區，它用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的代碼等資料。雖然 JAVA 虛擬機器規範把方法區描述為堆的一個邏輯部分，但是它卻有一個別名叫做 Non-Heap（非堆），目的應該是與 Java 堆區分開來。

JAVA 虛擬機器規範對這個地區的限制非常寬鬆，除了和 Java 堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴充外，還可以選擇不實現垃圾收集。相對而言，垃圾收集行為在這個地區是比較少出現的，但並非資料進入了方法區就如永久代的名字一樣“永久”存在了。這個地區的記憶體回收目標主要是針對常量池的回收和對類型的卸載，一般來說這個地區的回收“成績”比較難以令人滿意，尤其是類型的卸載，條件相當苛刻，但是這部分地區的回收確實是有必要的。

根據 JAVA 虛擬機器規範的規定，當方法區無法滿足記憶體配置需求時，將拋出 OutOfMemoryError 異常。

（6）運行時常量池

運行時常量池（ Runtime Constant Pool）是方法區的一部分。 Class 檔案中除了有類的版本、欄位、方法、介面等描述等資訊外，還有一項資訊是常量池（ Constant Pool Table），用於存放編譯期產生的各種字面量和符號引用，這部分內容將在類載入後存放到方法區的運行時常量池中。

JAVA 虛擬機器對 Class 檔案的每一部分（自然也包括常量池）的格式都有嚴格的規定，每一個位元組用於儲存哪種資料都必須符合規範上的要求，這樣才會被虛擬機器認可、裝載和執行。但對於運行時常量池， JAVA 虛擬機器規範沒有做任何細節的要求，不同的供應商實現的虛擬機器可以按照自己的需要來實現這個記憶體地區。不過，一般來說，除了儲存 Class 檔案中描述的符號引用外，還會把翻譯出來的直
接引用也儲存在運行時常量池中。

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

既然運行時常量池是方法區的一部分，自然會受到方法區記憶體的限制，當常量池無法再申請到記憶體時會拋出 OutOfMemoryError 異常。

（7）直接記憶體

直接記憶體（ Direct Memory）並不是虛擬機器運行時資料區的一部分，也不是 JAVA 虛擬機器規範中定義的記憶體地區，但是這部分記憶體也被頻繁地使用，而且也可能導致 OutOfMemoryError 異常出現。

在 JDK 1.4 中新加入了 NIO （ New Input/Output）類，引入了一種基於通道（ Channel）與緩衝區（ Buffer）的 I/O 方式，它可以使用 Native 函數庫直接分配堆外記憶體，然後通過一個儲存在 Java 堆裡面的DirectByteBuffer 對象作為這塊記憶體的引用進行操作。這樣能在一些情境中顯著提高效能，因為避免了在 Java 堆和 Native 堆中來回複製資料。

顯然，本機直接記憶體的分配不會受到 Java 堆大小的限制，但是，既然是記憶體，則肯定還是會受到本機總記憶體（包括 RAM 及 SWAP 區或者分頁檔案）的大小及處理器定址空間的限制。伺服器管理員配置虛擬機器參數時，一般會根據實際記憶體設定-Xmx 等參數資訊，但經常會忽略掉直接記憶體，使得各個記憶體地區的總和大於實體記憶體限制（包括物理上的和作業系統級的限制），從而導致動態擴充時
出現 OutOfMemoryError 異常。

JAVA 虛擬機器記憶體地區劃分詳解（1）