現在用一張圖來介紹每個區域儲存的內容。

執行時資料區怎麼理解？
JVM執行時首先需要類載入器（classLoader）載入所需類的位元組碼檔案。載入完畢交由執行引擎執行，在執行過程中需要一段空間來儲存資料（類比CPU與主存）。這段記憶體空間的分配和釋放過程正是我們需要關心的執行時資料區。

執行時資料區
執行時資料區都包括，程式計數器，方法區（包含常量池），虛擬機器棧，本地方法棧，堆 。 JVM本身就是一臺虛擬的計算機，目的是為了實現一次編譯處處執行。

程式計數器
程式計數器是一塊較小的記憶體空間。他可以看做是當前執行緒所執行的位元組碼行號指示器。位元組碼直譯器工作就是通過改變這個計數器的值來選擇下一條需要執行的位元組碼指令。分支，迴圈，跳轉，異常，執行緒恢復等基礎功能都需要依賴這個計數器來完成。
由於JVM虛擬機器的多執行緒是通過執行緒輪流切換並分配處理器執行時間的方式實現的，在任何一個確定的時刻，一個處理器（對於多核處理器來說是一個核心）都只會執行一條執行緒中的指令。當切換到另外一條執行緒時，若不儲存當前未執行完執行緒的執行位置，下次處理機再執行這條執行緒時，又要重新開始執行。這種情況顯然是不能容忍的。因此，為了執行緒切換後能正確的恢復到執行位置，每條執行緒都需要有一個獨立的程式計數器，各條執行緒之間計數器互不影響，獨立儲存，我們稱這類記憶體區域為‘執行緒私有’記憶體，
如果執行緒正在執行的是一個java方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址，如果正在執行的是native方法，這個計數器則為（undefined）,此記憶體區域是為一個在java虛擬機器規範中沒有規定任何OutOfMemoryError情況的區域

java虛擬機器棧
與程式計數器一樣java虛擬機器也是執行緒私有的，他的生命週期與執行緒相同，虛擬機器棧描述的是java方法執行的記憶體模型：每個方法在執行的同時都會建立一個棧幀（Stack Frame，可以這麼理解棧幀，虛擬機器棧包含N個棧幀每個棧幀包含區域性變量表,運算元棧，動態連結，方法出口等資訊）。每個方法從呼叫到執行完成這個過程，就對應這一個棧幀在虛擬機器棧中的入棧到出棧的過程。
經常有人將java記憶體分為堆，棧記憶體，這其實是很粗糙的，java記憶體的劃分遠比這複雜。只能說明傳統的程式設計師最關注的，與物件記憶體分配關係最密切的就是這兩塊記憶體堆，棧。棧就是現在說的虛擬機器棧，或者說是虛擬機器棧中棧幀的區域性變量表部分。
區域性變量表存放了編譯期可知的各種基本資料型別（boolean,byte,char,short,int,float,long,double），物件引用（reference型別，他不等同於物件本身，可能是一個指向物件起始地址的引用指標，也可能是指向一個代表物件的控制代碼或其他與此相關的位置）和returnAddress型別（指向了一條位元組碼指令的地址）
其中64位長度的long和double型別會佔用2個區域性變數空間，其餘的資料型別只會佔用1個區域性變數空間。區域性變量表所需的記憶體空間在編譯期間完成記憶體分配，當進入一個方法時，這個方法需要在幀中分配多大的記憶體空間是完全確定的，在方法執行期間不會改變區域性變量表的大小。
在java虛擬機器規範中，對這個區域規定了兩種異常狀態：如果執行緒請求的棧的深度大於虛擬機器允許的深度，將丟擲StackOverFlowError異常（棧溢位），如果虛擬機器棧可以動態擴充套件（現在大部分java虛擬機器都可以動態擴充套件，只不過java虛擬機器規範中也允許固定長度的java虛擬機器棧），如果擴充套件時無法申請到足夠的記憶體空間，就會丟擲OutOfmMemoryError異常（沒有足夠的記憶體）

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

