此處將引用《深入理解Java虛擬機——JVM高級特性與最佳實踐》這本書的一些內容。
1、對象已死？
垃圾回收是對堆中對象的管理，首先就要確定什麼是垃圾，即什麼情況下堆中的對象可以被回收。
最常用的判定算法是引用計數算法，即每當有一個對象被其它對象所引用，則將對象的引用數+1，當對象的引用數爲0時，則認爲對象將不再被使用，可以回收。但引用計數算法有一個缺陷，即無法解決對象循環引用的問題。當對象相互引用時，將會給引用的雙方的對象的引用計數+1，這樣的話對象的引用計數將一直無法被清零，也即是說，GC（Garbage Collection）無法判定對象爲可回收對象，該對象將一直佔據在內存中無法被釋放。
Java中使用的判定算法爲根搜索算法（GC Roots Tracing），這個算法的基本思路是通過一系列名爲“GC Roots”的對象作爲起始點，由該起始點出發向下搜索對象，搜索走過的路徑稱爲引用鏈（Reference Chain），當一個對象到GC Roots沒有任何引用鏈連接，即此對象不可達時，則認爲此對象不可用。
Java中可以作爲GC Roots的對象包括以下幾種：
a、虛擬機棧（棧幀中的本地變量表）中的引用的對象
b、方法區中的類靜態屬性引用的對象
c、方法區中的常量引用的對象
d、本地方法棧中JNI的引用的對象
個人對於以上幾種GC Roots對象的理解是這樣的：根搜索算法的判定條件是對象不可達，而不是引用計數歸零，即是說當從某個引用出發去搜索對象時，某個對象無法再被搜索到，則判定該對象可以被回收，這樣一來，一旦引用被重置爲null，假設該引用所指向的對象只被該引用所索引，那麼此時對象將不再被任何引用所索引，此時對象將處於可回收狀態，而不會出現由於循環引用而使引用計數無法被清零的問題。具體情形如下：
Java中對於引用的概念進行了擴充，以描述這樣一類對象：當內存空間還足夠時，則能保留在內存之中，如果內存在進行垃圾收集後還是非常緊張，則可以拋棄這些對象。
Java中的引用分爲強引用（Strong Reference），軟引用（Soft Reference），弱引用（Weak Reference），虛引用（Phantom Reference）四種，強度依次減弱。
a、強引用：類似"Object obj = new Object();"這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的對象
b、軟引用：通過SoftReference類實現，SoftReference<Person> p = new SoftReference<Person>(new Person(“Rain”));內存非常緊張的時候會被回收，其他時候不會被回收，所以在使用之前要判斷是否爲null從而判斷他是否已經被回收了。
c、通過WeakReference類實現，eg : WeakReference<Person> p = new WeakReference<Person>(new Person(“Rain”));不管內存是否足夠，系統垃圾回收時必定會回收。
d、不能單獨使用，主要是用於追蹤對象被垃圾回收的狀態。通過PhantomReference類和引用隊列ReferenceQueue類聯合使用實現。
回顧完引用問題，來繼續看對象什麼時候被回收的問題，前面已經講了當對象被判定不可達時，則可以被回收。但是否一定被回收呢？
當對象被判定不可達時，此時虛擬機會對該對象進行標記並篩選，篩選的條件是此對象有沒有必要執行finalize()方法。當對象沒有覆蓋 finalize()方法或是虛擬仙已經調用過finalize()方法，則虛擬機將這兩種情況都視爲沒有必要執行。若是判定爲沒有必要執行，則直接回收對象。
若對象被判定爲有必要執行finalize()方法，虛擬機會把該對象放入一個F-Queue的隊列中，稍後會由虛擬機建立的一條優先級的線程 Finalizer去執行。注意，此處的執行是指虛擬機會觸發這個方法，但不保證會等待方法的執行直至結束（避免由於執行緩慢或是死循環而導致整個內存回收系統崩潰）。finalize()方法是對象逃脫被回收命運的最後一次機會，(若想要保留對象不被回收，可覆蓋finalize()方法並在方法中添加到這個對象的引用。)在F-Queue隊列開始執行後，過一會時間GC會對隊列中的對象進行第二次標記，標記和篩選方法和第一次的相同，但有一點有所不同，即任何對象的finalize()方法將被會且只會被系統自動調用一次，只要執行過一次後，以後將不再執行，因此，在第二次標記後，依舊被判定爲不可達的對象將被虛擬機直接回收。
以上對對象的回收進行了回顧，而對於方法區的回收，JVM規範不要求虛擬機實現方法區的垃圾收集，虛擬機不一定會實現這方面的回收。在這裏就簡單的說一下永久代的回收內容和判定條件。
永久代的垃圾收集主要包括廢棄常量和無用的類，廢棄常量的判斷比較簡單，只要檢查該常量是否被引用就可以了。而類的“無用”判定則要同時滿足三個條件：a、該類所有的實例已經被回收，即Java堆中不存在該類的任何實例；b、加載該類的ClassLoader已經被回收；c、該類對應的 java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。
在大量使用反射、動態代理、CGLib等bytecode框架的場景，以及動態生成JSP和OSGi這類頻繁自定義的ClassLoader的場景都需要虛擬機具備類卸載的功能，以保證永久代不會溢出。
2、常用的垃圾收集算法
a、標記——清除算法（Mark——Sweep）
首先標記出所有需要回收的對象，在標記完成後統一回收掉所有被標記的對象。
缺點：
效率問題，標記和清除過程的效率不高；
空間問題，標記清除之後會產生大量的非連續空間碎片，過多的碎片將導致程序在以後的運行中找不到足夠大的連續內存空間來分配給較大的對象而不得不提前觸發另一次垃圾收集事件。
b、複製算法（Copying）
爲了解決標記清除算法的效率問題，複製算法將可用的內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活的對象複製到另一塊上，然後再把已使用過的內存空間一次清理掉。
優點：
實現簡單，運行高效
缺點：
對內存空間的利用不高，可用內存變成一半，這代價過高
現在的商業虛擬機基本都採用這種收集算法來回收新生代，由於新生代中的對象存活率不高，因此不需要按1：1來劃分內存空間，而是將內存分爲一塊較大的Eden空間和兩塊較小的Survior空間，每次使用Eden和其中的一塊Survior，回收時將Eden和Survior中還存活的對象一次性地拷貝到另外一塊Survior上，最後清理掉Eden和剛纔用過的Survior空間。（HotSpot虛擬機默認Eden和Survior大小比例是 8：1）當然，Survior空間不可能一直夠用，此時還需要老年代來進行分配擔保（Handle Promotion）（主要是將新生代存活的大對象直接移到老年代，以減少對Survior內存空間的需求）。
c、標記——整理算法（Mark——Compact）
與標記清除算法的標記階段相同，但標記後會將所有存活的對象向一端移動，然後直接清理掉端邊界以外的內存。這種算法一般用於老年代的內存回收上，因爲老年代中對象的存活時間都比較長，可能存在100%存活的極端情況，因此不能選擇Copying算法來進行回收。
d、分代收集算法（Generational Collection）
這種算法只是根據對象的存活週期的不同將內存劃分爲幾塊，一般都劃分爲新生代和老年代，這樣可以根據各個年代的特點採用最適當的收集算法。新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，因此選取複製算法，只需要付出少量存活對象的複製成本就可以完成收集；老年代中因爲對象存活率高，沒有額外的空間對它進行分配擔保，就必須使用“標記——清除”或是“標記——整理”算法來進行回收。在之前的三種算法中已經有所描述。
3、內存分配與回收策略
回顧完垃圾回收的判定和算法後，我們來看下內存分配和回收的策略。
內存的回收分爲兩類：
新生代GC（Minor GC）：指發生在新生代的垃圾收集動作，因爲Java對象大多都具備朝生夕死的特性，所以Minor GC非常頻繁，一般回收速度也比較快。
老年代GC（Major GC/Full GC）：指發生在老年代的GC，出現Major GC，經常會伴隨至少一次Minor GC。Major GC的速度一般會比Minor GC慢10倍以上，而且一次Full GC的執行是以整個程序完全停滯作爲代價的，這對於很多實時或是高響應要求的應用來說是不可接受的，因此需要儘可能地減少Full GC的出現。
虛擬機一般會採用以下幾種內存分配策略來儘量減少Full GC出現的頻率：
a、對象優先在Eden分配
b、大對象直接進行老年代（可通過參數設置直接進入老年代的對象的內存閾值）
c、長期存活的對象將進入老年代（對Survior中的對象進行年齡計量，每經過一次Minor GC而不被回收，則對其年齡+1，當達到閾值時就晉升到老年代，閾值可以通過參數設置）
d、動態對象年齡判定（當Survior空間中相同年齡所有對象大小的總和大於Survior空間的一半，則年齡大於或等於該年齡的對象就可以直接進入老年代）
e、空間分配擔保（在此前有提到過，老年代爲Survior進行空間擔保，當Survior空間不足時將對象轉移進老年代。前提是老年代也有足夠的空間來安置來自Survior的對象，但Survior中將要被移到老年代的對象的大小在完成內存回收之前是不可知的，只能取之前每一次回收晉升到老年代對象容量的平均大小值作爲經驗值，與老年代的剩餘空間進行比較，決定是否進行Full GC來讓老年代騰出空間。當然，如果出現某次Minor GC存活後的對象突增，遠遠高於平均值，此時可能會導致擔保失敗，則將重新發起一次Full GC）
好了，終於完成了關於Java內存回收機制的複習，除了《深入理解Java虛擬機》這本書外，還引用了以下頁面的內容，這篇博客對垃圾回收機制的描述更加細緻且易於理解。文章鏈接如下：
http://blog.jobbole.com/37273/