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

這里跟大家講個面試的最常見的垃圾回收器的問題，我跟大伙說，你不用懷疑，CMS垃圾回收器一定是最常見的問題，只要問到了Java虛擬機，面試官恨不得就問你CMS，當然還有就是G1這個垃圾回收器了，所以，關于這個垃圾回收器的細節問題，一定要掌握好，只要掌握到位，那么一定可以讓面試官滿意。

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

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

正文

這個春天，因為疫情的原因，所有的面試都是線上遠程面試的，所以，如果運氣好，你可以看到面試官的臉，如果運氣不好，你可以只能被面試官看到你緊張的樣子，而你，看到的只是黑屏，哈哈！

這就是最真實的場景！

可是，并沒有面試官的身影，只有一次又一次的毒打！！

小伙子，你說一下 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時的開銷。

結尾

面到這里，面試官給你說了一句：小伙子很優秀，思考問題很深入，什么時候可以來我們公司實習，我們公司轉正幾率很高啊，歡迎您的加入！

另外，我花了3個月時間把Java學習和面試的總結整理成了一本電子書！目錄如下

現在免費分享大家，在我的公眾號好好學java回復Java面試即可獲取。

有收獲？希望老鐵們來個三連擊，給更多的人看到這篇文章

1、老鐵們，關注我的原創微信公眾號「好好學java」，專注于Java、數據結構和算法、微服務、中間件等技術分享，保證你看完有所收獲。

2、給俺點個贊唄，可以讓更多的人看到這篇文章，順便激勵下我繼續寫作，嘻嘻。

點贊是對我最大的鼓勵
↓↓↓↓↓↓

總結

以上是生活随笔為你收集整理的【拥抱大厂系列】面试官100%会严刑拷打的 CMS 垃圾回收器，下次面试就拿这篇文章怼回去！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。