根據《Java 虛擬機規范》的規定，Java 虛擬機所管理的內存一共分為Method Area（方法區）、VM Stack（虛擬機棧）、Native Method Stack（本地方法棧）、Heap（堆）、Program Counter Register（程序計數器）五個區域。這些區域都有各自的用途，以及創建和銷毀的時間，有的隨著虛擬機進程啟動而存在，有的區域則依賴于用戶線程的啟動和結束而建立和銷毀。
Program Counter Register
程序計數器可以看成為當前線程所執行的字節碼的行號指示器，使用一塊較小的空間記錄正在執行的虛擬機字節碼的指令地址。字節碼解釋器工作時，通過改變線程計數器的值來選取下一條需要執行的指令。包括分支、循環、跳轉、異常福利、線程恢復等功能都是依賴它完成。為此，每一個程序計數器都是由線程私有，獨立存儲，互不影響。
VM Stack
VM Stack 描述的是 Java 方法執行的內存模型：每個方法在執行的同時都會創建一個棧幀用于存儲局部變量表、操作數棧、動態鏈接、方法出口等信息。每個方法的從調用至執行完成的過程，對應著一個棧幀在 VM stack 中入棧和出站的過程。
其中局部變量表中存放著編譯可知的各種基本類型（bolean、byte、char、short、int、long、double、float）、對象應用類型（不是對象本身）和 returnAddress 類型（指向一條字節碼指令的地址）。局部變量表所需內存的大小在編譯期間根據數據類型完成的分配，所以大小是確定的，運行期間不會改變。其中 long 和 double 類型的數據會占用兩個局部變量類型空間（Slot），其余的數據類型只會占用一個。
在 JVM 規范中，如果線程請求的棧大于了 JVM 所允許的深度，則會拋出 StackOverflowError ; 如果 VM Stack 可以動態擴展，當擴展時無法申請到足夠的內存，則會拋出 OutOfMemoryError。
不難看出 VM Stack 也是屬于線程私有，他的生命周期和線程相同。
Native Method Stack
Native Method Stack 與 VM Stack 的作用非常的相似，他們的區別在于: VM Stack 服務的是虛擬機執行的 Java 方法，而 Native Method Stack 服務的對象是 Native 防范。與 VM Stack 一樣，也會拋出 StackOverflowError 和 OutOfMemoryError 異常
而 JVM 規范并沒有限制Native Method Stack 中使用的語言、使用方式以及使用的數據結構，由 JVM 自由實現。介于此，在 Sun 的 Hotspot 實現中已經將 Native Method Stack 和 VM Stack 合二為一。
Heap
Heap 是 JVM 管理的內存中最大的一塊，用于存放對象實例，幾乎所有的對象實例以及數組都在這里分配內存，同時也是被所有線程所共享的，它的生命周期和 JVM 一致。
GC 管理也就是管理這部分區域。由于現在Garbage Collected 采用都是分代回收算法，因此從內存回收的角度來講，分為新生代和老年代。在細致一點，分為 Eden 空間、From Survivor 空間、 To Survivor 空間。從內存分配的角度來看，線程共享的Java堆中可能劃分出多個線程私有的分配緩沖區（Thread Local Allocation buffer），即TLAB。不管怎么劃分，其實都是為了更好的回收、分配內存。
Java Heap 所使用的內存在物理是不需要連續的，只要邏輯上是連續的即可。Java Heap 的容量可以是固定大小，也可以隨著需求動態擴展（-Xms 和- Xmx），并在不需要過多空間時自動收縮。如果堆中沒有內存完成實例分配并且堆也無法擴展，就會拋OutOfMemoryError。
Method Area
方法區與Java堆一樣，是各個線程共享的內存區域，用于存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。
一般來說， 無論是訪問對象的屬性， 亦或調用對象的方法等，其實操縱的是類的實例對象。 于是這里便會引出這樣的一個問題，JVM 是如何知道如何創建對象的？我們都了解，對象的創建依賴對象所屬類的類信息，那么這些類的信息是怎么存儲的呢？其實，Method Area 就是存儲類信息的區域。再者，我們的類信息是怎么存儲到Method Aread的？這是另外一個領域的事情了--類的加載機制，類加載機制將會 class 文件中的信息，并將這些信息存放到 Method Area。Java虛擬機規范規定，當方法區無法滿足內存分配需求時，講拋出OutOfMemoryError異常。
這里需要特別指明一下運行時常量池，它是方法區的一部分。Class文件中除了有類的版本、字段、方法、接口等描述等信息外，還有一項信息是常量池（Constant Pool Table），用于存放編譯期生成的各種字面量和符號引用，這部分內容將在類加載后存放到方法區的運行時常量池中。
Java虛擬機對Class文件的每一部分（自然也包括常量池）的格式都有嚴格的規定，每一個字節用于存儲哪種數據都必須符合規范上的要求，這樣才會被虛擬機認可、裝載和執行。但對于運行時常量池，Java虛擬機規范沒有做任何細節的要求，不同的提供商實現的虛擬機可以按照自己的需要來實現這個內存區域。不過，一般來說，除了保存Class文件中描述的符號引用外，還會把翻譯出來的直接引用也存儲在運行時常量池中。
運行時常量池相對于Class文件常量池的另外一個重要特征是具備動態性，Java語言并不要求常量一定只能在編譯期產生，也就是并非預置入Class文件中常量池的內容才能進入方法區運行時常量池，運行期間也可能將新的常量放入池中，這種特性被開發人員利用得比較多的便是String類的intern()方法。
既然運行時常量池是方法區的一部分，自然會受到方法區內存的限制，當常量池無法再申請到內存時會拋出OutOfMemoryError異常。
Direct Memory（這部分不是虛擬機運行時數據區的一部分）
直接內存（Direct Memory）并不是虛擬機運行時數據區的一部分，也不是Java虛擬機規范中定義的內存區域，但是這部分內存也被頻繁地使用，而且也可能導致OutOfMemoryError異常出現(不過這里拋出內存溢出多半都是因為系統總內存不夠)。
JDK1.4加的NIO中，ByteBuffer有個方法是allocateDirect(int capacity) ，這是一種基于通道（Channel）與緩沖區（Buffer）的I/O方式，它可以使用Native函數庫直接分配堆外內存，然后通過一個存儲在Java堆里面的DirectByteBuffer對象作為這塊內存的引用進行操作。這樣能在一些場景中顯著提高性能，因為避免了在Java堆和Native堆中來回復制數據。（加入這片內存的目的就是提高性能）
顯然，本機直接內存的分配不會受到Java堆大小的限制，但是，既然是內存，則肯定還是會受到本機總內存（包括RAM及SWAP區或者分頁文件）的大小及處理器尋址空間的限制。服務器管理員配置虛擬機參數時，一般會根據實際內存設置-Xmx等參數信息，但經常會忽略掉直接內存，使得各個內存區域的總和大于物理內存限制（包括物理上的和操作系統級的限制），從而導致動態擴展時出現OutOfMemoryError異常。
Thread Memory Model
綜上所述，線程內存模型如下：
