相信大家可以透過我提供的另外兩個文章，學習到很多的垃圾回收器的相關知識。而我們真正需要關注，甚至可能使用到的垃圾收集器就是以下四種：
如果是在client#類型的虛擬機器或在單核心的伺服器上，這種垃圾回收器將會成為預設的垃圾回收器。無論是Minor GC 還是 Full GC ，所有的應用程式執行緒都會暫停。在老年代當中使用的是Serial Old，同樣是單線程的老年代版本。
client型虛擬機，我們前面提到編譯類型分為client和server，jvm會透過client編譯器（單執行緒）將程式碼編譯成jvm辨識的字節碼。
可以透過以下標誌表示：
-XX:+UseSerialGC
在server型虛擬機或多執行緒伺服器上，jdk8默認使用的垃圾收集器類型。
無論是Minor GC或Full GC都使用多執行緒的方式去回收垃圾，這兩種GC都會造成應用程式執行緒的暫停。但是它具有更多的吞吐量，是對於響應時間沒有過多要求情況下，最合適的垃圾回收器。
可以透過以下標誌查看其狀態：
年輕代：
-XX:+UseParallelGC
老年代：
-XX:+UseParallelOldGC
其設計初衷是為了減少serial和parallel收集器，在回收時造成的長時間的系統卡頓。
它在發生Minor GC時同樣會暫停所有的應用線程，不同之處在於，年輕代使用的不是parallel或者serial，而是使用一款專門適用於CMS的年輕代收集器ParNew。
可以透過下面的標誌查看：
-XX:+UseParNewGC
CMS在發生Full GC時不再暫停全部應用線程，使用多線程的方式，和應用線程同時運行，清理不在使用的物件。這事得CMS垃圾收集器的停頓時間大大的降低。與Parellel收集器相比，極為明顯。
缺點：
CMS需要佔用較多的CPU資源，確保在應用執行緒執行時，gc執行緒不斷掃描堆空間。
不會對記憶體進行壓縮整理，導致記憶體碎片化。
如果沒有足夠的CPU資源，或記憶體碎片化達到極限，將會退化成serial收集器。
可以透過下面的標誌查看：
-XX:+UseConcMarkSweepGC
也可以稱為垃圾優先收集器( garbage first)。
設計初衷是為了盡量減少處理超大堆（4gb）時發生的卡頓。 G1仍然屬於分代收集器，但不同之處是它是邏輯分代。 G1將堆空間劃分成若干個區域（Region），新生代的垃圾收集依然採用暫停所有應用線程的方式，將存活物件拷貝到老年代或Survivor空間。老年代也分成許多區域，G1收集器透過將物件從一個區域複製到另一個區域，完成了清理工作。這樣就解決了CMS中的記憶體碎片問題。
與CMS相同，G1也屬於concurrent收集器，在老年代發生Full GC時，由後台執行緒完成回收工作，不需要暫停應用執行緒。
透過下面的標誌查看：
-XX:+UseG1GC
其實上面的內容都是簡單描述，真正的實作細節請看開篇提供的文章。
這裡說的顯式的垃圾收集，其實指的是手動觸發的垃圾回收，如下所示：
System.gc;
這是一種可以認為控制，讓jvm發生強制gc的方式。無論什麼時候，都是不建議使用這種方式進行垃圾回收。
當你使用這條指定，不論是何種垃圾收集器，即使是CMS或G1也會發生Full GC，同時停止全部的應用線程，會卡頓相當長的一段時間。
例外：
效能分析、測試
以上是java效能優化常見的垃圾收集器有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！
