jvm垃圾收集器有哪些？深度講解

Serial收集器

Serial收集器是最基本，發(fā)展最悠久的收集器，在JDK1.3.1之前是虛擬機新生代垃圾回收的唯一選擇。這個收集器是一個單線程的。它的單線程的意義并不僅僅說明它只會使用一個CPU或者一條收集線程去完成收集工作，最重要的是，它進行垃圾收集時，其他工作線程會暫停，直到收集結束。這項工作由虛擬機在后臺自動發(fā)起和執(zhí)行的，在用戶不可見的情況下將所有工作線程全部停掉，這對于很多應用程序來說是不可容忍的。我們可以設想一下，我們的計算機在運行1個小時就要停止5分鐘的時候，這是什么情況?對于這種設計，虛擬機設計人員表示的也是非常委屈，因為不可能邊收集，這邊還要不斷的產生垃圾對象，這樣是清理不完的。所以從1.3一直到現在，虛擬機的開發(fā)團隊一直為減少因垃圾回收而產生的線程停頓所努力著，所出現的虛擬機越來越優(yōu)秀，但直到現在，依然沒有完全消除。

講到這里，貌似Serial收集器已經是"食之無味棄之可惜"了，但實際上，它依然是虛擬機在Client模式下，新生代默認的垃圾收集器。它有相對于其他垃圾收集器的優(yōu)勢，比如由于沒有線程之間切換的開銷，專心做垃圾收集自然能夠收獲最高的線程利用效率。在用戶桌面應用背景下，一般分配給虛擬機的內存不會太大，收集幾十兆或者一兩百兆的新生代對象，停頓時間完全可以控制在幾十毫秒到一百毫秒之間，這個是可以接受的，只要不是頻繁發(fā)生。因此，Serial收集器在Client模式下，對于新生代來說依然是一個很好的選擇。

ParNew收集器

ParNew收集器其實就是Serial收集器的多線程版本，除了使用多線程進行垃圾回收之外，其余可控參數，收集算法，停止工作線程，對象分配原則，回收策略等與Serial收集器完全一致。

除了多線程實現垃圾收集之外，其他沒有什么太多創(chuàng)新之處，但是它確實Server模式下的新生代的首選的虛擬機收集器。其中一個重要的原因就是除了Serial收集器外，只有它能與CMS配合使用。在JDK1.5時期，HotSpot推出了一款在強交互應用劃時代的收集器CMS，這款收集器是HotSpot第一款真正意義上的并發(fā)收集器，第一次實現了垃圾回收與工作線程同時工作的可能性，換而言之，你可以邊污染，邊收集。

不過CMS作為老年代的收集器，卻無法與1.4中發(fā)布的最新的新生代垃圾收集器配合使用，反之只能使用Serial或者Parnew中的一個。ParNew收集器可以使用-XX:+UseParNewGC強行指定它，或者使用-XX:+UseConcMarkSweepGC選項后的默認新生代收集器。

ParNew收集器在單CPU環(huán)境下絕對不會有比Serial收集器更好的效果，甚至優(yōu)于存在線程交互開銷，該收集器在通過超線程技術實現的兩個CPU的環(huán)境下都不能保證百分之百超越Serial收集器。當然，隨著CPU數量的增加，對于GC時系統(tǒng)的有效資源利用還是很有好處的。在CPU非常多的情況下，可以使用-XX:ParallelGCThreads來限制垃圾回收線程的數量。

Parallel Scavenge收集器

Parallel Scavenge收集器是一個新生代收集器，采用復制算法，又是并行的多線程垃圾收集器。它的關注點與其它收集器的關注點不一樣，CMS等收集器的關注點在于縮短垃圾回收時用戶線程停止的時間，而Parallel Scavenge收集器則是達到一個可控制的吞吐量，所謂吞吐量就是CPU運行用戶線程的時間與CPU運行總時間的比值，即 吞吐量 = (用戶線程工作時間)/(用戶線程工作時間 + 垃圾回收時間)，比如虛擬機總共運行100分鐘，垃圾收集消耗1分鐘，則吞吐量為99%。停頓時間越短越適合與用戶交互的程序，良好的響應速度能提高用戶體驗，但是高吞吐量則可以高效率的利用CPU的時間，盡快完成程序的運算任務，主要適合在后臺運算而不需要太多交互的程序。

