下面是老年代收集器。如果兩個收集器之間存在連線，就表示它們可以搭配使用。
Serial收集器是新生代收集器，單執行緒執行，使用複製演算法。它在進行垃圾收集時，必須暫停其他所有的工作執行緒(使用者執行緒)。是Jvm client模式下預設的新生代收集器。對於限定單一CPU的環境來說，Serial收集器由於沒有執行緒互動的開銷，專心做垃圾收集自然可以獲得最高的單執行緒收集效率。
ParNew收集器其實就是serial收集器的多條執行緒版本，除了使用多條執行緒進行垃圾收集之外，其餘行為與Serial收集器一樣。
Parallel Scavenge收集器也是一個新生代收集器，它也是使用複製Parallel Scavenge收集器也是一個新代收集器，它也是使用複製
Parallel Scavenge收集器也是一個新生代收集器，它也是使用複製
。 parallel Scavenge收集器的特點是它的關注點與其他收集器不同，CMS等收集器的關注點是盡可能地縮短垃圾收集時用戶線程的停頓時間，而parallel Scavenge收集器的目標則是達到一個可控制的吞吐量。吞吐量= 程式運作時間/(程式運作時間 + 垃圾收集時間)，虛擬機器總共運作了100分鐘。其中垃圾收集花掉1分鐘，那吞吐量就是99%。
Serial Old(串行GC)收集器
標記-整理”演算法。主要使用在Client模式下的虛擬機器。
Parallel OldParallel版本，收集多年代版本，收集多年代演算法」的「舊年代」。
①.初始標記(CMS initial
①①
②.並發標記(CMS concurrenr mark)
③.重新標記(CMS remark)
其中初始標記、重新標記這兩個步驟任然需要停頓其他使用者執行緒。初始標記只是標記出GC ROOTS能直接關聯到的對象，速度很快，並發標記階段是進行GC ROOTS 根搜尋演算法階段，會判定對像是否存活。而重新標記階段則是為了修正並發標記期間，因使用者程式繼續運作而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間會被初始標記階段稍長，但比並發標記階段要短。
由於整個過程中耗時最長的並發標記和並發清除過程中，收集器線程都可以與用戶線程一起工作，所以整體來說，CMS收集器的內存回收過程是與用戶線程一起並發執行的。
CMS收集器的優點：並發收集、低停頓，但是CMS還遠遠達不到完美，器主要有三個顯著缺點：
CMS收集器對CPU資源非常敏感。在並發階段，雖然不會導致使用者執行緒停頓，但會佔用CPU資源而導致引用程式變慢，總吞吐量下降。 CMS預設啟動的回收線程數是：(CPU數量+3) / 4。
CMS收集器無法處理浮動垃圾，可能出現“Concurrent Mode Failure“，失敗後而導致另一次Full GC的產生。由於CMS並發清理階段用戶線程還在運行，伴隨程式的運行自熱會有新的垃圾不斷產生，這一部分垃圾出現在標記過程之後，CMS無法在本次收集中處理它們，只好留待下一次GC時將其清理掉。這一部分垃圾稱為「浮動垃圾」。也是由於在垃圾收集階段用戶線程還需要運行，
即需要預留足夠的內存空間給用戶線程使用，因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集，需要預留一部分記憶體空間提供並發收集時的程式運作使用。在預設設定下，CMS收集器在老年代使用了68%的空間時就會被激活，也可以透過參數-XX:CMSInitiatingOccupancyFraction的值來提供觸發百分比，以降低記憶體回收次數提高效能。要是CMS運行期間預留的內存無法滿足程式其他線程需要，就會出現“Concurrent Mode Failure”失敗，這時候虛擬機將啟動後備預案：臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，這樣停頓時間就很長了。所以說參數-XX:CMSInitiatingOccupancyFraction設定的過高將會很容易導致「Concurrent Mode Failure」失敗，效能反而降低。最後一個缺點，CMS是基於「標記-清除」演算法實現的收集器，使用「標記-清除」演算法收集後，會產生大量碎片。空間碎片太多時，將會給對象分配帶來很多麻煩，比如說大對象，內存空間找不到連續的空間來分配不得不提前觸發一次Full GC。為了解決這個問題，CMS收集器提供了一個-XX:UseCMSCompactAtFullCollection開關參數，用於在Full GC之後增加一個碎片整理過程，還可透過-XX:CMSFullGCBeforeCompaction參數設定執行多少次不壓縮的Full GC之後，跟著來一次碎片整理過程。
G1(
ip.72」實現，也就是說不會產生記憶體碎片。還有一個特點之前的收集器進行收集的範圍都是整個新生代或老年代，而G1將整個Java堆(包括新生代，老年代)。
-XX:+
-XX:-
-XX:
-XX:
| 參數 | 描述 |
|---|---|
| Jvm運行在Client模式下的預設值，開啟此開關後，使用Serial + Serial Old的收集器組合進行記憶體回收 | |
| -XX:+UseParNewGC | -XX:+UseParNewGC使用ParNew + Serial Old的收集器進行垃圾回收 |
| -XX:+UseConcMarkSweepGC | 使用New Mode Failure」失敗後的後備收集器使用。 |
| -XX:+UseParallelGC | Jvmerial組合在此組合下的預設值，開啟此組合 |
| -XX:+UseParallelOldGCParXX:+UseParallelOldGC | ParallelOld的收集器組合回收 |
| -XX:SurvivorRatio 8:1 | |
| PretenureSizeThreshold直接晉升到老年代物件的大小，設定這個參數後，大於這個參數的物件將直接在老年代分配給Max | 晉升到老年代的對象年齡，每次Minor GC之後，年齡就加1，當超過這個參數的值時進入老年代 |
| -XX: | UseAdaptiveSizeSize java堆中各個區域的大小以及進入老年代的年齡|
| -XX:+ | HandlePromotionFailureSurvivor空間不足時，將直接會在老年代中保留 |
| :-XXo | :- |
| -XX:GCTimeRatioGC時間佔總時間的比列，預設值為99，即允許1%的GC時間，僅在使用時有效 | |
| XX:MaxGCPauseMillis -XX:CMSInitiatingOccupancyFraction | 設定CMS收集器在老年代空間被使用多少後出發垃圾收集，預設值為68%，僅在CMS收集器時有效，-XX:CMSInitiatingOccupancyFraction=70 |
| -XX: UseCMSCompactAtFullCollection由於CMS收集器會產生碎片，此參數設定在垃圾收集器後是否需要一次記憶體碎片整理過程，僅在CMS收集器時有效 | 設定CMS收集器在進行若干次垃圾收集後再進行一次內存碎片整理過程，通常與UseCMSCompactAtFullCollection參數一起使用 |
| -XX:+DisableExplicitGC | |
| 是否關閉手動System.gc 頓停頓 |
-XX:LargePageSizeInBytes | 記憶體頁的大小不可設定過大，會影響Perm的大小，-XX:LargePageSizeInBytes=128m |
| 新生代GC方式 | 老年代與持久 | 代GC方式老年代與持久代 | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Serial Old | 序列GCServerParallel Scavenge 並行回收GC | |||||||||||||||||||
| Parallel Old 並行回收GC | Parallel Old 並行GC |
Sun/oracle JDK GC組合方式
|
