看著面試官真誠的眼神，心中暗想看起來年紀輕輕卻提出如此直擊靈魂的問題。擦了擦額頭上汗，我稍微調(diào)整了一下緊張的情緒，對面試官說：

在JDK8中有Serial收集器、Parallel收集器、CMS收集器、G1收集器這么幾種收集器，需要根據(jù)實際硬件配置和業(yè)務需求進行選擇調(diào)優(yōu)。

如此淺顯的回答，無法讓面試官達到深入的要求，肯定不能滿足面試官強烈的需求，果不其然面試官又追問到：如果是桌面應用，內(nèi)存占用也就100MB，應該選擇哪種垃圾收集器呢？我快速的回答：Serial收集器。看著面試官期待的眼神，我又詳細解釋到：

Serial收集器

Serial收集器是使用單線程處理所有的垃圾收集工作的，因為沒有多線程的額外開銷，相對來說也是比較有效的。所以，最適合單核CPU環(huán)境，因為本來也沒辦法利用多核。不過，當應用的使用的內(nèi)存大小在100MB左右甚至更小的時候，在也適用于多核CPU的環(huán)境。

我一邊說著，一邊在紙上畫了起來：

Client模式的JVM默認的垃圾收集器就是Serial收集器，或者可以使用JVM參數(shù)-XX:+UseSerialGC顯式啟用Serial收集器。

面試官又追問到：如果是要求高吞吐量的應用，使用較大內(nèi)存并且有多核CPU，應該選擇哪種垃圾收集器呢？我快速的回答：Parallel收集器?？粗嬖嚬倨诖难凵瘢矣衷敿毥忉尩剑?/p>

Parallel收集器

Parallel收集器是類似于Serial收集器的分代收集器，主要區(qū)別是在垃圾回收的時候使用了多個線程進行加速垃圾的收集。所以，對于使用較大內(nèi)存并且有多核CPU的環(huán)境更加適合。

我一邊說著，一邊在紙上畫了起來：

Server模式的JVM默認的垃圾收集器就是Parallel收集器，也可以使用JVM參數(shù)-XX:+UseParallelGC啟用。啟用Parallel收集器后默認情況下，Minor垃圾收集（針對年輕代的垃圾收集）和Major垃圾收集（針對老年代的垃圾收集）都是并行執(zhí)行的，可以進一步減少垃圾收集的開銷。

Parallel收集器可以通過JVM參數(shù)指定最大垃圾收集暫停時間、吞吐量（用戶代碼運行時間/(用戶代碼運行時間+垃圾收集運行時間)）和堆占用空間的目標值：

• -XX:MaxGCPauseMillis：最大垃圾收集暫停時間，單位為毫秒，如：-XX:MaxGCPauseMillis=200，表示垃圾收集暫停時間最大為200毫秒。默認情況下，沒有指定最大垃圾收集暫停時間。如果指定了暫停時間目標，則會調(diào)整堆大小與垃圾收集相關(guān)的其他參數(shù)，使垃圾收集的暫停時間短于指定值。這些調(diào)整可能導致降低應用的整體吞吐量，也有可能無法始終滿足所指定的最大垃圾收集暫停時間目標。
• -XX:GCTimeRatio：吞吐量大小，如：-XX:GCTimeRatio=19，表示將垃圾收集運行時間的目標設(shè)定為應用總運行時間（用戶代碼運行時間+垃圾收集運行時間）的1/(1+19)，即5%。默認值為99，垃圾收集的目標時間占應用總運行時間的1/(1+99)，即1％。
• -Xmx：堆占用的最大占用空間，如：-Xmx1G，表示堆占用的最大占用空間為1GB。另外，Parallel收集器還有一個隱含的目標：只要滿足其他目標的同時，把堆占用內(nèi)存的大小最小化。

這三個目標是有優(yōu)先級的：

1. 高優(yōu)先級：最大垃圾收集暫停時間
2. 中優(yōu)先級：吞吐量目標
3. 低優(yōu)先級：最小堆占用內(nèi)存目標

Parallel收集器按照指定的目標對分代大小和底層進行自動調(diào)節(jié)，盡量達到指定的目標，但不保證百分之百能達到。

面試官又追問到：如果同樣是使用較大內(nèi)存并且有多核CPU，但是要求垃圾收集暫停時間要盡可能短的Web應用，應該選擇哪種垃圾收集器呢？我稍微思考了一下，回答：CMS收集器?？粗嬖嚬倨诖难凵?，我又詳細解釋到：

CMS收集器

