一、JVM結構

根據《java虛擬機器規範》規定，JVM的基本結構一般如下圖所示：

從左圖可知，JVM主要包括四個部分：

1.類載入器（ClassLoader）:在JVM啟動時或者在類執行時將需要的class載入到JVM中。（右圖表示了從java原始檔到JVM的整個過程，可配合理解。 關於類的載入機制，可以參考http://blog.csdn.net/tonytfjing/article/details/47212291）

2.執行引擎：負責執行class檔案中包含的位元組碼指令（執行引擎的工作機制，這裡也不細說了，這裡主要介紹JVM結構）；

3.記憶體區（也叫執行時資料區）：是在JVM執行的時候操作所分配的記憶體區。執行時記憶體區主要可以劃分為5個區域，如圖：

• 方法區(Method Area)：用於儲存類結構資訊的地方，包括常量池、靜態變數、建構函式等。雖然JVM規範把方法區描述為堆的一個邏輯部分， 但它卻有個別名non-heap（非堆），所以大家不要搞混淆了。方法區還包含一個執行時常量池。
  

• java堆(Heap)：儲存java例項或者物件的地方。這塊是GC的主要區域（後面解釋）。從儲存的內容我們可以很容易知道，方法區和堆是被所有java執行緒共享的。
  

• java棧(Stack)：java棧總是和執行緒關聯在一起，每當建立一個執行緒時，JVM就會為這個執行緒建立一個對應的java棧。在這個java棧中又會包含多個棧幀，每執行一個方法就建立一個棧幀，用於儲存區域性變量表、操作棧、方法返回值等。每一個方法從呼叫直至執行完成的過程，就對應一個棧幀在java棧中入棧到出棧的過程。所以java棧是現成私有的。
  

• 程式計數器(PC Register)：用於儲存當前執行緒執行的記憶體地址。由於JVM程式是多執行緒執行的（執行緒輪流切換），所以為了保證執行緒切換回來後，還能恢復到原先狀態，就需要一個獨立的計數器，記錄之前中斷的地方，可見程式計數器也是執行緒私有的。
  

• 本地方法棧(Native Method Stack)：和java棧的作用差不多，只不過是為JVM使用到的native方法服務的。
  

二、記憶體分配

我覺得了解垃圾回收之前，得先了解JVM是怎麼分配記憶體的，然後識別哪些記憶體是垃圾需要回收，最後才是用什麼方式回收。

Java的記憶體分配原理與C/C++不同，C/C++每次申請記憶體時都要malloc進行系統呼叫，而系統呼叫發生在核心空間，每次都要中斷進行切換，這需要一定的開銷，而Java虛擬機器是先一次性分配一塊較大的空間，然後每次new時都在該空間上進行分配和釋放，減少了系統呼叫的次數，節省了一定的開銷，這有點類似於記憶體池的概念；二是有了這塊空間過後，如何進行分配和回收就跟GC機制有關了。

java一般記憶體申請有兩種：靜態記憶體和動態記憶體。很容易理解，編譯時就能夠確定的記憶體就是靜態記憶體，即記憶體是固定的，系統一次性分配，比如int型別變數；動態記憶體分配就是在程式執行時才知道要分配的儲存空間大小，比如java物件的記憶體空間。根據上面我們知道，java棧、程式計數器、本地方法棧都是執行緒私有的，執行緒生就生，執行緒滅就滅，棧中的棧幀隨著方法的結束也會撤銷，記憶體自然就跟著回收了。所以這幾個區域的記憶體分配與回收是確定的，我們不需要管的。但是java堆和方法區則不一樣，我們只有在程式執行期間才知道會建立哪些物件，所以這部分記憶體的分配和回收都是動態的。一般我們所說的垃圾回收也是針對的這一部分。

總之Stack的記憶體管理是順序分配的，而且定長，不存在記憶體回收問題；而Heap 則是為java物件的例項隨機分配記憶體，不定長度，所以存在記憶體分配和回收的問題；

三、垃圾檢測、回收演算法

垃圾收集器一般必須完成兩件事：檢測出垃圾；回收垃圾。怎麼檢測出垃圾？一般有以下幾種方法：

引用計數法：給一個物件新增引用計數器，每當有個地方引用它，計數器就加1；引用失效就減1。

好了，問題來了，如果我有兩個物件A和B，互相引用，除此之外，沒有其他任何物件引用它們，實際上這兩個物件已經無法訪問，即是我們說的垃圾物件。但是互相引用，計數不為0，導致無法回收，所以還有另一種方法：

可達性分析演算法：以根集物件為起始點進行搜尋，如果有物件不可達的話，即是垃圾物件。這裡的根集一般包括java棧中引用的物件、方法區常良池中引用的物件

本地方法中引用的物件等。

總之，JVM在做垃圾回收的時候，會檢查堆中的所有物件是否會被這些根集物件引用，不能夠被引用的物件就會被垃圾收集器回收。一般回收演算法也有如下幾種：

1.標記-清除（Mark-sweep）

演算法和名字一樣，分為兩個階段：標記和清除。標記所有需要回收的物件，然後統一回收。這是最基礎的演算法，後續的收集演算法都是基於這個演算法擴充套件的。

不足：效率低；標記清除之後會產生大量碎片。效果圖如下：

2.複製（Copying）

