參考資料：

《深入理解java虛擬機器》

  https://www.cnblogs.com/dolphin0520/p/3613043.html

目錄

一：記憶體模型

二：分別作用

1.程式計數器

2.Java棧

3.本地方法棧

4.堆

5.方法區

6.直接記憶體

一：記憶體模型

根據《Java虛擬機器規範》的規定，執行時資料區通常包括這幾個部分：程式計數器(Program Counter Register)、Java棧(VM Stack)、本地方法棧(Native Method Stack)、方法區(Method Area)、堆(Heap)。

　　如上圖所示，JVM中的執行時資料區應該包括這些部分。在JVM規範中雖然規定了程式在執行期間執行時資料區應該包括這幾部分，但是至於具體如何實現並沒有做出規定，不同的虛擬機器廠商可以有不同的實現方式。

二：分別作用

1.程式計數器

　　程式計數器（Program Counter Register），也有稱作為PC暫存器。想必學過組合語言的朋友對程式計數器這個概念並不陌生，在組合語言中，程式計數器是指CPU中的暫存器，它儲存的是程式當前執行的指令的地址（也可以說儲存下一條指令的所在儲存單元的地址），當CPU需要執行指令時，需要從程式計數器中得到當前需要執行的指令所在儲存單元的地址，然後根據得到的地址獲取到指令，在得到指令之後，程式計數器便自動加1或者根據轉移指標得到下一條指令的地址，如此迴圈，直至執行完所有的指令。

　　雖然JVM中的程式計數器並不像組合語言中的程式計數器一樣是物理概念上的CPU暫存器，但是JVM中的程式計數器的功能跟組合語言中的程式計數器的功能在邏輯上是等同的，也就是說是用來指示執行哪條指令的。

　　由於在JVM中，多執行緒是通過執行緒輪流切換來獲得CPU執行時間的，因此，在任一具體時刻，一個CPU的核心只會執行一條執行緒中的指令，因此，為了能夠使得每個執行緒都線上程切換後能夠恢復在切換之前的程式執行位置，每個執行緒都需要有自己獨立的程式計數器，並且不能互相被幹擾，否則就會影響到程式的正常執行次序。因此，可以這麼說，程式計數器是每個執行緒所私有的。

　　在JVM規範中規定，如果執行緒執行的是非native方法，則程式計數器中儲存的是當前需要執行的指令的地址；如果執行緒執行的是native方法，則程式計數器中的值是undefined。

　　由於程式計數器中儲存的資料所佔空間的大小不會隨程式的執行而發生改變，因此，對於程式計數器是不會發生記憶體溢位現象(OutOfMemory)的。

2.Java棧

　　Java棧也稱作虛擬機器棧（Java Vitual Machine Stack），也就是我們常常所說的棧，跟C語言的資料段中的棧類似。事實上，Java棧是Java方法執行的記憶體模型。為什麼這麼說呢？下面就來解釋一下其中的原因。

　　Java棧中存放的是一個個的棧幀，每個棧幀對應一個被呼叫的方法，在棧幀中包括區域性變量表(Local Variables)、運算元棧(Operand Stack)、指向當前方法所屬的類的執行時常量池（執行時常量池的概念在方法區部分會談到）的引用(Reference to runtime constant pool)、方法返回地址(Return Address)和一些額外的附加資訊。當執行緒執行一個方法時，就會隨之建立一個對應的棧幀，並將建立的棧幀壓棧。當方法執行完畢之後，便會將棧幀出棧。因此可知，執行緒當前執行的方法所對應的棧幀必定位於Java棧的頂部。講到這裡，大家就應該會明白為什麼 在 使用 遞迴方法的時候容易導致棧記憶體溢位的現象了以及為什麼棧區的空間不用程式設計師去管理了（當然在Java中，程式設計師基本不用關係到記憶體分配和釋放的事情，因為Java有自己的垃圾回收機制），這部分空間的分配和釋放都是由系統自動實施的。對於所有的程式設計語言來說，棧這部分空間對程式設計師來說是不透明的。下圖表示了一個Java棧的模型：

　　區域性變量表，顧名思義，想必不用解釋大家應該明白它的作用了吧。就是用來儲存方法中的區域性變數（包括在方法中宣告的非靜態變數以及函式形參）。對於基本資料型別的變數，則直接儲存它的值，對於引用型別的變數，則存的是指向物件的引用。區域性變量表的大小在編譯器就可以確定其大小了，因此在程式執行期間區域性變量表的大小是不會改變的。

