1，如何判定對象為垃圾對象
1.1 引用計數法
1.2 可達性分析法
2，如何回收
2.1 回收政策
2.1.1 标記-清除算法
2.1.2 複制算法
2.1.3 标記-整理算法
2.1.4 分代收集算法
2.2 垃圾回收器
常用回收器： Serial Parnew Cms G1
3，何時回收
引用計數法：
在對象中添加一個引用計數器，當有地方引用這個對象的時候，引用計數器的值+1.當引用失效的時候，計數器的值就-1.
引用計數器高效簡單，但是已經被淘汰了。因為如上圖；當對象内部互相引用的時候，外部沒有引用的時候。計數器不為0，但實際已經無效了。此時垃圾回收器失效了
public static void main(String[] args){
Object object1=new Object();
Object object2=new Object();
object1.object=object2;
object2.object=object1;
object1=null;
object2=null;
}
顯然，在最後，object1和object2的記憶體塊都不能再被通路到了，但他們的引用計數都不為0，這就會使他們永遠不會被清除。
-verbose:gc
-xx+PrintGCDetail
列印GC資訊
可達性分析算法（目前回收器都是使用的這種）
首先建立一個垃圾回收根節點，指向一個位址，如果能走到對象說明這個對象還存在有效引用，如果走完所有路徑都走不到該對象，那麼說明這個對象該被回收了。
下面對象可作為GCRoot的對象：虛拟機棧（局部變量表），方法區的類屬性所引用的對象，方法區常亮所引用的對象，本地方法棧中所引用的對象。
為了解決引用計數法的循環引用問題，Java使用了可達性分析的方法。通過一系列的“GC roots”對象作為起點搜尋。如果在“GC roots”和一個對象之間沒有可達路徑，則稱該對象是不可達的。要注意的是，不可達對象不等價于可回收對象，不可達對象變為可回收對象至少要經過兩次标記過程。兩次标記後仍然是可回收對象，則将面臨回收。
所謂“GC roots”，或者說tracing GC的“根集合”，就是一組必須活躍的引用。例如說，這些引用可能包括：
- 所有Java線程目前活躍的棧幀裡指向GC堆裡的對象的引用；換句話說，目前所有正在被調用的方法的引用類型的參數/局部變量/臨時值。
- VM的一些靜态資料結構裡指向GC堆裡的對象的引用，例如說HotSpot VM裡的Universe裡有很多這樣的引用。
- JNI handles，包括global handles和local handles（看情況）
- 所有目前被加載的Java類（看情況）
- Java類的引用類型靜态變量（看情況）
- Java類的運作時常量池裡的引用類型常量（String或Class類型）（看情況）
- String常量池（StringTable）裡的引用
比較常見的将對象視為可回收對象的原因：
- 顯式地将對象的唯一強引用指向新的對象。
- 顯式地将對象的唯一強引用指派為Null。
- 局部引用所指向的對象（如，方法内對象）。
下述代碼中，每次循環結束，object都會被視為可回收對象。
void fun() {
.....
for(int i=0;i<10;i++) {
Object obj = new Object();
System.out.println(obj.getClass());
}
}
- 隻有弱引用與其關聯的對象
4種引用狀态
在JDK1.2之前，Java中引用的定義很傳統：如果引用類型的資料中存儲的數值代表的是另一塊記憶體的起始位址，就稱這塊記憶體代表着一個引用。這種定義很純粹，但是太過于狹隘，一個對象隻有被引用或者沒被引用兩種狀态。我們希望描述這樣一類對象：當記憶體空間還足夠時，則能保留在記憶體中；如果記憶體空間在進行垃圾收集後還是非常緊張，則可以抛棄這些對象。很多系統的緩存功能都符合這樣的應用場景。在JDK1.2之後，Java對引用的概念進行了擴充，将引用分為強引用、軟引用、弱引用、虛引用4種，這4種引用強度依次減弱。
1、強引用
代碼中普遍存在的類似"Object obj = new Object()"這類的引用，隻要強引用還存在，垃圾收集器永遠不會回收掉被引用的對象
2、軟引用
描述有些還有用但并非必需的對象。在系統将要發生記憶體溢出異常之前，将會把這些對象列進回收範圍進行二次回收。如果這次回收還沒有足夠的記憶體，才會抛出記憶體溢出異常。Java中的類SoftReference表示軟引用
3、弱引用
描述非必需對象。被弱引用關聯的對象隻能生存到下一次垃圾回收之前，垃圾收集器工作之後，無論目前記憶體是否足夠，都會回收掉隻被弱引用關聯的對象。Java中的類WeakReference表示弱引用
4、虛引用
這個引用存在的唯一目的就是在這個對象被收集器回收時收到一個系統通知，被虛引用關聯的對象，和其生存時間完全沒關系。Java中的類PhantomReference表示虛引用、
方法區回收
虛拟機規範中不要求方法區一定要實作垃圾回收，而且方法區中進行垃圾回收的效率也确實比較低，但是HotSpot對方法區也是進行回收的，主要回收的是廢棄常量和無用的類兩部分。判斷一個常量是否“廢棄常量”比較簡單，隻要目前系統中沒有任何一處引用該常量就好了，但是要判定一個類是否“無用的類”條件就要苛刻很多，類需要同時滿足以下三個條件：
1、該類所有執行個體都已經被回收，也就是說Java堆中不存在該類的任何執行個體
2、加載該類的ClassLoader已經被回收
3、該類對應的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射通路該類的方法
在大量使用反射、動态代理、CGLib等ByteCode架構、動态生成JSP以及OSGi這類頻繁自定義ClassLoader的場景都需要虛拟機具備類解除安裝功能，以保證方法區不會溢出。
标記-清除算法
效率低，空間利用低（産生很多碎片）
複制算法
不過這種算法有個缺點，記憶體縮小為了原來的一半，這樣代價太高了。現在的商用虛拟機都采用這種算法來回收新生代，不過研究表明1:1的比例非常不科學，是以新生代的記憶體被劃分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor。每次回收時，将Eden和Survivor中還存活着的對象一次性複制到另外一塊Survivor空間上，最後清理掉Eden和剛才用過的Survivor空間。HotSpot虛拟機預設Eden區和Survivor區的比例為8:1，意思是每次新生代中可用記憶體空間為整個新生代容量的90%。當然，我們沒有辦法保證每次回收都隻有不多于10%的對象存活，當Survivor空間不夠用時，需要依賴老年代進行配置設定擔保（Handle Promotion）。
線程獨占：堆 方法區
線程共享：棧 本地方法棧 程式計數器
為了友善垃圾回收，堆分為新生代，老年代。新生代分為 Eden（伊甸園）新的對象都放在這，沒被回收掉之後放入 Survivor 存活區中，最後一個是 Tenured Gen 這部分區域垃圾回收期關注的比較少。
複制算法提高了标記清除的性能，看看怎麼做到的：複制算法将記憶體分為A,B兩部分。每次使用一個部分A，當觸發一次垃圾回收後，将剩餘可用的一部分記憶體複制到另一部分區域B。此後所有申請的記憶體都在B中，直到下次垃圾回收的時候，清除B中回收記憶體，将剩餘的記憶體複制到A中，如此反複。
這個算法有個問題：記憶體浪費！為了優化這個問題，将細分新生代的記憶體占比和回收方式
Eden 存放所有新的對象，那麼它肯定要占絕大多數；
把survival弄成2個，假設各站剩餘的一半
Tenured Gen 基本不用到，假設先為0 有必要用到後會後續申請配置設定
一般Eden 絕大多數的資料都會被回收，那麼把未被回收的資料放在左側survival，下次gc流程光顧eden和survival區域把eden存活的和左側survival存活的對象全部複制到右側survival，再gc的時候會把eden存活的和右側survival存活的放到左側survival中。這個循環過程中有算法判斷是否需要把survival多次存活的對象複制到Tenured Gen中。
不是每次光顧Eden的時候都會光顧survival的！survival被光顧的次數比Eden要少很多，Tenured Gen 更是如此。
這樣空間浪費就沒有那麼大
當Eden存活的資料大于survival最大值的時候，會有個記憶體擔保算法，将對象放在老年代中。
複制算法在對象存活率較高的場景下要進行大量的複制操作，效率很低。萬一對象100%存活，那麼需要有額外的空間進行配置設定擔保。老年代都是不易被回收的對象，對象存活率高，是以一般不能直接選用複制算法。根據老年代的特點，有人提出了另外一種标記-整理算法，過程與标記-清除算法一樣，不過不是直接對可回收對象進行清理，而是讓所有存活對象都向一端移動，然後直接清理掉邊界以外的記憶體。标記-整理算法的工作過程如圖：
标記整理算法
複制算法适用于絕大多數都會被回收的情況，老年代的資料就不适用。
跟标記清除算法不一樣的是：因為是老生代需要清除的不多，就把不需要清除的對象移到一端，需要回收的對象移動到另一端，另一端的資料将會被回收。多出了一個整理的過程，因為資料量小是以移動開銷可以接受
分代收集算法
針對新生代老生代不同選擇不同算法。新生代 回收率高的使用複制算法，老年代回收率低的使用 标記整理算法
分代收集算法：
根據記憶體中對象的存活周期不同，将記憶體劃分為幾塊，java的虛拟機中一般把記憶體劃分為新生代和年老代，當新建立對象時一般在新生代中配置設定記憶體空間，當新生代垃圾收集器回收幾次之後仍然存活的對象會被移動到年老代記憶體中，當大對象在新生代中無法找到足夠的連續記憶體時也直接在年老代中建立。
分代收集
根據上面的内容，用一張圖概括一下堆記憶體的布局
現代商用虛拟機基本都采用分代收集算法來進行垃圾回收。這種算法沒什麼特别的，無非是上面内容的結合罷了，根據對象的生命周期的不同将記憶體劃分為幾塊，然後根據各塊的特點采用最适當的收集算法。大批對象死去、少量對象存活的，使用複制算法，複制成本低；對象存活率高、沒有額外空間進行配置設定擔保的，采用标記-清理算法或者标記-整理算法。
現在的Java虛拟機就聯合使用了分代複制、标記-清除和标記-整理算法，java虛拟機垃圾收集器關注的記憶體結構如下：
什麼時候回收？
1. Minor GC
當新生代空間不足時觸發
2. Full GC
當調用System.gc()函數時觸發老年代空間不足時觸發,方法區空間不足時觸發
觸發GC的時機
最後總結一下什麼時候會觸發一次GC，個人經驗看，有三種場景會觸發GC：
1、第一種場景應該很明顯，當年輕代或者老年代滿了，Java虛拟機無法再為新的對象配置設定記憶體空間了，那麼Java虛拟機就會觸發一次GC去回收掉那些已經不會再被使用到的對象
2、手動調用System.gc()方法，通常這樣會觸發一次的Full GC以及至少一次的Minor GC
3、程式運作的時候有一條低優先級的GC線程，它是一條守護線程，當這條線程處于運作狀态的時候，自然就觸發了一次GC了。這點也很好證明，不過要用到WeakReference的知識，後面寫WeakReference的時候會專門講到這個。