java堆
對於大多數應用來說，java堆（java Heap）是java虛擬機器管理記憶體中的最大一塊。java堆是所有執行緒共享的一塊記憶體管理區域，在虛擬機器啟動時建立。此記憶體區域唯一目的就是存放物件的例項。幾乎所有物件例項都在堆中分配記憶體。這一點在java虛擬機器規範中的描述是：所有物件例項以及陣列都要在堆上分配，但是隨著JIT編譯器的發展與逃逸技術逐漸成熟，棧上分配，標量替換優化技術將會導致一些微妙的變化發生，所有的物件都分配在堆上也不是變的那麼“絕對”了。
java堆是垃圾回收器管理的主要區域，因此很多時候也被稱為GC堆（Garbage Collected Heap）。從記憶體回收的角度來看，由於現在收集器基本都採用分代收集演算法，所以java堆中還可以細分為：新生代和年老代：在細緻一點的劃分可以分為：Eden空間，From Survivor空間，To Survivor空間等。從記憶體分配的角度來看，執行緒共享的java堆中可能劃分出多個執行緒私有的分配緩衝區 ，不過無論如何劃分，都與存放內容無關，無論哪個區域存放的都是物件例項。進一步劃分的目的是為了更好的回收記憶體，或者更快的分配記憶體。
根據java虛擬機器規範的規定，java堆可以處在物理上不連續的記憶體空間，只要邏輯上是連續的即可，就像我們的磁碟空間一樣。在實現上既可以實現成固定大小，也可以是可擴充套件的大小，不過當前主流的虛擬機器都是按照可擴充套件來實現的（通過-Xmx和-Xms控制）。如果在堆中沒有記憶體例項完成分配，並且堆也無法在擴充套件時將會丟擲OutOfMemoryError異常。

方法區
方法區和java堆一樣，是各個執行緒共享的記憶體區域，他用於儲存已被虛擬機器載入的類資訊，常量，靜態變數，即時編譯器編譯後的程式碼等資料。雖然java虛擬機器規範把方法區描述為堆的一部分，但是他還有個別名叫做Non-heap（非堆），目的應該是與java堆區分開來。
java虛擬機器規範對方法區的限制非常寬鬆，除了和java堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴充套件外，還可以選擇不實現垃圾收集。相對而言，垃圾收集在這個區域是比較少出現的，但並非資料進入了方法區就如永久代的名字一樣永久存在了。這區域的記憶體回收目標重要是針對常量池的回收和型別的解除安裝，一般來說這個記憶體區域的回收‘成績’比較難以令人滿意。尤其是型別的解除安裝條件非常苛刻，但是這部分的回收確實是必要的。在sun公司的bug列表中，曾出現過的若干個嚴重的bug就是由於低版本的HotSpot虛擬機器對此區域未完成回收導致的記憶體溢位。

這裡有三個概念需要清楚
1 常量池（Constant Pool）： 常量池資料編譯器被確定，是class檔案中的一部分，儲存了類，方法，介面等中的常量，當然也包括字串常量。
常量池：可以理解為Class檔案之中的資源倉庫，它是Class檔案結構中與其他專案資源關聯最多的資料型別
常量池中主要存放兩大類常量：字面量（Literal）和符號引用（Symbolic Reference）。
字面量：文字字串、宣告為final的常量值等；
符號引用：類和介面的完全限定名（Fully Qualified Name）、欄位的名稱和描述符（Descriptor）、方法的名稱和描述符
2 字串池/字串常量池（String Pool/String Constant Pool）：是常量池中的一部分，儲存了編譯器產生的字串型別資料

3 執行時常量池（Runtime Constant Pool）: 方法區的一部分，所有執行緒共享。虛擬機器載入class檔案後把常量池中的資料存放到執行時常量池中
這裡需要注重提一下在JDK1.6之前字串常量池是存在於方法區之中，在JDK1.7和以上字串常量池存在了堆之中。
這是官網翻譯後的中文說明：在JDK 7中，在Java堆的永久生成中不再分配interned字串，而是在Java堆的主要部分(稱為young和old generation)中分配，以及應用程式建立的其他物件。此更改將導致更多的資料駐留在主Java堆中，而在永久生成中資料更少，因此可能需要調整堆大小。由於這種變化，大多數應用程式在堆使用上只會看到相對較小的差異，但是更大的應用程式載入了許多類，或者大量使用了string . intern()方法將看到更顯著的差異。如果還有疑問可進行測試，測試參考http://blog.csdn.net/u014039577/article/details/50377805

直接記憶體
直接記憶體並不是虛擬機器執行記憶體的一部分，也不是java虛擬機器規範中定義的記憶體區域。但是這部分記憶體區域也被頻繁的使用，也可能導致OutOfMemoryError異常出現，
在jdk1.4中新加入了NIO（New Input/Output）類，引入了一種基於通道（Channel）和緩衝區（Buffer）的I/O方式，他可以使用本地的函式庫直接分配堆外記憶體，然後通過一個儲存在java堆中的DirectByteBuffer物件作為這塊記憶體的引用進行操作，這樣能在一些場景中顯著提高效能，因為避免了在java堆中和Native堆中來回複製資料。
顯然本機直接記憶體的分配不會受到java堆大小的限制，但是既然是記憶體。肯定還會受到本機總記憶體的限制。伺服器管理員在配置虛擬機器記憶體引數時，會根據實際記憶體設定-Xmx等引數資訊。但經常忽略直接記憶體，使得各個記憶體區域總和大於實體記憶體限制（包括物理和作業系統級的限制），從而導致動態擴充套件時OutOfMemoryError異常。