JVM-CMS垃圾回收器

CMS垃圾回收的步驟

1. 初始標(biāo)記（InitialMarking）

1. 這是一個(gè)STW的過程，并行標(biāo)記，只是標(biāo)記GC Roots能直接關(guān)聯(lián)到的對象。
2. 由于GC Root直接關(guān)聯(lián)的對象少，因此STW時(shí)間比較短。

2. 并發(fā)標(biāo)記

1. 非STW的過程，并發(fā)標(biāo)記，業(yè)務(wù)線程和GC線程同時(shí)運(yùn)行，由CPU進(jìn)行調(diào)度。這里標(biāo)記的算法是三色標(biāo)記算法
2. 由于并發(fā)標(biāo)記，在標(biāo)記過程中會導(dǎo)致對象之間的引用發(fā)生變化，采用增量更新方法解決這個(gè)問題

3. 重新標(biāo)記

1. STW的過程，重新標(biāo)記在并發(fā)標(biāo)記過程中引用發(fā)生了變化或者新產(chǎn)生的對象。主要包括：
2. 年輕代對象晉升到老年代，可能產(chǎn)生新的存活對象；
3. 大對象直接被分配到老年代，可能產(chǎn)生新的存活對象；
4. 老年代和年輕代對象的引用關(guān)系發(fā)生變化

4. 并發(fā)清除

1. 最后，GC線程會清除不再被引用的對象，并回收他們占用的內(nèi)存空間
2. 非STW，由于前面的標(biāo)記階段已經(jīng)將還在使用的對象標(biāo)記了出來
3. 在此過程中新產(chǎn)生的垃圾只能等待下次GC

CMS特點(diǎn)與問題

1. Concurrent mark sweep并發(fā)標(biāo)記清除，在CMS之前都是STW的。
2. 浮動垃圾問題
3. CPU要求高：CMS默認(rèn)啟動的回收線程數(shù)為（CPU數(shù)量+3）/4，當(dāng)CPU不足4個(gè)時(shí)候，效率低
4. 標(biāo)記清除算法導(dǎo)致內(nèi)存碎片化嚴(yán)重

小結(jié)：CMS從提出概念到實(shí)際完成用了10年多的時(shí)間，在此之前沒有過并發(fā)回收的垃圾回收器，因此它是一個(gè)垃圾回收器的里程碑，后來的G1也是基于CMS做的一些改進(jìn)。由于CMS是并發(fā)清除的新時(shí)代，它也存留了很多問題，JDK任何版本都不會使用CMS作為默認(rèn)垃圾回收器。

三色標(biāo)記算法

1. 它是一個(gè)標(biāo)記算法，不負(fù)責(zé)清除。
2. 從root開始遍歷鏈表，并用白、灰、黑三種顏色來標(biāo)記對象的狀態(tài)。
3. 沒有被標(biāo)記過的為白色；被標(biāo)記過但是沒有遍歷完其子節(jié)點(diǎn)的標(biāo)記為灰色；對象本身及其子節(jié)點(diǎn)都被遍歷過的標(biāo)記為黑色。
4. 多標(biāo)問題：在標(biāo)記完成后對象引用斷開，被引用對象變?yōu)槔鴮ο?#xff0c;但是已經(jīng)被標(biāo)記過了，產(chǎn)生浮動垃圾，這個(gè)問題并不大，等待下次GC即可
5. 漏標(biāo)問題：至少有一個(gè)黑色對象新增了對白色對象的引用，所有灰色對象指向該白色對象的引用都斷開了，這個(gè)問題比較嚴(yán)重，CMS使用增量更新的方法解決。

CMS如何解決漏標(biāo)問題

incremental update:增量更新，關(guān)注引用的增加，如果要給黑色對象引用增加，將黑色對象標(biāo)記為灰色