CMS（Concurrent Mark Sweep）收集器是為那些要求垃圾收集暫停時間盡可能短，并且可以和垃圾收集器共享CPU資源的應用設(shè)計的。具有相對較大的內(nèi)存使用并有多核CPU的應用，往往會更適合CMS收集器的使用?？梢允褂肑VM參數(shù)-XX:+UseConcMarkSweepGC啟用CMS收集器，啟用后同時作用于Minor垃圾收集（針對年輕代的垃圾收集）和Major垃圾收集（針對老年代的垃圾收集）。

CMS收集器嘗試通過使用單獨的垃圾收集器線程在執(zhí)行用戶線程的同時并跟蹤可訪問對象，來減少由于Major垃圾收集而導致的暫停時間。在每個Major垃圾收集周期中，CMS收集器會在收集開始時暫停所有用戶線程一小段時間，然后在收集的中期再次暫停。第二個暫停往往是兩個暫停中較長的一個，在兩個暫停之間都使用多個線程并行做收集工作的。所以，CMS收集器的垃圾收集過程分為以下四個步驟：

1. 初始標記（CMS initial mark）：這個步驟會暫停所有用戶線程，但耗時非常短，標記GC Root直接關(guān)聯(lián)的對象。
2. 并發(fā)標記（CMS concurrent mark）：這個步驟耗時較長，但用戶線程可同時運行，標記至GC Root有可達路徑的對象。
3. 重新標記（CMS remark）：這個步驟會暫停所有用戶線程，但耗時比較短。由于步驟2用戶線程同步運行，所以要修正在步驟二中用戶線程同步運行產(chǎn)生對象標記的變動。
4. 并發(fā)清除（CMS concurrent sweep）：這個步驟耗時較長，但用戶線程可同時運行。

我一邊說著，一邊在紙上畫了起來：

面試官繼續(xù)追問到：如果堆中有超過50%的活躍對象，分配對象和對象升代的頻率較高，垃圾收集停頓時間大于0.5秒，應該選擇哪種垃圾收集器呢？我稍微思考了一下，回答：G1收集器。看著面試官期待的眼神，我又詳細解釋到：

G1收集器

G1（Garbage-First）收集器是一款主要面向服務端應用的垃圾收集器，適用于具有大內(nèi)存的多核CPU的服務器。它嘗試在高概率下同時滿足較小的垃圾收集暫停時間和較高的吞吐量。所有堆相關(guān)的操作（如：全局標記）與用戶線程同時運行，這樣可以避免隨著堆內(nèi)存的大小的增加垃圾收集的停頓時間也跟著增加。

G1收集器是垃圾收集技術(shù)歷史上里程碑的成果，它跳出了之前收集整個代垃圾的思維模式，開創(chuàng)了收集器面向局部收集的設(shè)計思路和基于Rigion的內(nèi)存布局形式。在之后的JDK版本中，G1收集器正在逐漸成為了CMS收集器的替代者和繼任者。

G1收集器雖然遵循分代收集的設(shè)計，但是整個堆的內(nèi)存設(shè)計有顯著的不同。整個堆被劃分為一組大小相等的獨立區(qū)域（Region），每個獨立區(qū)域（Region）都有一個連續(xù)的虛擬內(nèi)存范圍，并且根據(jù)需要在邏輯被劃分為年輕代的Eden區(qū)、Survivor區(qū)或者老年代。

我一邊說著，一邊在紙上畫了起來：

通過JVM參數(shù)-XX:MaxGCPauseMillis來給G1收集器指定垃圾收集的目標停頓時間，默認是200毫秒。G1收集器會使用預測模型來估算停頓時間內(nèi)可以收集多少個獨立區(qū)域。在一次垃圾回收結(jié)束時，G1收集器會選擇下次將要收集哪些獨立區(qū)域。通常情況下，G1收集器通過選擇年輕代獨立區(qū)域的數(shù)量來控制垃圾收集的停頓時間。與其他垃圾收集器一樣，可以通過參數(shù)指定年輕代的大小，但是這樣做可能會影響G1收集器達到停頓時間目標的效果。除了停頓時間目標之外，還可以通過JVM參數(shù)-XX:GCPauseIntervalMillis指定停頓的間隔時長，默認是0。

聽了我的回答后，面試官對我會心一笑，我仿佛還在她的眼神中看到了一絲傾慕。正所謂：金風玉露一相逢，便勝卻人間無數(shù)，欲知后事如何，且聽下回分解。

總結(jié)

到此這篇關(guān)于面試官：怎么做JDK8的垃圾收集器的調(diào)優(yōu)(面試常問)的文章就介紹到這了,更多相關(guān)JDK8的垃圾收集器的調(diào)優(yōu)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論