典型的垃圾收集器

        若是說收集算法是內存回收的方法論，垃圾收集器就是內存回收的具體實現。Java虛擬機規範中對垃圾收集器應該如何實現並無任何規定，所以不一樣的廠商、不一樣版本的虛擬機所提供的垃圾收集器均可能會有很大的差異，而且通常都會提供參數共用戶根據本身的應用特色和需求組合出各個年代所使用的收集器

1.Serial收集器

　　Serial收集器是最基本最古老的收集器，它是一個單線程收集器，但它的「單線程」的意義並不只僅是說明它只會使用一個CPU或一條收集線程去完成垃圾收集工做，更重要的是它進行垃圾收集時，必須暫停其餘全部的工做線程。Serial收集器是針對新生代的收集器，採用的是Copying算法，Serial Old收集器是針對老年代的收集器，採用的是Mark-Compact算法。

     它的優勢是實現簡單高效，可是缺點是會給用戶帶來停頓。

     它最適合簡單的命令行程序。經過-XX:+UseSerialGC參數來選用Serial Garbage Collector。

2.Serial Old收集器

    單線程收集器，針對老年代的收集器，採用標記-整理算法。

    做爲CMS收集器的後備收集器：當CMS收集器產生Concurrent Mode Failure時，將臨時啓動Serial Old收集器從新進行老年代的垃圾收集

3.ParNew收集器

　　ParNew收集器是Serial收集器的多線程版本，新生代收集器使用複製算法.除了使用多線程進行垃圾收集外，其他行爲與Serial收集器徹底同樣，依然會stop the world不少虛擬機-server模式下的首選新生代收集器，主要緣由是CMS收集器（老年代收集器）只能與Serial收集器或者ParNew收集器配合使用默認開啓的回收線程數與CPU個數相同（現代服務器動輒32個邏輯CPU將會致使ParNew收集器開啓32個收集線程，這種狀況下最好限制下收集線程個數）

     -XX：ParallelGCThreads 多線程垃圾收集器內存回收開啓的線程數量

4.Parallel Old收集器

   Parallel Old是Parallel Scavenge收集器的老年代版本（並行收集器），使用多線程和Mark-Compact算法。

5.Parallel Scavenge收集器

　　Parallel Scavenge收集器是一個新生代的多線程收集器（並行收集器），採用的是Copying算法,它在回收期間不須要暫停其餘用戶線程.該收集器與前兩個收集器有所不一樣，它主要是爲了達到一個可控的吞吐量。吞吐量=運行用戶代碼時間/(運行用戶代碼時間+垃圾回收時間) 

     停頓時間短則響應速度快，適合與用戶交互比較多的應用；吞吐量大可以最高效的利用CPU時間，儘快完成運算任務，適合後臺運算、交互很少的應用.

     GC擁有自適應調節策略。若是啓用該策略，只須要設置好基本參數（-Xmx等），而後設置一個優化目標（最大垃圾收集時間或吞吐量大小），虛擬機會根據當前系統的運行情況收集性能監控信息，動態調整細節參數設置。

-XX：MaxGCPauseMillis 最大停頓時間，僅對Parallel Scavenge收集器生效

-XX：GCTimeRatio 吞吐量大小，默認值爲99，即1%的GC時間，僅對Parallel Scavenge收集器生效

-XX：+UseAdaptiveSizePolicy 使用GC自適應調節策略

6.CMS收集器

      用多個線程來掃描堆內存來標記須要回收的實例，而後再清除被標記的實例。CMS Garbage Collector只有在以下兩種情景纔會暫停全部的應用線程:

     1.當標記永久代內存空間中的對象時；

     2.當進行垃圾回收時，堆內存同步發生了一些變化。

相比Parallel Garbage Collector，CMS Garbage Collector使用更多的CPU資源來確保應用有一個更好的吞吐量。若是分配更多的CPU資源能夠得到更好的性能，那麼CMS Garbage Collector是一個更好的選擇，相比Parallel Garbage Collector。

    經過XX:+USeParNewGC參數來選用CMS Garbage Collector。

     該收集器的收集過程分爲4個步驟：

     1.初始標記 CMS initial mark：該步會stop the world，但耗時很是短，標記GC Root直接關聯的對象

     2.併發標記 CMS concurrent mark：耗時較長，用戶線程可同時運行，標記至GC Root有可達路徑的對象

     3.從新標記 CMS remark：該步會stop the world，但耗時很是短。因爲步驟2用戶線程同步運行，此時主要修正因步驟二同步用戶線程產生的對象標記變更

     4.併發清除 CMS concurrent sweep：耗時較長，用戶線程可同時運行

     在耗時很長的併發標記階段和併發清除階段用戶線程和收集線程均可同時工做，故而整體上來講，CMS收集器的內存回收是與用戶線程一塊兒併發執行的.雖然收集停頓時間短，可是也有很多缺點：

     1.對CPU資源敏感，CMS收集器默認開啓的收集線程數爲(CPU數量+3)/4，若是CPU數量較少，會佔用很多CPU處理資源

     2.沒法處理浮動垃圾，而且可能產生Concurrent Mode Failure從而致使另外一次Full GC。

      併發清除時（步驟4），用戶線程是能夠同時運行的，此時用戶線程會產生新的垃圾，這部分垃圾在標記過程以後產生，本次GC已經不能進行標記後清除，只能留到下次GC時處理，被稱爲浮動垃圾

    因爲CMS的收集線程執行時，用戶線程也是會同時執行的，致使CMS收集器沒法像其它老年代收集器那樣在老年代內存幾乎耗盡時在進行GC，必須爲用戶線程預留部份內存（默認使用68%內存就會開啓收集過程），若是預留內存沒法知足用戶線程的執行，將會出現Concurrent Mode Failure，此時虛擬機將會啓動備用方案，調用Serial Old收集器執行一次Full GC，這將致使較長的收集停頓

-XX：CMSInitiationgOccupancyFraction 設置GC觸發的百分比，默認爲68%，過高會致使過多的Concurrent Mode Failure，過低則影響性能，僅對CMS收集器生效

    3.因爲採用標記-清除算法實現，會產生內存碎片

-XX：+UseCMSCompactAtFullCollection Full GC後提供內存整理，該過程是沒法併發的，會致使性能降低，僅對CMS收集器生效

-XX：+CMSFullGCsBeforeCompation 設置進行完幾回不進行壓縮的Full GC後，進行一次附帶壓縮的Full GC，僅對CMS收集器生效

7.G1收集器

　　G1收集器是當今收集器技術發展最前沿的成果，它是一款面向服務端應用的收集器，它能充分利用多CPU、多核環境。所以它是一款並行與併發收集器，而且它能創建可預測的停頓時間模型。

　  用於大的堆內存區域。它將堆內存分割成多個獨立區域（Region），而後併發地對它們進行垃圾回收。在釋放內存後，G1還能夠壓縮空閒的堆內存。可是，CMS Garbage Collector是經過「Stop The World (STW)」來進行內存壓縮的。G1優先收集可回收更多內存的區域。

     經過–XX:+UseG1GC參數來選用G1 Garbage Collector。

 

附：收集器的組合使用：

-XX:+UseSerialGC 使用Serial+Serial Old的收集器組合

-XX:+UseParNewGC 使用ParNew+Serial Old的收集器組合

-XX:+UseConcMarkSweepGC 使用ParNew+CMS（Serial Old）的收集器組合

-XX:+UseParallelGC 使用Parallel Scavenge+Serial Old的收集器組合

-XX:+UseParallelOldGC 使用Parallel Scavenge+Parallel Old的收集器組合