【擁抱大廠系列】面試官100%會嚴刑拷打的 CMS 垃圾回收器，下次面試就拿這篇文章懟回去！

這裏跟你們講個面試的最多見的垃圾回收器的問題，我跟大夥說，你不用懷疑，CMS垃圾回收器必定是最多見的問題，只要問到了Java虛擬機，面試官巴不得就問你CMS，固然還有就是G1這個垃圾回收器了，因此，關於這個垃圾回收器的細節問題，必定要掌握好，只要掌握到位，那麼必定可讓面試官滿意。

可是，說句糟心的話，運氣很差，面試官就是不對眼，也是沒有辦法的事情，只能認栽，自我感受再良好，也只是自我感受，在面試官內心，你就是渣渣！！！

好了，下面咱們開始面試環節，這篇文章想換一種方式，咱們列舉一些面試常見的問題，而後再來回答這些問題。

正文

這個春天，由於疫情的緣由，全部的面試都是線上遠程面試的，因此，若是運氣好，你能夠看到面試官的臉，若是運氣很差，你能夠只能被面試官看到你緊張的樣子，而你，看到的只是黑屏，哈哈！

這就是最真實的場景！

但是，並無面試官的身影，只有一次又一次的毒打！！

點個贊，看一看，好習慣！本文 GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收錄，這是我花了3個月總結的一線大廠Java面試總結，本人已拿騰訊等大廠offer。

小夥子，你說一下 CMS 垃圾回收器吧！

這個題目一來，嚇出一身冷汗，差點就沒有複習這個CMS，還好昨晚抱佛腳看了一下哈。

因而我。。。一頓操做猛如虎。

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間爲目標的收集器，它是基於「標記-清除」算法實現的，而且常見的應用場景是互聯網站或者B/S系統的服務端上的Java應用。

結果就一緊張就記得這麼多，面試官確定不滿意了，這個時候，面試官的常規操做是，繼續嚴刑拷打，他想，你可能忘記了，我來提醒提醒你！

CMS收集器工做的整個流程是怎麼樣的，你能給我講講嗎？

這個時候，面試官還會安慰你說不用緊張，可是，安慰歸安慰，最後掛不掛但是另外一回事。

因而，我又開始回答問題。

CMS 處理過程有七個步驟：

• 初始標記,會致使stw;
• 併發標記，與用戶線程同時運行；
• 預清理，與用戶線程同時運行；
• 可被終止的預清理，與用戶線程同時運行；
• 從新標記 ，會致使swt；
• 併發清除，與用戶線程同時運行；

其實，只要回答四個就差很少了，是這幾個。

• 初始標記：僅僅只是標記一下GC Roots能直接關聯到的對象，速度很快，須要「Stop The World」。
• 併發標記：進行GC Roots Tracing的過程，在整個過程當中耗時最長。
• 從新標記：爲了修正併發標記期間因用戶程序繼續運做而致使標記產生變更的那一部分對象的標記記錄，這個階段的停頓時間通常會比初始標記階段稍長一些，但遠比並發標記的時間短。此階段也須要「Stop The World」。
• 併發清除。

你覺得這樣子就能夠了，面試官就會說能夠了，若是能夠了，那估計你涼了！

面試官說：CMS這麼好，那有沒有什麼缺點呢？

我。。。好吧，誰怪我這麼強呢，對吧。

其實，CMS雖然通過這麼些年的考驗，已是一個值得信賴的GC回收器了，可是，其實也是有一些他的不足的，

第一，垃圾碎片的問題，咱們都知道CMS是使用的是標記-清除算法的，因此不可避免的就是會出現垃圾碎片的問題。
第二，通常CMS的GC耗時80%都在remark階段，remark階段停頓時間會很長，在CMS的這四個主要的階段中，最費時間的就是從新標記階段。
第三，concurrent mode failure，說出這個的時候，面試官就會以爲，小夥子，哎呦，不錯喲，掌握的比較清楚，那這個是什麼意思呢，實際上是說：

這個異常發生在cms正在回收的時候。執行CMS GC的過程當中，同時業務線程也在運行，當年輕帶空間滿了，執行ygc時，須要將存活的對象放入到老年代，而此時老年代空間不足，這時CMS尚未機會回收老年帶產生的，或者在作Minor GC的時候，新生代救助空間放不下，須要放入老年代，而老年代也放不下而產生的。

第四，promotion failed，這個問題是指，在進行Minor GC時，Survivor空間不足，對象只能放入老年代，而此時老年代也放不下形成的，多數是因爲老年代有足夠的空閒空間，可是因爲碎片較多，新生代要轉移到老年帶的對象比較大,找不到一段連續區域存放這個對象致使的。

面試官看到你掌握的這麼好，內心已經給你豎起來大拇指，可是，面試官以爲你優秀啊，就還想看看你到底還有多少東西。

既然你知道有這麼多的缺點，那麼你知道怎麼解決這些問題嗎？

這個真的被問蒙了，你覺得我什麼都會嗎！！！！

可是，我仍是得給你們講講，否則下次被問到，可能會把鍋甩給我。

• 垃圾碎片的問題：針對這個問題，這時候咱們須要用到這個參數：-XX:CMSFullGCsBeforeCompaction=n 意思是說在上一次CMS併發GC執行事後，到底還要再執行多少次full GC纔會作壓縮。默認是0，也就是在默認配置下每次CMS GC頂不住了而要轉入full GC的時候都會作壓縮。
• concurrent mode failure

解決這個問題其實很簡單，只須要設置兩個參數便可

-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=60：是指設定CMS在對內存佔用率達到60%的時候開始GC。

爲何設置這兩個參數呢？因爲在垃圾收集階段用戶線程還須要運行，那也就還須要預留有足夠的內存空間給用戶線程使用，所以CMS收集器不能像其餘收集器那樣等到老年代幾乎徹底被填滿了再進行收集。

固然也不能設置太高，好比90%，這時候雖然GC次數少，可是，卻會致使用於用戶線程空間小，效率不高，過低10%，你本身想一想會怎麼樣，體會體會！

哈哈，萬事大吉，這一點說出了，估計面試官已經愛上我了吧，趕忙把我招進去幹活吧。。。

• remark階段停頓時間會很長的問題：解決這個問題巨簡單，加入-XX:+CMSScavengeBeforeRemark。在執行remark操做以前先作一次Young GC，目的在於減小年輕代對老年代的無效引用，下降remark時的開銷。

結尾

面到這裏，面試官給你說了一句：小夥子很優秀，思考問題很深刻，何時能夠來咱們公司實習，咱們公司轉正概率很高啊，歡迎您的加入！