目錄
判斷一個對象是否死亡？
1、引用計數(shù)法?
2、可達性分析算法
三色標記
垃圾收集算法
1、分代收集理論?
2、垃圾回收算法
標記-清除
標記-復(fù)制
標記-整理
CMS（Concurrent Mark Sweep）收集器
CMS垃圾收集器步驟
CMS垃圾收集器優(yōu)缺點
垃圾收集需要完成的三件事情：
- 哪些內(nèi)存需要回收？
- 什么時候回收？
- 如何回收？
判斷一個對象是否死亡？
1、引用計數(shù)法?
引用計數(shù)法：在對象中添加一個引用計數(shù)器，每當有一個地方引用它時，計數(shù)器值就加一；當引用失效時，計數(shù)器值就減一；任何時刻計數(shù)器為零的對象就是不可能再被使用的。
客觀地說，引用計數(shù)算法（Reference Counting）雖然占用了一些額外的內(nèi)存空間來進行計數(shù)，但
它的原理簡單，判定效率也很高，在大多數(shù)情況下它都是一個不錯的算法。但是，在Java領(lǐng)域，至少主流的Java虛擬機里面都沒有選用引用計數(shù)算法來管理內(nèi)存，主要原因是，這個看似簡單的算法有很多例外情況要考慮，必須要配合大量額外處理才能保證正確地工作，譬如單純的引用計數(shù)
就很難解決對象之間相互循環(huán)引用的問題。舉個例子，對象objA和objB都有字段instance，賦值令
objA.instance=objB及objB.instance=objA，除此之外，這兩個對象再無任何引用，實際上這兩個對象已經(jīng)不可能再被訪問，但是它們因為互相引用著對方，導致它們的引用計數(shù)都不為零，引用計數(shù)算法也就無法回收它們。
2、可達性分析算法
當前主流的商用程序語言的內(nèi)存管理子系統(tǒng)，都是通過可達性分析（Reachability Analysis）算法來判定對象是否存活的。這個算法的基本思路就是通過一系列稱為“GC Roots”的根對象作為起始節(jié)點集，從這些節(jié)點開始，根據(jù)引用關(guān)系向下搜索，搜索過程所走過的路徑稱為“引用鏈（Reference Chain），如果某個對象到GC Roots間沒有任何引用鏈相連，或者用圖論的話來說就是從GC Roots到這個對象不可達時，則證明此對象是不可能再被使用的。
如圖所示，對象object 5、object 6、object 7雖然互有關(guān)聯(lián)，但是它們到GC Roots是不可達的，因此它們將會被判定為可回收的對象。
三色標記
上面曾經(jīng)提到了當前主流編程語言的垃圾收集器基本上都是依靠可達性分析算法來判定對象是否存活的，可達性分析算法理論上要求全過程都基于一個能保障一致性的快照中才能夠進行分析，這意味著必須全程凍結(jié)用戶線程的運行。從GC Roots再繼續(xù)往下遍歷對象圖，這一步驟的停頓時間就必定會與Java堆容量直接成正比例關(guān)系了：堆越大，存儲的對象越多，對象圖結(jié)構(gòu)越復(fù)雜，要標記更多對象而產(chǎn)生的停頓時間自然就更長，這聽起來是理所當然的事情。要知道包含“標記”階段是所有追蹤式垃圾收集算法的共同特征，如果這個階段會隨著堆變大而等比例增加停頓時間，其影響就會波及幾乎所有的垃圾收集器，同理可知，如果能夠削減這部分停頓時間的話，那收益也將會是系統(tǒng)性的。
想解決或者降低用戶線程的停頓，就要先搞清楚為什么必須在一個能保障一致性的快照上才能進
行對象圖的遍歷？為了能解釋清楚這個問題，我們引入三色標記（Tri-color Marking）作為工具來輔助推導，把遍歷對象圖過程中遇到的對象，按照“是否訪問過”這個條件標記成以下三種顏色：
- 白色：表示對象尚未被垃圾收集器訪問過。顯然在可達性分析剛剛開始的階段，所有的對象都是白色的，若在分析結(jié)束的階段，仍然是白色的對象，即代表不可達。
- 黑色：表示對象已經(jīng)被垃圾收集器訪問過，且這個對象的所有引用都已經(jīng)掃描過。黑色的對象代表已經(jīng)掃描過，它是安全存活的，如果有其他對象引用指向了黑色對象，無須重新掃描一遍。黑色對象不可能直接（不經(jīng)過灰色對象）指向某個白色對象。
- 灰色：表示對象已經(jīng)被垃圾收集器訪問過，但這個對象上至少存在一個引用還沒有被掃描過。
關(guān)于可達性分析的掃描過程，把它看作對象圖上一股以灰色為波峰的波紋從黑向白推進的過程。如果用戶線程此時是凍結(jié)的，只有收集器線程在工作，那不會有任何問題。但如果用戶線程與收集器是并發(fā)工作呢？收集器在對象圖上標記顏色，同時用戶線程在修改引用關(guān)系——即修改對象圖的結(jié)構(gòu)，這樣可能出現(xiàn)兩種后果。一種是把原本消亡的對象錯誤標記為存活，這不是好事，但其實是可以容忍的，只不過產(chǎn)生了一點逃過本次收集的浮動垃圾而已，下次收集清理掉就好。另一種是把原本存活的對象錯誤標記為已消亡，這就是非常致命的后果了，程序肯定會因此發(fā)生錯誤
下面演示了這樣的致命錯誤具體是如何產(chǎn)生的
當且僅當以下兩個條件同時滿足時，會產(chǎn)生“對象消失”的問題，即原本應(yīng)該是黑色的對象被誤標為白色：
- 賦值器插入了一條或多條從黑色對象到白色對象的新引用；
- 賦值器刪除了全部從灰色對象到該白色對象的直接或間接引用。
因此，我們要解決并發(fā)掃描時的對象消失問題，只需破壞這兩個條件的任意一個即可。由此分別
產(chǎn)生了兩種解決方案：增量更新和原始快照
- 增量更新要破壞的是第一個條件，當黑色對象插入新的指向白色對象的引用關(guān)系時，就將這個新插入的引用記錄下來，等并發(fā)掃描結(jié)束之后，再將這些記錄過的引用關(guān)系中的黑色對象為根，重新掃描一次。這可以簡化理解為，黑色對象一旦新插入了指向白色對象的引用之后，它就變回灰色對象了。
- 原始快照要破壞的是第二個條件，當灰色對象要刪除指向白色對象的引用關(guān)系時，就將這個要刪除的引用記錄下來，在并發(fā)掃描結(jié)束之后，再將這些記錄過的引用關(guān)系中的灰色對象為根，重新掃描一次。這也可以簡化理解為，無論引用關(guān)系刪除與否，都會按照剛剛開始掃描那一刻的對象圖快照來進行搜索。
以上無論是對引用關(guān)系記錄的插入還是刪除，虛擬機的記錄操作都是通過寫屏障實現(xiàn)的。在
HotSpot虛擬機中，增量更新和原始快照這兩種解決方案都有實際應(yīng)用，譬如，CMS是基于增量更新來做并發(fā)標記的，G1、Shenandoah則是用原始快照來實現(xiàn)。
垃圾收集算法
1、分代收集理論?
當前商業(yè)虛擬機的垃圾收集器，大多數(shù)都遵循了“分代收集”（Generational Collection）的理論進
行設(shè)計，分代收集名為理論，實質(zhì)是一套符合大多數(shù)程序運行實際情況的經(jīng)驗法則，它建立在兩個分代假說之上：
- 1）弱分代假說（Weak Generational Hypothesis）：絕大多數(shù)對象都是朝生夕滅的。
- 2）強分代假說（Strong Generational Hypothesis）：熬過越多次垃圾收集過程的對象就越難以消亡
這兩個分代假說共同奠定了多款常用的垃圾收集器的一致的設(shè)計原則：收集器應(yīng)該將Java堆劃分出不同的區(qū)域，然后將回收對象依據(jù)其年齡（年齡即對象熬過垃圾收集過程的次數(shù)）分配到不同的區(qū)域之中存儲。顯而易見，如果一個區(qū)域中大多數(shù)對象都是朝生夕滅，難以熬過垃圾收集過程的話，那么把它們集中放在一起，每次回收時只關(guān)注如何保留少量存活而不是去標記那些大量將要被回收的對象，就能以較低代價回收到大量的空間；如果剩下的都是難以消亡的對象，那把它們集中放在一塊，虛擬機便可以使用較低的頻率來回收這個區(qū)域，這就同時兼顧了垃圾收集的時間開銷和內(nèi)存的空間有效利用。
設(shè)計者一般至少會把Java堆劃分為新生代（Young Generation）和老年代（Old Generation）兩個區(qū)域。顧名思義，在新生代中，每次垃圾收集時都發(fā)現(xiàn)有大批對象死去，而每次回收后存活的少量對象，將會逐步晉升到老年代中存放。
分代收集并非只是簡單劃分一下內(nèi)存區(qū)域那么容易，它至少存在一個明顯的困難：對象不是孤立的，對象之間會存在跨代引用。假如要現(xiàn)在進行一次只局限于新生代區(qū)域內(nèi)的收集（Minor GC），但新生代中的對象是完全有可能被老年代所引用的，為了找出該區(qū)域中的存活對象，不得不在固定的GC Roots之外，再額外遍歷整個老年代中所有對象來確?？蛇_性分析結(jié)果的正確性，反過來也是一樣。遍歷整個老年代所有對象的方案雖然理論上可行，但無疑會為內(nèi)存回收帶來很大的性能負擔。為了解決這個問題，就需要對分代收集理論添加第三條經(jīng)驗法則：
-
3 ）跨代引用假說（ Intergenerational Reference Hypothesis ）：跨代引用相對于同代引用來說僅占極少數(shù)。
這其實是可根據(jù)前兩條假說邏輯推理得出的隱含推論：存在互相引用關(guān)系的兩個對象，是應(yīng)該傾
向于同時生存或者同時消亡的。舉個例子，如果某個新生代對象存在跨代引用，由于老年代對象難以消亡，該引用會使得新生代對象在收集時同樣得以存活，進而在年齡增長之后晉升到老年代中，這時跨代引用也隨即被消除了。
依據(jù)這條假說，我們就不應(yīng)再為了少量的跨代引用去掃描整個老年代，也不必浪費空間專門記錄
每一個對象是否存在及存在哪些跨代引用，只需在新生代上建立一個全局的數(shù)據(jù)結(jié)構(gòu)（該結(jié)構(gòu)被稱
為“記憶集”，Remembered Set），這個結(jié)構(gòu)把老年代劃分成若干小塊，標識出老年代的哪一塊內(nèi)存會存在跨代引用。此后當發(fā)生Minor GC時，只有包含了跨代引用的小塊內(nèi)存里的對象才會被加入到GC Roots進行掃描。雖然這種方法需要在對象改變引用關(guān)系（如將自己或者某個屬性賦值）時維護記錄數(shù)據(jù)的正確性，會增加一些運行時的開銷，但比起收集時掃描整個老年代來說仍然是劃算的。
2、垃圾回收算法
標記-清除
- 標記所有需要清除的對象，統(tǒng)一回收；也可標記存活，清理未標記
- 效率不穩(wěn)定；內(nèi)存空間碎片化
算法分為“標記”和“清除”兩個階段：首先標記出所有需要回收的對象，在標記完成后，統(tǒng)一回收掉所有被標記的對象，也可以反過來，標記存活的對象，統(tǒng)一回收所有未被標記的對象。標記過程就是對象是否屬于垃圾的判定過程。
之所以說它是最基礎(chǔ)的收集算法，是因為后續(xù)的收集算法大多都是以標記-清除算法為基礎(chǔ)，對其
缺點進行改進而得到的。它的主要缺點有兩個：第一個是執(zhí)行效率不穩(wěn)定，如果Java堆中包含大量對象，而且其中大部分是需要被回收的，這時必須進行大量標記和清除的動作，導致標記和清除兩個過程的執(zhí)行效率都隨對象數(shù)量增長而降低；第二個是內(nèi)存空間的碎片化問題，標記、清除之后會產(chǎn)生大量不連續(xù)的內(nèi)存碎片，空間碎片太多可能會導致當以后在程序運行過程中需要分配較大對象時無法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集動作。
標記-復(fù)制
- 用一半，留一半，清理時復(fù)制存活到未用的一半，清空另一半
- 內(nèi)存規(guī)整，內(nèi)存利用率低，STW
標記-復(fù)制算法常被簡稱為復(fù)制算法。為了解決標記-清除算法面對大量可回收對象時執(zhí)行效率低的問題，1969年Fenichel提出了一種稱為“半?yún)^(qū)復(fù)制”（Semispace Copying）的垃圾收集算法，它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的內(nèi)存用完了，就將還存活著的對象復(fù)制到另外一塊上面，然后再把已使用過的內(nèi)存空間一次清理掉。如果內(nèi)存中多數(shù)對象都是存活的，這種算法將會產(chǎn)生大量的內(nèi)存間復(fù)制的開銷，但對于多數(shù)對象都是可回收的情況，算法需要復(fù)制的就是占少數(shù)的存活對象，而且每次都是針對整個半?yún)^(qū)進行內(nèi)存回收，分配內(nèi)存時也就不用考慮有空間碎片的復(fù)雜情況，只要移動堆頂指針，按順序分配即可。這樣實現(xiàn)簡單，運行高效，不過其缺陷也顯而易見，這種復(fù)制回收算法的代價是將可用內(nèi)存縮小為了原來的一半，空間浪費未免太多了一點。
用Java虛擬機大多都優(yōu)先采用了這種收集算法去回收新生代，把新生代分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次分配內(nèi)存只使用Eden和其中一塊Survivor。發(fā)生垃圾搜集時，將Eden和Survivor中仍然存活的對象一次性復(fù)制到另外一塊Survivor空間上，然后直接清理掉Eden和已用過的那塊Survivor空間。HotSpot虛擬機默認Eden和Survivor的大小比例是8:1:1。如果另外一塊Survivor空間沒有足夠空間存放上一次新生代收集下來的存活對象，這些對象便將通過分配擔保機制直接進入老年代
標記-整理
- 移動存貨到一邊，邊界線以外全部清除
- 內(nèi)存規(guī)整；需要移動對象，STW，對象越多STW時間越長
針對老年代對象的存亡特征，1974年Edward Lueders提出了另外一種有針對性的“標記-整理”（Mark-Compact）算法，其中的標記過程仍然與“標記-清除”算法一樣，但后續(xù)步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向內(nèi)存空間一端移動，然后直接清理掉邊界以外的內(nèi)
存。
標記-清除算法與標記-整理算法的本質(zhì)差異在于前者是一種非移動式的回收算法，而后者是移動
式的。是否移動回收后的存活對象是一項優(yōu)缺點并存的風險決策：如果移動存活對象，尤其是在老年代這種每次回收都有大量對象存活區(qū)域，移動存活對象并更新所有引用這些對象的地方將會是一種極為負重的操作，而且這種對象移動操作必須全程暫停用戶應(yīng)用程序才能進行，這就更加讓使用者不得不小心翼翼地權(quán)衡其弊端了，像這樣的停頓被最初的虛擬機設(shè)計者形象地描述為“Stop The World”。
但如果跟標記-清除算法那樣完全不考慮移動和整理存活對象的話，彌散于堆中的存活對象導致的
空間碎片化問題就只能依賴更為復(fù)雜的內(nèi)存分配器和內(nèi)存訪問器來解決。譬如通過“分區(qū)空閑分配鏈表”來解決內(nèi)存分配問題。內(nèi)存的訪問是用戶程序最頻繁的操作，甚至都沒有之一，假如在這個環(huán)節(jié)上增加了額外的負擔，勢必會直接影響應(yīng)用程序的吞吐量。
基于以上兩點，是否移動對象都存在弊端，移動則內(nèi)存回收時會更復(fù)雜，不移動則內(nèi)存分配時會
更復(fù)雜。從垃圾收集的停頓時間來看，不移動對象停頓時間會更短，甚至可以不需要停頓，但是從整個程序的吞吐量來看，移動對象會更劃算。即使不移動對象會使得收集器的效率提升一些，但因內(nèi)存分配和訪問相比垃圾收集頻率要高得多，這部分的耗時增加，總吞吐量仍然是下降的。HotSpot虛擬機里面關(guān)注吞吐量的Parallel Scavenge收集器是基于標記-整理算法的，而關(guān)注延遲的CMS收集器則是基于標記-清除算法的。
另外，還有一種“和稀泥式”解決方案可以不在內(nèi)存分配和訪問上增加太大額外負擔，做法是讓虛
擬機平時多數(shù)時間都采用標記-清除算法，暫時容忍內(nèi)存碎片的存在，直到內(nèi)存空間的碎片化程度已經(jīng)大到影響對象分配時，再采用標記-整理算法收集一次，以獲得規(guī)整的內(nèi)存空間。前面提到的基于標記-清除算法的CMS收集器面臨空間碎片過多時采用的就是這種處理辦法。
CMS（Concurrent Mark Sweep）收集器
CMS (Concurrent Mark Sweep)是一種以最短停頓時間為目標的收集器，使用CMS并不能達到GC效率最高（總體GC時間最小)，但它能盡可能降低GC時服務(wù)的停頓時間，CMS收集器使用的是標記-清除算法。
CMS垃圾收集器步驟
1)初始標記(CMS initial mark)?暫停所有的其他線程(STW)。記錄下 GC ROOT直接引用對象，速度很快。
2)并發(fā)標記(CMS concurrent mark)?并發(fā)標記階段就是從 GC ROOT行的直接關(guān)聯(lián)對象開始遍歷整個對象的過程，這個過程耗時比較長但是不需要停頓用戶線程，可以與垃圾收集器一起并發(fā)運行。因此用戶程序繼續(xù)運行,可能會導致已經(jīng)標記過的對象狀態(tài)發(fā)生變化。
3)重新標記(CMS remark)?重新標記階段就是為了修正并發(fā)標記期間，因為用戶程序繼續(xù)運行而導致標記產(chǎn)生變動的那一部分對象的標記記錄。這個階段的停頓時間一般比初始標記階段的時間稍長，遠遠比并發(fā)標記階段時間短。主要是用到三色標記里的增量更新算法
4）并發(fā)清除（CMS concurrent sweep)?開啟用戶線程，同時GC線程開始對未標記的區(qū)域做清掃，這個階段如果有新增對象會被標記為黑色不做任何處理。
5)并發(fā)重置?重置本次GC過程中標記數(shù)據(jù)。
CMS垃圾收集器優(yōu)缺點
從它的名字可以看出他是一款優(yōu)秀的垃圾收集器，主要優(yōu)點∶并發(fā)收集、低停頓。但是它有以下幾個明顯的缺點:
- 對于CPU資源敏感（會和服務(wù)搶資源);
- 無法處理浮動垃圾（在并發(fā)標記和并發(fā)清理階段又產(chǎn)生垃圾，這種浮動垃圾只能等到下次gc的時候在進行清理了)由于在垃圾收集階段用戶線程還需要持續(xù)運行，那就還需要預(yù)留足夠內(nèi)存空間提供給用戶線程使用，因此CMS收集器不能像其他收集器那樣等待到老年代幾乎完全被填滿了再進行收集，必須預(yù)留一部分空間供并發(fā)收集時的程序運作使用。在JDK5的默認設(shè)置下，CMS收集器當老年代使用了68%的空間后就會被激活，這是一個偏保守的設(shè)置,到了JDK 6時，CMS收集器的啟動閾值就已經(jīng)默認提升至92%。但這又會更容易面臨另一種風險：要是CMS運行期間預(yù)留的內(nèi)存無法滿足程序分配新對象的需要，就會出現(xiàn)一次“并發(fā)失敗”（Concurrent Mode Failure），這時候虛擬機將不得不啟動后備預(yù)案：凍結(jié)用戶線程的執(zhí)行，臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，但這樣停頓時間就很長了。所以參數(shù)-XX：CMSInitiatingOccupancyFraction設(shè)置得太高將會很容易導致大量的并發(fā)失敗產(chǎn)生，性能反而降低，用戶應(yīng)在生產(chǎn)環(huán)境中根據(jù)實際應(yīng)用情況來權(quán)衡設(shè)置。
- 它使用的收集算法“標記-清除”算法會導致結(jié)束時候又大量空間碎片產(chǎn)生，當然通過參數(shù)–XX:UseCMSCompactAtFullCollection可以讓JVM在執(zhí)行標記清除完成后再做整理?？臻g碎片過多時，將會給大對象分配帶來很大麻煩，往往會出現(xiàn)老年代還有很多剩余空間，但就是無法找到足夠大的連續(xù)空間來分配當前對象，而不得不提前觸發(fā)一次Full GC的情況。在CMS收集器不得不進行Full GC時開啟內(nèi)存碎片的合并整理過程，由于這個內(nèi)存整理必須移動存活對象，是無法并發(fā)的。這樣空間碎片問題是解決了，但停頓時間又會變長，因此虛擬機設(shè)計者們還提供了另外一個參數(shù)-XX：CMSFullGCsBefore-Compaction（此參數(shù)從JDK 9開始廢棄），這個參數(shù)的作用是要求CMS收集器在執(zhí)行過若干次（數(shù)量由參數(shù)值決定）不整理空間的Full GC之后，下一次進入Full GC前會先進行碎片整理（默認值為0，表示每次進入Full GC時都進行碎片整理）。
?文章來源地址http://www.zghlxwxcb.cn/news/detail-687700.html
?文章來源：http://www.zghlxwxcb.cn/news/detail-687700.html
?
?
到了這里，關(guān)于JVM垃圾回收算法和CMS垃圾收集器的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
