Java記憶體區域與記憶體溢位異常

概述

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

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

Java執行時資料區域

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

程式計數器

如果學習過計算機組成原理的應該很清楚，程式計數器就相當於身份證一樣，由於JVM也有自己的CPU，在執行多執行緒程式的時候，通過時間片輪轉的方式，根據程式計數器來排程執行緒的執行。

程式計數器（ Program Counter Register）是一塊較小的記憶體空間，它的作用可以看做是當前執行緒所執行的位元組碼的行號指示器。在虛擬機器的概念模型裡（僅是概念模型，各種虛擬機器可能會通過一些更高效的方式去實現），位元組碼直譯器工作時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令，分支、迴圈、跳轉、異常處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成。

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

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

Java 虛擬機器棧

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

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

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

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

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

本地方法棧

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

Java 堆

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

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

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

方法區

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

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

根據 Java 虛擬機器規範的規定，當方法區無法滿足記憶體分配需求時，將丟擲OutOfMemoryError 異常。

執行時常量池

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

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

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

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

直接記憶體

直接記憶體（ 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 異常。