你对JVM三色标记的理解嘛？
點擊上方“朱小廝的博客”，選擇“設為星標”
后臺回復"書"，獲取
后臺回復“k8s”，可領取k8s資料
三色標記法是一種垃圾回收法，它可以讓JVM不發生或僅短時間發生STW(Stop The World)，從而達到清除JVM內存垃圾的目的。JVM中的CMS、G1垃圾回收器所使用垃圾回收算法即為三色標記法。
三色標記算法思想
三色標記法將對象的顏色分為了黑、灰、白，三種顏色。
白色：該對象沒有被標記過。（對象垃圾）
灰色：該對象已經被標記過了，但該對象下的屬性沒有全被標記完。（GC需要從此對象中去尋找垃圾）
黑色：該對象已經被標記過了，且該對象下的屬性也全部都被標記過了。（程序所需要的對象）
img算法流程
從我們main方法的根對象（JVM中稱為GC Root）開始沿著他們的對象向下查找，用黑灰白的規則，標記出所有跟GC Root相連接的對象,掃描一遍結束后，一般需要進行一次短暫的STW(Stop The World)，再次進行掃描，此時因為黑色對象的屬性都也已經被標記過了，所以只需找出灰色對象并順著繼續往下標記（且因為大部分的標記工作已經在第一次并發的時候發生了，所以灰色對象數量會很少，標記時間也會短很多）, 此時程序繼續執行，GC線程掃描所有的內存，找出掃描之后依舊被標記為白色的對象（垃圾）,清除。
具體流程:
首先創建三個集合：白、灰、黑。
將所有對象放入白色集合中。
然后從根節點開始遍歷所有對象（注意這里并不遞歸遍歷），把遍歷到的對象從白色集合放入灰色集合。
之后遍歷灰色集合，將灰色對象引用的對象從白色集合放入灰色集合，之后將此灰色對象放入黑色集合
重復 4 直到灰色中無任何對象
通過write-barrier檢測對象有變化，重復以上操作
收集所有白色對象（垃圾）
三色標記存在問題
浮動垃圾：并發標記的過程中，若一個已經被標記成黑色或者灰色的對象，突然變成了垃圾，由于不會再對黑色標記過的對象重新掃描,所以不會被發現，那么這個對象不是白色的但是不會被清除，重新標記也不能從GC Root中去找到，所以成為了浮動垃圾，浮動垃圾對系統的影響不大，留給下一次GC進行處理即可。
對象漏標問題（需要的對象被回收）：并發標記的過程中，一個業務線程將一個未被掃描過的白色對象斷開引用成為垃圾（刪除引用），同時黑色對象引用了該對象（增加引用）（這兩部可以不分先后順序）；因為黑色對象的含義為其屬性都已經被標記過了，重新標記也不會從黑色對象中去找，導致該對象被程序所需要，卻又要被GC回收，此問題會導致系統出現問題，而CMS與G1，兩種回收器在使用三色標記法時，都采取了一些措施來應對這些問題，CMS對增加引用環節進行處理（Increment Update），G1則對刪除引用環節進行處理(SATB)。
解決辦法
在JVM虛擬機中有兩種常見垃圾回收器使用了該算法：CMS(Concurrent Mark Sweep)、G1(Garbage First) ，為了解決三色標記法對對象漏標問題各自有各自的法:
CMS回顧
CMS(Concurrent Mark Sweep)收集器是一種以獲取最短回收停頓時間為目標的收集器。目前很大一部分的Java應用集中在互聯網網站或者基于瀏覽器的B/S系統的服務端上，這類應用通常都會較為關注服務的響應速度，希望系統停頓時間盡可能短，以給用戶帶來良好的交互體驗。CMS收集器就非常符合這類應用的需求(但是實際由于某些問題,很少有使用CMS作為主要垃圾回收器的)。
從名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于標記-清除算法實現的，它的運作過程相對于前面幾種收集器來說要更復雜一些，整個過程分為四個步驟，包括：1）初始標記（CMS initial mark） 2）并發標記（CMS concurrent mark） 3）重新標記（CMS remark） 4）并發清除（CMS concurrent sweep）
其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。初始標記僅僅只是標記一下GCRoots能直接關聯到的對象，速度很快；
并發標記階段就是從GC Roots的直接關聯對象開始遍歷整個對象圖的過程，這個過程耗時較長但是不需要停頓用戶線程，可以與垃圾收集線程一起并發運行；
重新標記階段則是為了修正并發標記期間，因用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間通常會比初始標記階段稍長一些，但也遠比并發標記階段的時間短；
最后是并發清除階段，清理刪除掉標記階段判斷的已經死亡的對象，由于不需要移動存活對象，所以這個階段也是可以與用戶線程同時并發的。由于在整個過程中耗時最長的并發標記和并發清除階段中，垃圾收集器線程都可以與用戶線程一起工作，所以從總體上來說，CMS收集器的內存回收過程是與用戶線程一起并發執行的。
imgCMS解決辦法:增量更新
在應對漏標問題時，CMS使用了增量更新(Increment Update)方法來做：
在一個未被標記的對象（白色對象）被重新引用后，引用它的對象若為黑色則要變成灰色，在下次二次標記時讓GC線程繼續標記它的屬性對象。
但是就算是這樣，其仍然是存在漏標的問題：
在一個灰色對象正在被一個GC線程回收時，當它已經被標記過的屬性指向了一個白色對象（垃圾）
而這個對象的屬性對象本身還未全部標記結束，則為灰色不變
而這個GC線程在標記完最后一個屬性后，認為已經將所有的屬性標記結束了，將這個灰色對象標記為黑色，被重新引用的白色對象，無法被標記
CMS另兩個致命缺陷
CMS采用了Mark-Sweep算法，最后會產生許多內存碎片，當到一定數量時，CMS無法清理這些碎片了，CMS會讓Serial Old垃圾處理器來清理這些垃圾碎片，而Serial Old垃圾處理器是單線程操作進行清理垃圾的，效率很低。
所以使用CMS就會出現一種情況，硬件升級了，卻越來越卡頓，其原因就是因為進行Serial Old GC時，效率過低。
解決方案：使用Mark-Sweep-Compact算法，減少垃圾碎片
調優參數（配套使用）：
-XX:+UseCMSCompactAtFullCollection??開啟CMS的壓縮 -XX:CMSFullGCsBeforeCompaction?默認為0，指經過多少次CMS?FullGC才進行壓縮
當JVM認為內存不夠，再使用CMS進行并發清理內存可能會發生OOM的問題，而不得不進行Serial Old GC，Serial Old是單線程垃圾回收，效率低
解決方案：降低觸發CMS GC的閾值，讓浮動垃圾不那么容易占滿老年代
調優參數：
-XX:CMSInitiatingOccupancyFraction?92%?可以降低這個值，讓老年代占用率達到該值就進行CMS?GC
G1回顧
G1(Garbage First)物理內存不再分代，而是由一塊一塊的Region組成,但是邏輯分代仍然存在。G1不再堅持固定大小以及固定數量的分代區域劃分，而是把連續的Java堆劃分為多個大小相等的獨立區域（Region），每一個Region都可以根據需要，扮演新生代的Eden空間、Survivor空間，或者老年代空間。收集器能夠對扮演不同角色的Region采用不同的策略去處理，這樣無論是新創建的對象還是已經存活了一段時間、熬過多次收集的舊對象都能獲取很好的收集效果。
Region中還有一類特殊的Humongous區域，專門用來存儲大對象。G1認為只要大小超過了一個Region容量一半的對象即可判定為大對象。每個Region的大小可以通過參數-XX：G1HeapRegionSize設定，取值范圍為1MB～32MB，且應為2的N次冪。而對于那些超過了整個Region容量的超級大對象，將會被存放在N個連續的Humongous Region之中，G1的大多數行為都把Humongous Region作為老年代的一部分來進行看待，如圖所示
imgG1前置知識
Card Table（多種垃圾回收器均具備）
由于在進行YoungGC時，我們在進行對一個對象是否被引用的過程，需要掃描整個Old區，所以JVM設計了CardTable，將Old區分為一個一個Card，一個Card有多個對象；如果一個Card中的對象有引用指向Young區，則將其標記為Dirty Card，下次需要進行YoungGC時，只需要去掃描Dirty Card即可。
Card Table 在底層數據結構以?Bit Map實現。
RSet(Remembered Set)
是輔助GC過程的一種結構，典型的空間換時間工具，和Card Table有些類似。
后面說到的CSet(Collection Set)也是輔助GC的，它記錄了GC要收集的Region集合，集合里的Region可以是任意年代的。
在GC的時候，對于old->young和old->old的跨代對象引用，只要掃描對應的CSet中的RSet即可。邏輯上說每個Region都有一個RSet，RSet記錄了其他Region中的對象引用本Region中對象的關系，屬于points-into結構（誰引用了我的對象）。
而Card Table則是一種points-out（我引用了誰的對象）的結構，每個Card 覆蓋一定范圍的Heap（一般為512Bytes）。G1的RSet是在Card Table的基礎上實現的：每個Region會記錄下別的Region有指向自己的指針，并標記這些指針分別在哪些Card的范圍內。這個RSet其實是一個Hash Table，Key是別的Region的起始地址，Value是一個集合，里面的元素是Card Table的Index。每個Region中都有一個RSet，記錄其他Region到本Region的引用信息；使得垃圾回收器不需要掃描整個堆找到誰引用當前分區中的對象，只需要掃描RSet即可。
CSet(Collection Set)
一組可被回收的分區Region的集合, 是多個對象的集合內存區域。
新生代與老年代的比例
5% - 60%，一般不使用手工指定，因為這是G1預測停頓時間的基準,這地方簡要說明一下,G1可以指定一個預期的停頓時間,然后G1會根據你設定的時間來動態調整年輕代的比例,例如時間長,就將年輕代比例調小,讓YGC盡早行。
G1解決辦法:SATB
SATB(Snapshot At The Beginning), 在應對漏標問題時，G1使用了SATB方法來做,具體流程：
在開始標記的時候生成一個快照圖標記存活對象
在一個引用斷開后，要將此引用推到GC的堆棧里，保證白色對象（垃圾）還能被GC線程掃描到(在**write barrier(寫屏障)**里把所有舊的引用所指向的對象都變成非白的)。
配合Rset，去掃描哪些Region引用到當前的白色對象，若沒有引用到當前對象，則回收
SATB詳細流程
SATB是維持并發GC的一種手段。G1并發的基礎就是SATB。SATB可以理解成在GC開始之前對堆內存里的對象做一次快照，此時活的對像就認為是活的，從而開成一個對象圖。
在GC收集的時候，新生代的對象也認為是活的對象，除此之外其他不可達的對象都認為是垃圾對象。
如何找到在GC過程中分配的對象呢？每個region記錄著兩個top-at-mark-start(TAMS)指針，分別為prevTAMS和nextTAMS。在TAMS以上的對象就是新分配的，因而被視為隱式marked。
通過這種方式我們就找到了在GC過程中新分配的對象，并把這些對象認為是活的對象。
解決了對象在GC過程中分配的問題，那么在GC過程中引用發生變化的問題怎么解決呢？
G1給出的解決辦法是通過Write Barrier。Write Barrier就是對引用字段進行賦值做了額外處理。通過Write Barrier就可以了解到哪些引用對象發生了什么樣的變化。
mark的過程就是遍歷heap標記live object的過程，采用的是三色標記算法，這三種顏色為white（表示還未訪問到）、gray（訪問到但是它用到的引用還沒有完全掃描）、back（訪問到而且其用到的引用已經完全掃描完）。
整個三色標記算法就是從GC roots出發遍歷heap，針對可達對象先標記white為gray，然后再標記gray為black；遍歷完成之后所有可達對象都是balck的，所有white都是可以回收的。
SATB僅僅對于在marking開始階段進行“snapshot”(marked all reachable at mark start)，但是concurrent的時候并發修改可能造成對象漏標記。
對black新引用了一個white對象，然后又從gray對象中刪除了對該white對象的引用，這樣會造成了該white對象漏標記。
對black新引用了一個white對象，然后從gray對象刪了一個引用該white對象的white對象，這樣也會造成了該white對象漏標記。
對black新引用了一個剛new出來的white對象，沒有其他gray對象引用該white對象，這樣也會造成了該white對象漏標記。
SATB效率高于增量更新的原因？
因為SATB在重新標記環節只需要去重新掃描那些被推到堆棧中的引用，并配合Rset來判斷當前對象是否被引用來進行回收；
并且在最后G1并不會選擇回收所有垃圾對象，而是根據Region的垃圾多少來判斷與預估回收價值（指回收的垃圾與回收的STW時間的一個預估值），將一個或者多個Region放到CSet中，最后將這些Region中的存活對象壓縮并復制到新的Region中，清空原來的Region。
G1會不會進行Full GC?
會，當內存滿了的時候就會進行Full GC；且JDK10之前的Full GC，為單線程的，所以使用G1需要避免Full GC的產生。
解決方案：
加大內存；
提高CPU性能，加快GC回收速度，而對象增加速度趕不上回收速度，則Full GC可以避免；
降低進行Mixed GC觸發的閾值，讓Mixed GC提早發生（默認45%）
ClickHouse到底是什么？為什么如此牛逼！
原來ElasticSearch還可以這么理解
面試官：InnoDB中一棵B+樹可以存放多少行數據？
架構之道：分離業務邏輯和技術細節
星巴克不使用兩階段提交
面試官：Redis新版本開始引入多線程，談談你的看法？
喜馬拉雅自研網關架構演進過程
收藏：存儲知識全面總結
微博千萬級規模高性能高并發的網絡架構設計
總結
以上是生活随笔為你收集整理的你对JVM三色标记的理解嘛？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Kafka 3.0重磅发布，都更新了些啥
- 下一篇： 神器 JMH + Arthas 性能监控