其實對于我們一般理解的計算機內存，它算是CPU與計算機打交道最頻繁的區域，所有數據都是先經過硬盤至內存，然后由CPU再從內存中獲取數據進行處理，又將數據保存到內存，通過分頁或分片技術將內存中的數據再flush至硬盤。那JVM的內存結構到底是如何呢？JVM做為一個運行在操作系統上，但又獨立于os運行的平臺，它的內存至少應該包括象寄存器、堆棧等區域。

JVM在運行時將數據劃分為了6個區域來存儲，而不僅僅是大家熟知的Heap區域，這6個區域圖示如下：

 JVM內存的分配結構示意圖

下面將逐一介紹下各個區域所做的工作及其充當的功能。

PC Register(PC寄存器)

PC寄存器是一塊很小的內存區域，主要作用是記錄當前線程所執行的字節碼的行號。字節碼解釋器工作時就是通過改變當前線程的程序計數器選取下一條字節碼指令來工作的。任何分支，循環，方法調用，判斷，異常處理，線程等待以及恢復線程，遞歸等等都是通過這個計數器來完成的。

 由于Java多線程是通過交替線程輪流切換并分配處理器時間的方式來實現的，在任何一個確定的時間里，在處理器的一個內核只會執行一條線程中的指令。因此為了線程等待結束需要恢復到正確的位置執行，每條線程都會有一個獨立的程序計數器來記錄當前指令的行號。計數器之間相互獨立互不影響，我們稱這塊內存為“線程私有”的內存。

如果所調用的方法為native的，則PC寄存器中不存儲任何信息。

l  JVM棧

JVM棧是線程私有的，每個線程創建的同時都會創建JVM棧，JVM棧中存放的為當前線程中局部基本類型的變量（java中定義的八種基本類型：boolean、char、byte、short、int、long、float、double）、部分的返回結果以及Stack Frame，非基本類型的對象在JVM棧上僅存放一個指向堆上的地址，因此Java中基本類型的變量是值傳遞，而非基本類型的變量是引用傳遞，Sun           JDK的實現中JVM棧的空間是在物理內存上分配的，而不是從堆上分配。

由于JVM棧是線程私有的，因此其在內存分配上非常高效，并且當線程運行完畢后，這些內存也就被自動回收。

當JVM棧的空間不足時，會拋出StackOverflowError的錯誤，在Sun JDK中可以通過-Xss來指定棧的大小，例如如下代碼：

new Thread(new Runnable(){ 
           public void run() { 
              loop(0); 
           }        
           private void loop (int i){ 
              if(i!=1000){ 
                  i++; 
loop (i); 
              } 
              else{ 
                  return; 
              } 
           } 
          }).start(); 

當JVM參數設置為-Xss1K，運行后會報出類似下面的錯誤：

Exception in thread "Thread-0"java.lang.StackOverflowError

l  堆（Heap）

Heap是大家最為熟悉的區域，它是JVM用來存儲對象實例以及數組值的區域，可以認為Java中所有通過new創建的對象的內存都在此分配，Heap中的對象的內存需要等待GC進行回收，Heap在32位的操作系統上***為2G，在64位的操作系統上則沒有限制，其大小通過-Xms和-Xmx來控制，-Xms為JVM啟動時申請的最小Heap內存，默認為物理內存的1/64但小于1G，-Xmx為JVM可申請的***Heap內存，默認為物理內存的1/4，默認當空余堆內存小于40%時，JVM會增大Heap的大小到-Xmx指定的大小，可通過-XX:MinHeapFreeRatio=來指定這個比例，當空余堆內存大于70%時，JVM會將Heap的大小往-Xms指定的大小調整，可通過-XX:MaxHeapFreeRatio=來指定這個比例，但對于運行系統而言，為了避免頻繁的Heap Size的大小，通常都會將-Xms和-Xmx的值設成一樣，因此這兩個用于調整比例的參數通常是沒用的。其實jvm中對于堆內存的分配、使用、管理、收集等有更為精巧的設計，具體可以在JVM堆內存分析中進行詳細介紹。

當堆中需要使用的內存超過其允許的大小時，會拋出OutOfMemory的錯誤信息。

l  方法區域（MethodArea）

方法區域存放了所加載的類的信息（名稱、修飾符等）、類中的靜態變量、類中定義為final類型的常量、類中的Field信息、類中的方法信息，當開發人員在程序中通過Class對象中的getName、isInterface等方法來獲取信息時，這些數據都來源于方法區域，可見方法區域的重要性。同樣，方法區域也是全局共享的，它在虛擬機啟動時在一定的條件下它也會被GC，當方法區域需要使用的內存超過其允許的大小時，會拋出OutOfMemory的錯誤信息。

在Sun JDK中這塊區域對應的為PermanetGeneration，又稱為持久代，默認為64M，可通過-XX:PermSize以及-XX:MaxPermSize來指定其大小。

l  運行時常量池（RuntimeConstant Pool）

類似C中的符號表，存放的為類中的固定的常量信息、方法和Field的引用信息等，其空間從方法區域中分配。類或接口的常量池在該類的class文件被java虛擬機成功裝載時分配。

l  本地方法堆棧（NativeMethod Stacks）

JVM采用本地方法堆棧來支持native方法的執行，此區域用于存儲每個native方法調用的狀態。

例如有這么一段代碼：

public class A { 
                   public static void main(String[]args){ 
           String a="a"; 
          String b="b"; 
           String ab="ab"; 
           System.out.println((a+b)==ab);       // false 
           System.out.println(("a"+"b")==ab);   // true 
           final String afinal="a"; 
           String result=afinal+"b"; 
           System.out.println(result==ab);      // true 
           String plus=a+"b"; 
           System.out.println(plus==ab);        // false 
             System.out.println(plus.intern()==ab);  // true 
    } 
} 

分析下上面代碼執行的結果，可通過javap –verbose A來輔助理解分析。

l  (a+b)==ab

a+b是兩個變量相加，需要到運行時才能確定其值，到運行時后JVM會為兩者相加后產生一個新的對象，因此a+b==ab的結果為false。

l  (“a”+”b”)==ab

“a”+”b”是常量，在編譯時JVM已經將其變為”ab”字符串了，而ab=”ab”也是常量，這兩者在常量池即為同一地址，因此(“a”+”b”)==ab為true。

l  result==ab

result=afinal+”b”，afinal是個final的變量， result在編譯時也已經被轉變為了”ab”，和”ab”在常量池中同樣為同一地址，因此result==ab為true。

l  plus=ab

plus和a+b的情況是相同的，因此plus==ab為false。

l  plus.intern()==ab

這里的不同點在于調用了plus.intern()方法，這個方法的作用是獲取plus指向的常量池地址，因此plus.intern()==ab為true。

在掌握了JVM對象內存分配的機制后，接下來看看JVM是如何做到自動的對象內存回收的，這里指的的是Heap以及Method Area的回收，其他幾個區域的回收都由JVM簡單的按生命周期來進行管理

原文鏈接：http://blog.csdn.net/zhaozheng7758/article/details/8623562

 【編輯推薦】