此演算法把記憶體空間劃為兩個相等的區域，每次只使用其中一個區域。垃圾回收時，遍歷當前使用區域，把正在使用中的物件複製到另外一個區域中。此演算法每次只處理正在使用中的物件，因此複製成本比較小，同時複製過去以後還能進行相應的記憶體整理，不會出現“碎片”問題。當然，此演算法的缺點也是很明顯的，就是需要兩倍記憶體空間。效果圖如下：

3.標記-整理（Mark-Compact）

此演算法結合了“標記-清除”和“複製”兩個演算法的優點。也是分兩階段，第一階段從根節點開始標記所有被引用物件，第二階段遍歷整個堆，把清除未標記物件並且把存活物件“壓縮”到堆的其中一塊，按順序排放。此演算法避免了“標記-清除”的碎片問題，同時也避免了“複製”演算法的空間問題。效果圖如下：

4.分代收集演算法

這是當前商業虛擬機器常用的垃圾收集演算法。分代的垃圾回收策略，是基於這樣一個事實：不同的物件的生命週期是不一樣的。因此，不同生命週期的物件可以採取不同的收集方式，以便提高回收效率。

為什麼要運用分代垃圾回收策略？在java程式執行的過程中，會產生大量的物件，因每個物件所能承擔的職責不同所具有的功能不同所以也有著不一樣的生命週期，有的物件生命週期較長，比如Http請求中的Session物件，執行緒，Socket連線等；有的物件生命週期較短，比如String物件，由於其不變類的特性，有的在使用一次後即可回收。試想，在不進行物件存活時間區分的情況下，每次垃圾回收都是對整個堆空間進行回收，那麼消耗的時間相對會很長，而且對於存活時間較長的物件進行的掃描工作等都是徒勞。因此就需要引入分治的思想，所謂分治的思想就是因地制宜，將物件進行代的劃分，把不同生命週期的物件放在不同的代上使用不同的垃圾回收方式。

如何劃分？將物件按其生命週期的不同劃分成：年輕代(Young Generation)、年老代(Old Generation)、持久代(Permanent Generation)。其中持久代主要存放的是類資訊，所以與java物件的回收關係不大，與回收息息相關的是年輕代和年老代。這裡有個比喻很形象

“假設你是一個普通的 Java 物件，你出生在 Eden 區，在 Eden 區有許多和你差不多的小兄弟、小姐妹，可以把 Eden 區當成幼兒園，在這個幼兒園裡大家玩了很長時間。Eden 區不能無休止地放你們在裡面，所以當年紀稍大，你就要被送到學校去上學，這裡假設從小學到高中都稱為 Survivor 區。開始的時候你在 Survivor 區裡面劃分出來的的“From”區，讀到高年級了，就進了 Survivor 區的“To”區，中間由於學習成績不穩定，還經常來回折騰。直到你 18 歲的時候，高中畢業了，該去社會上闖闖了。於是你就去了年老代，年老代裡面人也很多。在年老代裡，你生活了 20 年 (每次 GC 加一歲)，最後壽終正寢，被 GC 回收。有一點沒有提，你在年老代遇到了一個同學，他的名字叫愛德華 (慕光之城裡的帥哥吸血鬼)，他以及他的家族永遠不會死，那麼他們就生活在永生代。”

具體區域可以通過VisualVM中的VisaulGC外掛檢視，如圖（openjdk 1.7）：

年輕代：是所有新物件產生的地方。年輕代被分為3個部分——Enden區和兩個Survivor區（From和to）當Eden區被物件填滿時，就會執行Minor GC。並把所有存活下來的物件轉移到其中一個survivor區（假設為from區）。Minor GC同樣會檢查存活下來的物件，並把它們轉移到另一個survivor區（假設為to區）。這樣在一段時間內，總會有一個空的survivor區。經過多次GC週期後，仍然存活下來的物件會被轉移到年老代記憶體空間。通常這是在年輕代有資格提升到年老代前通過設定年齡閾值來完成的。需要注意，Survivor的兩個區是對稱的，沒先後關係，from和to是相對的。

年老代：在年輕代中經歷了N次回收後仍然沒有被清除的物件，就會被放到年老代中，可以說他們都是久經沙場而不亡的一代，都是生命週期較長的物件。對於年老代和永久代，就不能再採用像年輕代中那樣搬移騰挪的回收演算法，因為那些對於這些回收戰場上的老兵來說是小兒科。通常會在老年代記憶體被佔滿時將會觸發Full GC,回收整個堆記憶體。

持久代：用於存放靜態檔案，比如java類、方法等。持久代對垃圾回收沒有顯著的影響。 

分代回收的效果圖如下：

我這裡之所以最後講分代，是因為分代裡涉及了前面幾種演算法。年輕代：涉及了複製演算法；年老代：涉及了“標記-整理（Mark-Sweep）”的演算法。

四、垃圾收集器

垃圾收集演算法是記憶體回收的方法論，而實現這些方法論的則是垃圾收集器。不同廠商不同版本JVM所提供的垃圾收集器可能不同，這裡參照《深入理解Java虛擬機器》說的是JDK1.7版本Hotspot虛擬機器，關於垃圾收集器有篇博文總結的不錯，我就不說了，詳見：http://blog.csdn.net/java2000_wl/article/details/8030172