理解JVM之Java記憶體區域
Java虛擬機器執行時資料區分為以下幾個部分：
方法區、虛擬機器棧、本地方法棧、堆、程式計數器。如下圖所示：
程式計數器
程式計數器可看作當前執行緒所執行的位元組碼行號指示器，位元組碼直譯器工作時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令。Java虛擬機器的多執行緒是通過執行緒輪流切換以分配處理執行時間的方式進行的，因而為了確保執行緒切換後能夠恢復到正確的執行位置，每條執行緒都有一個獨立的程式計數器，各個執行緒計數器獨立儲存，互不影響，這類記憶體區域稱為“執行緒私有”記憶體。當執行緒執行Java方法時，計數器記錄的時正在執行虛擬機器位元組碼指令的地址；如果執行Native方法，則計數器值為空(Undefine)。
程式計數器時唯一一個在Java虛擬機器規範中沒有任何規定OutOfMemoryError情況的記憶體區域。
Java虛擬機器棧
Java虛擬機器棧也是執行緒私有的，生命週期與執行緒相同。Java虛擬機器棧是描述Java方法執行的記憶體模型：每個方法執行時都會建立一個棧幀(方法執行期間的基礎資料結構)，方法的執行過程對應著相應的棧幀在虛擬機器中從入棧到出棧的過程。我們平時提到的棧就是虛擬機器棧，也稱為區域性變量表部分。
區域性變量表存放了編譯期間的各種基本資料型別、物件引用和returAdress型別。其中，double和long佔兩個區域性變數空間(Slot)，其餘資料型別佔據一個。區域性變量表所需記憶體是在編譯期間完成分配的，當進入一個方法時，方法在幀中分配的區域性變數空間大小是完全確定的，在方法執行期間區域性變量表的大小不變。
Java虛擬機器棧規定了兩種異常狀況：
- 執行緒請求棧深度大於虛擬機器所允許的深度，丟擲StackOverflowError異常。
- 虛擬機器棧可以動態擴充套件，當擴充套件時無法申請到足夠的記憶體時丟擲OutOfMemoryError異常。
本地方法棧
本地方法棧為虛擬機器使用的Native方法服務，本地方法棧可根據虛擬機器的具體要求自由實現。由的虛擬機器(如Sun HotSpot虛擬機器)直接將本地方法棧和虛擬機器棧赫爾為一。
本地方法棧出現的異常為StackOverflowError和OutOfMemoryError異常。
Java堆
Java堆(Java Heap)是Java虛擬機器記憶體中最大的一塊。堆被所有執行緒共享，在虛擬機器啟動時建立。堆的唯一目的就是存放物件例項。一般來說，幾乎所有的物件例項都在堆上分配記憶體。
Java堆是垃圾收集器管理的主要區域，因此又稱為“GC堆”。(為什麼莫名想到垃圾堆？)從記憶體回收角度由於收集器採用分代收集演算法，故將Java堆細分為新生代，老生代；從記憶體分配角度將執行緒共享的堆劃分為多個執行緒私有分配緩衝區。
Java堆處於物理不連線的記憶體空間中，只要邏輯上連續即可。如果堆中沒有記憶體完成例項分配，且堆無法再擴充套件時丟擲OutOfMemoryError異常。
方法區
方法區也是執行緒共享的記憶體區域，它用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時候編譯器編譯後的程式碼等資料。Java虛擬機器規範將方法區描述為堆的一個邏輯部分，但為與java堆進行區分，稱它為Non-Heap(非堆)。由於HotSpot虛擬機器用永久代來實現方法區，因而部分人習慣將方法區稱為“永久代”。垃圾回收在方法區是較少出現的，這個區域記憶體回收主要目標是對常量池的回收和對型別的解除安裝。當方法區無法滿足記憶體分配需求時，將丟擲OutOfMemoryError異常。
執行時常量池
執行時常量池是方法區的一部分，常量池是包含在Class檔案中的一項資訊，用於存放編譯期生成的各種自面量和符號引用，這部分資訊將在類載入後存放到方法區的執行時常量池中。一般來說，除了儲存Class檔案中的符號引用外，還會把翻譯出來的直接引用也儲存在執行時常量池中。
執行時常量池與Class檔案常量池相比具有動態性，並非時只有預置在Class檔案中的常量池內容才能進入執行時常量池，執行期間也可以將新的常量放入池中，如String的intern()方法。當常量池無法再申請到記憶體時丟擲OutOfMemoryError異常。
直接記憶體
直接記憶體並不是虛擬機器執行時資料區的一部分，但這部分記憶體被頻繁的使用，也會OutOfMemoryError異常的出現。
JDK1.4加入Input/Output類,引入基於通道(Channel)與緩衝區(Buffer)的I/O方式，它可以使用Native函式庫直接分配堆外記憶體，再通過Java堆中的DirectByteBuffer物件引用這塊記憶體，以提高效能。它一般受到本機總記憶體與處理器定址空間的限制，從而導致OutOfMemoryError異常。
本文主要參考《深入理解Java虛擬機器——JVM高階特性與最佳實踐》一書
另參考文章:
https://blog.csdn.net/u011116672/article/details/50994109