　　運算元棧，想必學過資料結構中的棧的朋友想必對錶達式求值問題不會陌生，棧最典型的一個應用就是用來對錶達式求值。想想一個執行緒執行方法的過程中，實際上就是不斷執行語句的過程，而歸根到底就是進行計算的過程。因此可以這麼說，程式中的所有計算過程都是在藉助於運算元棧來完成的。

　　指向執行時常量池的引用，因為在方法執行的過程中有可能需要用到類中的常量，所以必須要有一個引用指向執行時常量。

　　方法返回地址，當一個方法執行完畢之後，要返回之前呼叫它的地方，因此在棧幀中必須儲存一個方法返回地址。

　　由於每個執行緒正在執行的方法可能不同，因此每個執行緒都會有一個自己的Java棧，互不干擾。

3.本地方法棧

　　本地方法棧與Java棧的作用和原理非常相似。區別只不過是Java棧是為執行Java方法服務的，而本地方法棧則是為執行本地方法（Native Method）服務的。在JVM規範中，並沒有對本地方發展的具體實現方法以及資料結構作強制規定，虛擬機器可以自由實現它。在HotSopt虛擬機器中直接就把本地方法棧和Java棧合二為一。

4.堆

　　在C語言中，堆這部分空間是唯一一個程式設計師可以管理的記憶體區域。程式設計師可以通過malloc函式和free函式在堆上申請和釋放空間。那麼在Java中是怎麼樣的呢？

　　Java中的堆是用來儲存物件本身的以及陣列（當然，陣列引用是存放在Java棧中的）。只不過和C語言中的不同，在Java中，程式設計師基本不用去關心空間釋放的問題，Java的垃圾回收機制會自動進行處理。因此這部分空間也是Java垃圾收集器管理的主要區域。另外，堆是被所有執行緒共享的，在JVM中只有一個堆。

5.方法區

　　方法區在JVM中也是一個非常重要的區域，它與堆一樣，是被執行緒共享的區域。在方法區中，儲存了每個類的資訊（包括類的名稱、方法資訊、欄位資訊）、靜態變數、常量以及編譯器編譯後的程式碼等。

　　在Class檔案中除了類的欄位、方法、介面等描述資訊外，還有一項資訊是常量池，用來儲存編譯期間生成的字面量和符號引用。

　　在方法區中有一個非常重要的部分就是執行時常量池，它是每一個類或介面的常量池的執行時表示形式，在類和介面被載入到JVM後，對應的執行時常量池就被創建出來。當然並非Class檔案常量池中的內容才能進入執行時常量池，在執行期間也可將新的常量放入執行時常量池中，比如String的intern方法(intern方法可參考部落格:https://blog.csdn.net/w372426096/article/details/80812903)。

　　在JVM規範中，沒有強制要求方法區必須實現垃圾回收。很多人習慣將方法區稱為“永久代”，是因為HotSpot虛擬機器以永久代來實現方法區，從而JVM的垃圾收集器可以像管理堆區一樣管理這部分割槽域，從而不需要專門為這部分設計垃圾回收機制。不過自從JDK7之後，Hotspot虛擬機器便將執行時常量池從永久代移除了。

jdk1.8中則把永久代給完全刪除了，取而代之的是metaspace(元空間)，執行時常量池和靜態變數都儲存到了堆中，MetaSpace儲存類的元資料，MetaSpace直接申請在本地記憶體中（Native memory）,這樣類的元資料分配只受本地記憶體大小的限制,OOM問題就不存在了

6.直接記憶體

• 直接記憶體並不是虛擬機器執行時資料區的一部分，也不是Java 虛擬機器規範中農定義的記憶體區域。在JDK1.4 中新加入了NIO(New Input/Output)類，引入了一種基於通道(Channel)與緩衝區（Buffer）的I/O 方式，它可以使用native 函式庫直接分配堆外記憶體，然後通脫一個儲存在Java堆中的DirectByteBuffer 物件作為這塊記憶體的引用進行操作。這樣能在一些場景中顯著提高效能，因為避免了在Java堆和Native堆中來回複製資料。

• 本機直接記憶體的分配不會受到Java 堆大小的限制，受到本機總記憶體大小限制

• 配置虛擬機器引數時，不要忽略直接記憶體 防止出現OutOfMemoryError異常

 直接記憶體（堆外記憶體）與堆記憶體比較

• 直接記憶體申請空間耗費更高的效能，當頻繁申請到一定量時尤為明顯
• 直接記憶體IO讀寫的效能要優於普通的堆記憶體，在多次讀寫操作的情況下差異明顯