Java虛擬機在執行程序時把它管理的內存分為若干數據區域，這些數據區域分布情況如下圖所示：
Java堆中存放著幾所所有的對象實例，垃圾收集器在對堆進行回收前，首先需要確定哪些對象還"活著"，哪些已經"死亡"，也就是不會被任何途徑使用的對象。
引用計數法實現簡單，效率較高，在大部分情況下是一個不錯的算法。其原理是：給對象添加一個引用計數器，每當有一個地方引用該對象時，計數器加1，當引用失效時，計數器減1，當計數器值為0時表示該對象不再被使用。需要注意的是：引用計數法很難解決對象之間相互循環引用的問題，主流Java虛擬機沒有選用引用計數法來管理內存。
這個算法的基本思路就是通過一系列的稱為“GC Roots”的對象作為起始點，從這些節點開始向下搜索，搜索所走過的路徑稱為引用鏈（Reference Chain），當一個對象到GC Roots沒有任何引用鏈相連（用圖論的話來說，就是從GC Roots到這個對象不可達）時，則證明此對象是不可用的。如圖所示，對象object 5、object 6、object 7雖然互相有關聯，但是它們到GC Roots是不可達的，所以它們將會被判定為是可回收的對象。
在Java語言中，可作為GC Roots的對象包括下面幾種：
現在問題來了，可達性分析算法會不會出現對象間循環引用問題呢？答案是肯定的，那就是不會出現對象間循環引用問題。GC Root在對象圖之外，是特別定義的“起點”，不可能被對象圖內的對象所引用。具體講解參見：http://www.zhihu.com/question/29218534。
即使在可達性分析算法中不可達的對象，也並非是“非死不可”的，這時候它們暫時處於“緩刑”階段，要真正宣告一個對象死亡，至少要經歷兩次標記過程：如果對象在進行可達性分析後發現沒有與GC Roots相連接的引用鏈，那它將會被第一次標記並且進行一次篩選，篩選的條件是此對象是否有必要執行finalize()方法。當對象沒有覆蓋finalize()方法，或者finalize()方法已經被虛擬機調用過，虛擬機將這兩種情況都視為“沒有必要執行”。程序中可以通過覆蓋finalize()來一場"驚心動魄"的自我拯救過程，但是，這只有一次機會呦。
/**
* 此代碼演示了兩點：
* 1.對象可以在被GC時自我拯救。
* 2.這種自救的機會只有一次，因為一個對象的finalize()方法最多只會被系統自動調用一次
* @author zzm
*/
public class FinalizeEscapeGC {
public static FinalizeEscapeGC SAVE_HOOK = null;
public void isAlive() {
System.out.println("yes, i am still alive :)");
}
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("finalize mehtod executed!");
FinalizeEscapeGC.SAVE_HOOK = this;
}
public static void main(String[] args) throws Throwable {
SAVE_HOOK = new FinalizeEscapeGC();
//對象第一次成功拯救自己
SAVE_HOOK = null;
System.gc();
//因為finalize方法優先級很低，所以暫停0.5秒以等待它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("no, i am dead :(");
}
//下面這段代碼與上面的完全相同，但是這次自救卻失敗了
SAVE_HOOK = null;
System.gc();
//因為finalize方法優先級很低，所以暫停0.5秒以等待它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("no, i am dead :(");
}
}
}
運行結果為：
finalize mehtod executed! yes, i am still alive :) no, i am dead :(
無論是通過引用計數算法判斷對象的引用數量，還是通過可達性分析算法判斷對象的引用鏈是否可達，判定對象是否存活都與“引用”有關。在JDK 1.2以前，Java中的引用的定義很傳統：如果reference類型的數據中存儲的數值代表的是另外一塊內存的起始地址，就稱這塊內存代表著一個引用。在JDK 1.2之後，Java對引用的概念進行了擴充，將引用分為強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）4種，這4種引用強度依次逐漸減弱。
軟引用使用示例：
package jvm;
import java.lang.ref.SoftReference;
class Node {
public String msg = "";
}
public class Hello {
public static void main(String[] args) {
Node node1 = new Node(); // 強引用
node1.msg = "node1";
SoftReference<Node> node2 = new SoftReference<Node>(node1); // 軟引用
node2.get().msg = "node2";
System.out.println(node1.msg);
System.out.println(node2.get().msg);
}
}
輸出結果為：
node2 node2
1.Mark-Sweep（標記-清除）算法
這是最基礎的垃圾回收算法，之所以說它是最基礎的是因為它最容易實現，思想也是最簡單的。標記-清除算法分為兩個階段：標記階段和清除階段。標記階段的任務是標記出所有需要被回收的對象，清除階段就是回收被標記的對象所占用的空間。具體過程如下圖所示：
從圖中可以很容易看出標記-清除算法實現起來比較容易，但是有一個比較嚴重的問題就是容易產生內存碎片，碎片太多可能會導致後續過程中需要為大對象分配空間時無法找到足夠的空間而提前觸發新的一次垃圾收集動作。
2.Copying（復制）算法
為了解決Mark-Sweep算法的缺陷，Copying算法就被提了出來。它將可用內存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活著的對象復制到另外一塊上面，然後再把已使用的內存空間一次清理掉，這樣一來就不容易出現內存碎片的問題。具體過程如下圖所示：
這種算法雖然實現簡單，運行高效且不容易產生內存碎片，但是卻對內存空間的使用做出了高昂的代價，因為能夠使用的內存縮減到原來的一半。
很顯然，Copying算法的效率跟存活對象的數目多少有很大的關系，如果存活對象很多，那麼Copying算法的效率將會大大降低。
3.Mark-Compact（標記-整理）算法
為了解決Copying算法的缺陷，充分利用內存空間，提出了Mark-Compact算法。該算法標記階段和Mark-Sweep一樣，但是在完成標記之後，它不是直接清理可回收對象，而是將存活對象都向一端移動，然後清理掉端邊界以外的內存。具體過程如下圖所示：
4.Generational Collection（分代收集）算法
分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根據對象存活的生命周期將內存劃分為若干個不同的區域。一般情況下將堆區劃分為老年代（Tenured Generation）和新生代（Young Generation），老年代的特點是每次垃圾收集時只有少量對象需要被回收，而新生代的特點是每次垃圾回收時都有大量的對象需要被回收，那麼就可以根據不同代的特點采取最適合的收集算法。
目前大部分垃圾收集器對於新生代都采取Copying算法，因為新生代中每次垃圾回收都要回收大部分對象，也就是說需要復制的操作次數較少，但是實際中並不是按照1：1的比例來劃分新生代的空間的，一般來說是將新生代劃分為一塊較大的Eden空間和兩塊較小的Survivor空間（一般為8:1:1），每次使用Eden空間和其中的一塊Survivor空間，當進行回收時，將Eden和Survivor中還存活的對象復制到另一塊Survivor空間中，然後清理掉Eden和剛才使用過的Survivor空間。
而由於老年代的特點是每次回收都只回收少量對象，一般使用的是Mark-Compact算法。
1、《深入理解Java虛擬機》2章和3章內容
2、Java垃圾回收機制
3、Java方法區和運行時常量池溢出問題分析
