前言
上文已經講解垃圾收集的各種算法,算法可以理解爲方法,如果說收集算法是內存回收的方法論,那麼垃圾收集器就是內存回收的具體實現。
正文
目錄
面試官:你認識到的收集器都有哪些啊?
答:Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1;
面試官:爲什麼HotSpot虛擬機需要這麼多收集器?
答:HotsSpot垃圾是分代收集的,所以不用的分代收集器也不同,即使是同一年代裏收集器也會不同,因爲每個收集器特點和性能不同也就有了收集器的多樣性,所以各個收集器互相組合使用才能適應不同場景。
面試官:那你說一下每個收集器都有什麼特點吧!
新生代收集器:Serial、ParNew、Parallel Scavenge;
老年代收集器:Serial Old、Parallel Old、CMS;
整堆收集器:G1;
開始之前我們瞭解一個概念
Minor GC
又稱新生代GC,指發生在新生代的垃圾收集動作;
因爲Java對象大多是朝生夕滅,所以Minor GC非常頻繁,一般回收速度也比較快;
Full GC
又稱Major GC或老年代GC,指發生在老年代的GC;
出現Full GC經常會伴隨至少一次的Minor GC(不是絕對,Parallel Sacvenge收集器就可以選擇設置Major GC策略);
Major GC速度一般比Minor GC慢10倍以上;
Serial收集器
這個收集器是最基本的,也是歷史最悠久的收集器,目前基本不會用了,想當年那也是新生代的唯一選擇,但是這麼多年過去了,HotSpot也沒有說過河拆橋把它廢了,“老而無用、食之無味棄之可惜”。
他是一個單線程收集器,他在工作的時候,必須暫停其他所有的工作線程,直到收集結束。這裏要知道一個很嚴重的問題就是,暫停一切線程的結果就是當前運行在這個JDK的所有程序裏的用戶線程全部暫停,也就是說這一瞬間都是死掉的,用戶看到的現象就是頁面無任何響應,如果這種現象出現的時間長且頻繁用戶就崩潰了。
這裏埋下了一個伏筆,越優秀的收集器,他的停頓時間一定越短,這也是所有收集器共同追求的目標。
ParNew收集器
他是Serial收集器多線程版本,其所有控制參數、收集算法、對象分配規則、回收策略等都與Serial完全一樣。下面是ParNew收集器工作的過程。
他的重要之處在於,除了多線程提高了性能之外,他還可以與CMS收集器(下面介紹)搭配使用的原因。
在單CPU環境下ParNew的性能沒辦法超過Serial,但是隨着CPU數量增多他的優勢就會越來越明顯。
Parallel Scavenge收集器
他也是一款新生代收集器,使用的是複製算法,並且是並行對線程收集器。可以看到收集器的進步都是保留上一代之長,彌補上一代之短。
很多收集器關注用戶線程的停頓時間,但是Parallel Scavenge則關注吞吐量。所謂吞吐量就是CPU用於運行用戶代碼的時間與CPU總消耗時間的比值,即吞吐量=運行用戶代碼時間/(運行用戶代碼時間+垃圾收集時間),例:虛擬機運行100分鐘,其中垃圾收集時間用了1分鐘,那吞吐量就是99%。
他是怎樣控制吞吐量呢?
使用參數控制最大垃圾收集停頓時間 -XX:MaxGCPauseMillis ,以及直接設置吞吐量大小 -XX:GCTimeRatio參數。
MaxGCPauseMillis參數是一個大於0的毫秒數,收集器一次工作儘可能不超過設定的這個值,但是設置太小GC停頓時間縮短,造成了垃圾收集頻率變快。如果你設定停頓100毫秒,10秒收集一次的頻率,改成70毫秒的停頓時間,那麼頻率就可能變成5秒一次。停頓時間下降,吞吐量也會下降,GC還會變得更頻繁。
XX:GCTimeRatio參數設置垃圾收集時間佔總時間的比率,0<n<100的整數;
GCTimeRatio相當於設置吞吐量大小;
垃圾收集執行時間佔應用程序執行時間的比例的計算方法是:1 / (1 + n)
例如,選項-XX:GCTimeRatio=19,設置了垃圾收集時間佔總時間的5%--1/(1+19);
默認值是1%--1/(1+99),即n=99;
看來找準最優的臨界點真的是Parallel Scavenge收集器比較配置的。
不要擔心,HotSpot又提供了一個參數 XX:+UseAdptiveSizePolicy幫助我們實現GC自適應的調節策略,他會根據當前系統運行情況收集性能監控信息,動態調整這些參數,以提供最合適的停頓時間或最大的吞吐量。
這個參數開啓,JVM就可以動態分配新生代的大小(-Xmn)、Eden與Survivor區的比例(-XX:SurvivorRation)、晉升老年代的對象年齡(-XX:PretenureSizeThreshold)等;
這裏插入一個筆者的經歷:當時面試有人問我,Eden與Survivor區的比例可以變化嗎?
看到這裏童鞋們就可以回答:Parallel Scavenge收集器開啓 XX:+UseAdptiveSizePolicy可以動態分配。
這也是Parallel Scavenge收集器優越於ParNew收集器一個重要點。
Serial Old收集器
Serial Old是 Serial收集器的老年代版本,也是繼承Serial收集器單線程的特點。
工作模型圖在Serial收集器中展示了。
Parallel Old收集器
Parallel Old垃圾收集器是Parallel Scavenge收集器的老年代版本,繼承了Parallel New多線程對特點,在JDK1.6及之後用來代替老年代的Serial Old收集器;
參數"-XX:+UseParallelOldGC":指定使用Parallel Old收集器;
工作模型圖在Parallel New收集器中展示了。
接下來講解CMS於G1收集器,在將之前要理解一個概念
可能前面也提到過,不過在這裏瞭解以下也不晚
並行(Parallel)
指多條垃圾收集線程並行工作,但此時用戶線程仍然處於等待狀態;
如ParNew、Parallel Scavenge、Parallel Old;
併發(Concurrent)
指用戶線程與垃圾收集線程同時執行(但不一定是並行的,可能會交替執行);
用戶程序在繼續運行,而垃圾收集程序線程運行於另一個CPU上;
如CMS、G1(也有並行);
CMS收集器
併發標記清理收集器也稱爲併發低停頓收集器或低延遲垃圾收集器;他的宗旨是:低停頓。
HotSpot在JDK1.5推出的第一款真正意義上的併發(Concurrent)收集器;
他採用的是“標記-清除算法",因此會生大量的空間碎片。爲了解決這個問題,CMS可以通過配置以下兩種參數解決:
-
-XX:+UseCMSCompactAtFullCollection:參數,強制JVM在FGC完成後対老年代迸行圧縮,執行一次空間碎片整理,但是空間碎片整理階段也會引發STW。爲了減少STW次數,CMS還可以通過配置。
-
-XX:+CMSFullGCsBeforeCompaction=n :參數,在執行了n次FGC後, JVM再在老年代執行空間碎片整理
初始標記 (Initial Mark)
停止一切用戶線程,僅使用一條初始標記線程對所有與GC Roots直接相關聯的 老年代對象進行標記,速度很快
併發標記 (Concurrent Marking Phase)
使用多條併發標記線程並行執行,並與用戶線程併發執行.此過程進行可達性分析,標記所有這些對象可達的存貨對象,速度很慢
重新標記 ( Remark)
因爲併發標記時有用戶線程在執行,標記結果可能有變化
停止一切用戶線程,並使用多條重新標記線程並行執行,重新遍歷所有在併發標記期間有變化的對象進行最後的標記.這個過程的運行時間介於初始標記和併發標記之間
併發清除 (Concurrent Sweeping)
只使用一條併發清除線程,和用戶線程們併發執行,清除剛纔標記的對象
這個過程非常耗時
G1收集器
G1(Garbage-First)是JDK7-u4才推出商用的收集器;他比CMS更高級了,他是並行與併發,能充分利用多CPU、多核環境下的硬件優勢;
G1以下特點
並行與併發
能充分利用多CPU、多核環境下的硬件優勢;
可以並行來縮短"Stop The World"停頓時間;
也可以併發讓垃圾收集與用戶程序同時進行;
分代收集,收集範圍包括新生代和老年代
能獨立管理整個GC堆(新生代和老年代),而不需要與其他收集器搭配;
能夠採用不同方式處理不同時期的對象;
雖然保留分代概念,但Java堆的內存佈局有很大差別;
將整個堆劃分爲多個大小相等的獨立區域(Region);
新生代和老年代不再是物理隔離,它們都是一部分Region(不需要連續)的集合;
結合多種垃圾收集算法,空間整合,不產生碎片
從整體看,是基於標記-整理算法;
從局部(兩個Region間)看,是基於複製算法;
這是一種類似火車算法的實現;
都不會產生內存碎片,有利於長時間運行;
可預測的停頓:低停頓的同時實現高吞吐量
G1除了追求低停頓處,還能建立可預測的停頓時間模型;
可以明確指定M毫秒時間片內,垃圾收集消耗的時間不超過N毫秒;
如:在堆大小約6GB或更大時,可預測的暫停時間可以低於0.5秒;
用來替換掉JDK1.5中的CMS收集器;
上面提到Region 概念,肯定都不會理解,讓我們看一下G1的內存模型
G1將Java堆空間分割成了若干相同大小的區域,即region
Humongous是特殊的Old類型,專門放置大型對象
在JDK11中,已經將G1設爲默認垃圾回收器
G1垃圾收集過程
初始標記
標記與GC Roots直接關聯的對象,停止所有用戶線程,只啓動一條初始標記線程,這個過程很快。
併發標記
進行全面的可達性分析,開啓一條併發標記線程與用戶線程並行執行.這個過程比較長。
最終標記
標記出併發標記過程中用戶線程新產生的垃圾.停止所有用戶線程,並使用多條最終標記線程並行執行。
篩選回收
回收廢棄的對象.此時也需要停止一切用戶線程,並使用多條篩選回收線程並行執行。
題外話:我們知道目前爲止JDK8是應用最廣泛對版本,並且JDK9、10是一個過度版,企業應用效果不好,JDK11是一個里程碑版本,重要程度相當於現在JDK8,並且JDK11默認使用G1收集器,G1的性能在早些年就突出於CMS並且官方對性能測試結果也是這樣說明的。