內存作爲系統中重要的資源，對於系統穩定運行和高效運行起到了關鍵的作用，Java和C之類的語言不同，不需要開發人員來分配內存和回收內存，而是由JVM來管理對象內存的分配以及對象內存的回收（又稱爲垃圾回收、GC），這對於開發人員來說確實大大降低了編寫程序的難度，但帶來的一個副作用就是，當系統運行過程中出現JVM拋出的內存異常（例如OutOfMemoryError）的時候，很難知道原因是什麼，另外一方面，要編寫高性能的程序，通常需要藉助內存來提升性能，因此如何才能合理的使用內存以及讓JVM合理的進行內存的回收是必須掌握的，本節將主要分析一下JVM的內存結構。
其實對於我們一般理解的計算機內存，它算是CPU與計算機打交道最頻繁的區域，所有數據都是先經過硬盤至內存，然後由CPU再從內存中獲取數據進行處理，又將數據保存到內存，通過分頁或分片技術將內存中的數據再flush至硬盤。那JVM的內存結構到底是如何呢？JVM做爲一個運行在操作系統上，但又獨立於os運行的平臺，它的內存至少應該包括象寄存器、堆棧等區域。
JVM在運行時將數據劃分爲了6個區域來存儲，而不僅僅是大家熟知的Heap區域，這6個區域圖示如下：
下面將逐一介紹下各個區域所做的工作及其充當的功能。
PC Register(PC寄存器)
PC寄存器是一塊很小的內存區域，主要作用是記錄當前線程所執行的字節碼的行號。字節碼解釋器工作時就是通過改變當前線程的程序計數器選取下一條字節碼指令來工作的。任何分支，循環，方法調用，判斷，異常處理，線程等待以及恢復線程，遞歸等等都是通過這個計數器來完成的。
由於Java多線程是通過交替線程輪流切換並分配處理器時間的方式來實現的，在任何一個確定的時間裏，在處理器的一個內核只會執行一條線程中的指令。因此爲了線程等待結束需要恢復到正確的位置執行，每條線程都會有一個獨立的程序計數器來記錄當前指令的行號。計數器之間相互獨立互不影響，我們稱這塊內存爲“線程私有”的內存。
如果所調用的方法爲native的，則PC寄存器中不存儲任何信息。
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
堆（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的錯誤信息。
方法區域（MethodArea）
方法區域存放了所加載的類的信息（名稱、修飾符等）、類中的靜態變量、類中定義爲final類型的常量、類中的Field信息、類中的方法信息，當開發人員在程序中通過Class對象中的getName、isInterface等方法來獲取信息時，這些數據都來源於方法區域，可見方法區域的重要性。同樣，方法區域也是全局共享的，它在虛擬機啓動時在一定的條件下它也會被GC，當方法區域需要使用的內存超過其允許的大小時，會拋出OutOfMemory的錯誤信息。
在Sun JDK中這塊區域對應的爲PermanetGeneration，又稱爲持久代，默認爲64M，可通過-XX:PermSize以及-XX:MaxPermSize來指定其大小。
運行時常量池（RuntimeConstant Pool）
類似C中的符號表，存放的爲類中的固定的常量信息、方法和Field的引用信息等，其空間從方法區域中分配。類或接口的常量池在該類的class文件被java虛擬機成功裝載時分配。
本地方法堆棧（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來輔助理解分析:
(a+b)==ab
a+b是兩個變量相加，需要到運行時才能確定其值，到運行時後JVM會爲兩者相加後產生一個新的對象，因此a+b==ab的結果爲false。
(“a”+”b”)==ab
“a”+”b”是常量，在編譯時JVM已經將其變爲”ab”字符串了，而ab=”ab”也是常量，這兩者在常量池即爲同一地址，因此(“a”+”b”)==ab爲true。
result==ab
result=afinal+”b”，afinal是個final的變量， result在編譯時也已經被轉變爲了”ab”，和”ab”在常量池中同樣爲同一地址，因此result==ab爲true。
plus=ab
plus和a+b的情況是相同的，因此plus==ab爲false。
plus.intern()==ab
這裏的不同點在於調用了plus.intern()方法，這個方法的作用是獲取plus指向的常量池地址，因此plus.intern()==ab爲true。
在掌握了JVM對象內存分配的機制後，接下來看看JVM是如何做到自動的對象內存回收的，這裏指的的是Heap以及Method Area的回收，其他幾個區域的回收都由JVM簡單的按生命週期來進行管理。