有兩個參數控制吞吐量，分別為最大垃圾收集時間： -XX:MaxGCPauseMills， 直接設置吞吐量的大小: -XX:GCTimeRatio

-XX:+UseAdaptiveSizePolicy

自適應策略也是Parallel Scavenge收集器區(qū)別去Parnew收集器的重要一點

Serial Old收集器

Serial Old收集器是Serial收集器的老年代版本，它同樣是一個單線程收集器，使用標記-整理算法，這個收集器的主要目的也是在與給Client模式下使用。如果在Server模式下，還有兩種用途，一種是在jdk5以前的版本中配合Parallel Scavenge收集器使用，另一種用途作為CMS的備用方案，在并發(fā)收集發(fā)生Concurrent Mode Failure時使用。

Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多線程和標記-整理算法，這個收集器在jdk6中才開始使用的，在此之前Parallel Scavenge收集器一直處于比較尷尬的階段，原因是，如果新生代采用了Parallel Scavenge收集器，那么老年代除了Serial Old之外，別無選擇，由于老年代Serial在服務端的拖累，使得使用了Parallel Scavenge收集器也未必能達到吞吐量最大化的效果，由于單線程的老年代無法充分利用服務器多CPU的處理能力，在老年代很大而且硬件比較高級的環(huán)境中，這種組合的吞吐量甚至不如Parallel Scavenge收集器 + CMS。

直到Parallel Old收集器出現后，"吞吐量優(yōu)先收集器"終于有了名副其實的組合，在注重吞吐量優(yōu)先和CPU資源敏感的場合，可以采用Parallel Scavenge收集器 + Parallel Old收集器。

CMS收集器

CMS收集器是一種以獲取最短停頓時間為目標的收集器。從名字(Concurrent Mark Sweep)上就可以看出，采用的標記-清除算法，它的過程分為4個步驟：

只有初始標記和重新標記需要暫停用戶線程。

(1)初始標記 --- 僅僅關聯GC Roots能直接關聯到的對象，速度很快;

(2)并發(fā)標記 --- 進行GC Roots Tracing的過程;

(3)重新標記 --- 為了修正并發(fā)標記期間，因用戶程序運作而導致標記產生變動的那一部分對象的標記記錄;

(4)并發(fā)清除

由于整個過程中耗時最長的并發(fā)標記和并發(fā)清除過程收集器都能與用戶線程一起工作，所以總的來說，CMS的內存回收過程與用戶線程一起并發(fā)執(zhí)行的

CMS收集器的三大缺點：

(1)CMS收集器對CPU資源非常敏感

(2)無法處理浮動垃圾

(3)因為基于標記清除算法，所以會有大量的垃圾碎片產生 -XX:+UseCMSCompactAtFullCollection

G1收集器

首先，G1的設計原則就是簡單可行的性能調優(yōu)

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200

其中-XX:+UseG1GC為開啟G1垃圾收集器，-Xmx32g 設計堆內存的最大內存為32G，-XX:MaxGCPauseMillis=200設置GC的最大暫停時間為200ms。如果我們需要調優(yōu)，在內存大小一定的情況下，我們只需要修改最大暫停時間即可。

(1)內存分配

(2)Young垃圾回收

(3)Mix垃圾回收

常見設置參數:

添加QQ（注意~~添加好友界面，選擇找人）：435946716，【免費】獲取《JVM核心教程：JVM從門到精通_JVM虛擬機底層原理深入教程》全套視頻教程+配套資料。

猜你喜歡

Java中的垃圾回收機制是什么？哪些對象會被回收？

垃圾收集算法有哪些?圖文詳細介紹

JVM組成部分和作用詳細介紹

傳智教育JavaEE高手班課程