大家好，我是 BookSea。

作為一名Java程序員，我們每天都在程序里不停地去new對象，但是你知道這些被new出來的對象，最后是怎么被回收的嗎？

在堆里面存放著Java世界中幾乎所有的對象實(shí)例，垃圾收集器在對堆進(jìn)行回收前，第一件事情就是要確定這些對象之中哪些還「存活」著，哪些已經(jīng)「死去」（“死去”即不可能再被任何途徑使用的對象）。

JVM必然是有自己的一套方法來判斷哪些對象該回收，哪些不該回收。

本篇文章就來聊聊這個話題。

一、引用計數(shù)算法

這種算法的工作原理是這樣的：在對象中添加一個引用計數(shù)器，每當(dāng)有一個地方引用它時，計數(shù)器值就加一；當(dāng)引用失效時，計數(shù)器值就減一；任何時刻計數(shù)器為零的對象就是不可能再被使用的。

客觀的說，引用計數(shù)算法雖然占用了一些額外的內(nèi)存空間來計數(shù)，但原理簡單，效率也很高。

但是目前主流的Java虛擬機(jī)里面都沒有選用引用計數(shù)法來進(jìn)行內(nèi)存管理，why？

主要原因是，引用計數(shù)算法很難解決對象之間相互「循環(huán)引用」的問題。下面放段代碼，舉個例子：

public class MyObject {
    public Object ref = null;
    public static void main(String[] args) {
        MyObject myObject1 = new MyObject();
        MyObject myObject2 = new MyObject();
        myObject1.ref = myObject2;
        myObject2.ref = myObject1;
        myObject1 = null;
        myObject2 = null;
    }
}

這段代碼里定義了一個類MyObject，只有一個成員變量ref。

當(dāng)設(shè)置myObject1 = null和myObject2 = null后，僅僅是清除了myObject1和myObject2變量所持有的引用。并沒有影響到myObject1對象內(nèi)部的ref字段和myObject2對象內(nèi)部的ref字段，它們?nèi)匀辉谙嗷ヒ谩?/p>

我們可以看出myObject1和myObject2這兩個對象除互相引用外再無任何引用，實(shí)際上這兩個對象已經(jīng)不可能再被訪問，但是它們因?yàn)榛ハ嘁弥鴮Ψ剑瑢?dǎo)致它們的引用計數(shù)都不為零，引用計數(shù)算法也就無法回收它們，這就是循環(huán)引用問題。

有點(diǎn)類似死鎖的概念，A和B互相持有，誰也不釋放，直接卡住。

通過這個例子我們可以看出引用計數(shù)法是存在弊端的。

所以HotSpot虛擬機(jī)并不是通過引用計數(shù)算法來判斷對象是否存活的，使用的是「可達(dá)性分析算法」。

二、可達(dá)性分析算法

JVM通過可達(dá)性分析（Reachability Analysis）算法來判定對象是否存活的。

這個算法的基本思路就是通過一系列稱為GC Roots的根對象作為起始節(jié)點(diǎn)集，從這些節(jié)點(diǎn)開始，根據(jù)引用關(guān)系向下搜索。

搜索過程所走過的路徑稱為引用鏈（Reference Chain），如果某個對象到GC Roots間沒有任何引用鏈相連，或者用圖論的話來說就是從GC Roots到這個對象不可達(dá)時，則證明此對象是不可能再被使用的。

如圖，對象object 5、object 6、object 7到GC Roots是不可達(dá)的，因此它們將會被判定為可回收的對象。

上文提到的GC Roots，我們可以認(rèn)為是起點(diǎn)，而在JVM里面，固定可以作為GC Roots的對象包括以下幾種：

• 在虛擬機(jī)棧（棧中 的本地變量表）中引用的對象，例如各個線程被調(diào)用的方法堆棧中使用到的參數(shù)、局部變量、臨時變量等。
• 在方法區(qū)中常量引用的對象，例如字符串常量池（String Table）里的引用。
• 在本地方法棧中JNI（本地方法）引用的對象。
• Java虛擬機(jī)內(nèi)部的引用，如基本數(shù)據(jù)類型對應(yīng)的Class對象，一些常駐的異常對象（NullPointException、OutOfMemoryError）等，以及系統(tǒng)類加載器。
• 所有被同步鎖（synchronized）持有的對象。
• 反映Java虛擬機(jī)內(nèi)部情況的JMXBean、JVMTI中注冊的回調(diào)、本地代碼緩存等。

通過枚舉一個一個根節(jié)點(diǎn)(GC Roots)，然后順藤摸瓜一路摸下來，然后沒摸到的那些對象，也就是不存在引用的對象就把它咔嚓回收了。這個過程稱之為「根節(jié)點(diǎn)枚舉」。

目前所有的垃圾收集器在根節(jié)點(diǎn)枚舉這一步驟時都是必須暫停用戶線程的，也就是必須會有STW（Stop the Wrold）。

這里面細(xì)講東西很多，先埋個坑，后續(xù)會有文章專門來講根節(jié)點(diǎn)枚舉。

上面我們講了可達(dá)性分析算法是根據(jù)引用來回收的，而對不同的引用類型有不同的處理方式，JVM也是會去「差別對待的」。

三、引用類型

Java將引用分為強(qiáng)引用（Strongly Re-ference）、軟引用（Soft Reference）、弱引用（Weak Reference）和虛引用（Phantom Reference）4種，這4種引用強(qiáng)度依次逐漸減弱：

• 強(qiáng)引用是最傳統(tǒng)的“引用”的定義，在程序代碼之中普遍存在，即類似Object obj=new Object()這種引用關(guān)系。如果一個對象具有強(qiáng)引用，那就類似于"必不可少的生活用品"。只要強(qiáng)引用還存在，垃圾收集器永遠(yuǎn)不會回收掉被引用的對象。
• 軟引用是用來描述一些還有用，但非必須的對象。只被軟引用關(guān)聯(lián)著的對象，在系統(tǒng)將要發(fā)生內(nèi)存溢出異常前，會把這些對象列進(jìn)回收范圍之中進(jìn)行第二次回收，如果這次回收還沒有足夠的內(nèi)存，才會拋出內(nèi)存溢出異常。在JDK 1.2版之后提供了SoftReference類來實(shí)現(xiàn)軟引用。
• 弱引用也是用來描述那些非必須對象，但是它的強(qiáng)度比軟引用更弱一些，被弱引用關(guān)聯(lián)的對象只能生存到下一次垃圾收集發(fā)生為止。當(dāng)垃圾收集器開始工作，無論當(dāng)前內(nèi)存是否足夠，都會回收掉只被弱引用關(guān)聯(lián)的對象。在JDK 1.2版之后提供了WeakReference類來實(shí)現(xiàn)弱引用。
• 虛引用是最弱的一種引用關(guān)系。如果一個對象僅持有虛引用，那么它就和沒有任何引用一樣，隨時都可能被垃圾回收器回收，無法通過虛引用來取得一個對象實(shí)例。虛引用主要用來跟蹤對象被垃圾回收器回收的活動，比如確保某個資源被finalize后，做一些后續(xù)的清理工作。在JDK 1.2版之后提供了PhantomReference類來實(shí)現(xiàn)虛引用。

上面巴拉巴拉說了一堆話，我知道你們肯定不愛看，也記不住。所以鐵子，我總結(jié)成一句話，你聽這句話就夠了。

總結(jié)一句話就是：強(qiáng)引用內(nèi)存不足也不會回收，軟引用內(nèi)存不足才回收，弱引用和虛引用看見就回收。

看到這里有個疑問，在可達(dá)性分析算法中判定為不可達(dá)的對象，就一定「非死不可」嗎？

四、Dead Or Alive

當(dāng)一個對象被判斷為不可達(dá)的時候，這時候該對象處在「緩刑」階段。

意思就是說刀已經(jīng)架你脖子上了，但是還沒落下來，還是有商量的余地的。

要真正宣告一個對象死亡，至少要經(jīng)歷兩次標(biāo)記過程：

如果對象在進(jìn)行可達(dá)性分析后發(fā)現(xiàn)沒有與GC Roots相連接的引用鏈，那它將會被第一次標(biāo)記，隨后進(jìn)行一次篩選，篩選的條件是此對象是否有必要執(zhí)行finalize()方法。

假如對象沒有覆蓋finalize()方法，或者finalize()方法已經(jīng)被虛擬機(jī)調(diào)用過，那么虛擬機(jī)將這兩種情況都視為“沒有必要執(zhí)行”。

如果這個對象被判定為確有必要執(zhí)行finalize()方法，那么該對象將會被放置在一個名為F-Queue的隊列之中，并在稍后由一條由虛擬機(jī)自動建立的、低調(diào)度優(yōu)先級的Finalizer線程去執(zhí)行它們的finalize()方法。

這里所說的“執(zhí)行”是指虛擬機(jī)會觸發(fā)這個方法開始運(yùn)行，但并不承諾一定會等待它運(yùn)行結(jié)束。

這樣做的原因是，如果某個對象finalize()方法執(zhí)行緩慢，或者更極端地發(fā)生了死循環(huán)，將很可能導(dǎo)致F-Queue隊列中的其他對象永久處于等待，卡死在這里。甚至導(dǎo)致整個內(nèi)存回收子系統(tǒng)的崩潰。

finalize()方法是對象逃脫死亡命運(yùn)的最后一次機(jī)會，救命的最后一根稻草，稍后收集器將對F-Queue中的對象進(jìn)行第二次小規(guī)模的標(biāo)記。

如果對象要在finalize()中成功拯救自己——只要重新與引用鏈上的任何一個對象建立關(guān)聯(lián)即可，譬如把自己（this關(guān)鍵字）賦值給某個類變量或者對象的成員變量，那在第二次標(biāo)記時它將被移出「即將回收」的集合。

如果對象這時候還沒有逃脫，那基本上它就真的要被回收了，就真要說byebye了。

需要注意的是：任何一個對象的finalize()方法都只會被系統(tǒng)自動調(diào)用一次，如果對象面臨下一次回收，它的finalize()方法不會被再次執(zhí)行，不能指望我每次都救你，我只能救你一次，剩下的就靠你自己了。

看起來對象能夠使用finalize()方法實(shí)現(xiàn)自我救贖，然而這個方法并沒有什么用，放一段《深入理解Java虛擬機(jī)》里的原話：

總結(jié)一下，就是finalize()這個方法并沒什么卵用，大家還是把他忘了好。

對象的回收行為主要發(fā)生在新生代和老年代，那么有兄弟可能會問了，永久代有垃圾回收行為嗎?

五、永久代真的"永久"嗎？

注意一下，這里說的永久代，主要還是針對于Java 8以前，在Java 8以及之后的版本中，永久代被元數(shù)據(jù)區(qū)（Metaspace）取代。

永久代和方法區(qū)和元空間的關(guān)系可能有點(diǎn)混亂，稍微提一嘴：方法區(qū)是由Java虛擬機(jī)規(guī)范定義的一個邏輯區(qū)域，是個邏輯上的概念，而永久代和元空間則是HotSpot對方法區(qū)的兩種不同實(shí)現(xiàn)。

一圖勝千言，直接上圖。

有些人認(rèn)為方法區(qū)（如HotSpot虛擬機(jī)中的元空間或者永久代）是沒有垃圾收集行為的，但其實(shí)方法區(qū)是可以被回收的，只不過回收的判定條件過于苛刻，垃圾收集的成果很差。

并不是名字叫永久代就真的「永久」了，出來混，欠的債總要還的。

我們先搞清楚方法區(qū)要回收的是什么，方法區(qū)的垃圾收集主要回收兩部分內(nèi)容：「廢棄的常量」和「不再使用的類型」。

判定一個常量是否“廢棄”還是相對簡單，看這個常量有沒有在用就行了，而要判定一個類型是否屬于「不再被使用的類」的條件就比較苛刻了。需要同時滿足下面三個條件（注意是同時！）：

• 該類所有的實(shí)例都已經(jīng)被回收，也就是Java堆中不存在該類及其任何派生子類的實(shí)例。
• 加載該類的類加載器已經(jīng)被回收，這個條件除非是經(jīng)過精心設(shè)計的可替換類加載器的場景，如OSGi、JSP的重加載等，否則通常是很難達(dá)成的。
• 該類對應(yīng)的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

Java虛擬機(jī)被允許對滿足上述三個條件的無用類進(jìn)行回收，這里說的僅僅是“被允許”，而并不是和對象一樣，沒有引用了就必然會回收。

關(guān)于是否要對類型進(jìn)行回收，HotSpot虛擬機(jī)提供了-Xnoclassgc參數(shù)進(jìn)行控制。

對于Oracle的HotSpot JVM，這個參數(shù)默認(rèn)是不開啟的，意味著默認(rèn)情況下，類元數(shù)據(jù)可以被垃圾收集器回收。如果你明確使用了 -Xnoclassgc 參數(shù)來啟動JVM，那么就會禁止類的垃圾回收。

也就是說如果沒有開啟這項(xiàng)參數(shù)支持類型的卸載，哪怕滿足了所有條件，也不會進(jìn)行類型的卸載。

上面我們講了對象回收的條件，知道了回收的條件之后，我們再講講怎么被回收，也就是垃圾回收算法。

這塊可是面試重點(diǎn)，面試問到JVM這塊少不了要被教育一番，大家好好聽，下次可以跟面試官對波線。

六、垃圾收集算法

垃圾收集（Garbage Collection，GC）算法是Java虛擬機(jī)（JVM）用來自動管理內(nèi)存的一種方式。主要的目標(biāo)是找出那些已經(jīng)不再使用的對象，并釋放它們所占用的內(nèi)存空間。

通俗來說就是發(fā)現(xiàn)垃圾之后怎么收垃圾，是打包帶走，還是來個垃圾分類。

1.標(biāo)記-清除算法

標(biāo)記-清除算法是最早出現(xiàn)也是最基礎(chǔ)的垃圾收集算法。

它分為「標(biāo)記」和「清除」兩個階段：首先標(biāo)記出所有需要回收的對象，在標(biāo)記完成后，統(tǒng)一回收掉所有被標(biāo)記的對象，也可以反過來，標(biāo)記存活的對象，統(tǒng)一回收所有未被標(biāo)記的對象。

下圖為使用“標(biāo)記-清除”算法回收前后的狀態(tài)：

優(yōu)點(diǎn)：不需要進(jìn)行對象的移動，在存活對象比較多的情況下非常高效。

缺點(diǎn)：標(biāo)記-清除算法主要缺點(diǎn)有兩個：

• 第一個是執(zhí)行效率不穩(wěn)定，如果Java堆中包含大量對象，而且其中大部分是需要被回收的，這時必須進(jìn)行大量標(biāo)記和清除的動作。
• 第二個是內(nèi)存空間的碎片化問題，標(biāo)記、清除之后會產(chǎn)生大量不連續(xù)的「內(nèi)存碎片」，而內(nèi)存碎片是無法被分配對象的，內(nèi)存碎片太多可能會導(dǎo)致當(dāng)以后在程序運(yùn)行過程中需要分配較大對象時無法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集動作。

第一個問題其實(shí)還好，但是第二個內(nèi)存碎片是個大問題，無法容忍。試想一下就跟你打游戲，玩著越來越卡，玩一秒卡二秒，這還怎么玩？

所以后續(xù)的收集算法大多都是以標(biāo)記-清除算法為基礎(chǔ)，改進(jìn)了內(nèi)存碎片的問題，對其缺點(diǎn)進(jìn)行改進(jìn)而得到的。

2.標(biāo)記-復(fù)制算法

為了解決標(biāo)記-清除算法面對大量可回收對象時執(zhí)行效率低的問題，1969年Fenichel提出了一種稱為「半?yún)^(qū)復(fù)制（Semispace Copying）」的垃圾收集算法。

它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當(dāng)這一塊的內(nèi)存用完了，就將還存活著的對象復(fù)制到另外一塊上面，然后再把已使用過的內(nèi)存空間一次清理掉。

如果內(nèi)存中多數(shù)對象都是存活的，這種算法將會產(chǎn)生大量的內(nèi)存間復(fù)制的開銷，但對于多數(shù)對象都是可回收的情況，算法需要復(fù)制的就是占少數(shù)的存活對象，而且每次都是針對整個半?yún)^(qū)進(jìn)行內(nèi)存回收，分配內(nèi)存時也就不用考慮有空間碎片的復(fù)雜情況。

所以，標(biāo)記-復(fù)制算法通常用在新生代的Eden區(qū)和Survivor區(qū)，這兩個區(qū)的對象，朝生夕死，多數(shù)對象都是可回收的。

總結(jié)一下，標(biāo)記-復(fù)制算法有如下優(yōu)點(diǎn)和缺點(diǎn)：

• 優(yōu)點(diǎn)：實(shí)現(xiàn)簡單，內(nèi)存回收時不用考慮內(nèi)存碎片的出現(xiàn)。
• 缺點(diǎn)：代價是將可用內(nèi)存縮小為了原來的一半，并且在對象存活率較高時就要進(jìn)行較多的復(fù)制操作，效率將會降低。

下圖為使用復(fù)制算法回收前后的狀態(tài)：

標(biāo)記-復(fù)制看著還行，但是比較大的缺點(diǎn)是浪費(fèi)了50%的空間，要知道內(nèi)存是很貴的啊。

3.標(biāo)記-整理算法

標(biāo)記-復(fù)制算法在對象存活率較高時就要進(jìn)行較多的復(fù)制操作，效率將會降低。

更關(guān)鍵的是，如果不想浪費(fèi)50%的空間，就需要有額外的空間進(jìn)行分配擔(dān)保，以應(yīng)對被使用的內(nèi)存中所有對象都100%存活的極端情況。

所以在老年代一般不能直接選用這種算法。針對老年代對象的存亡特征，1974年Edward Lueders提出了另外一種有針對性的標(biāo)記-整理（Mark-Compact）算法。

其中的標(biāo)記過程仍然與“標(biāo)記-清除”算法一樣，但后續(xù)步驟不是直接對可回收對象進(jìn)行清理，而是讓所有存活的對象都向內(nèi)存空間一端移動，然后直接清理掉邊界以外的內(nèi)存。

• 優(yōu)點(diǎn)：經(jīng)過整理之后，新對象的分配只需要通過指針碰撞便能完成，也解決了內(nèi)存碎片的問題。
• 缺點(diǎn)：GC 暫停的時間會增長，對象移動的時間成本是十分可觀的。

下圖為使用“標(biāo)記-整理”算法回收前后的狀態(tài)：

4.標(biāo)記-清除 VS 標(biāo)記-整理

標(biāo)記-清除算法與標(biāo)記-整理算法的本質(zhì)差異在于前者是一種「非移動式」的回收算法，而后者是「移動式」的。

別小看這一差異，是否移動回收后的存活對象是一項(xiàng)優(yōu)缺點(diǎn)并存的風(fēng)險決策。

如果移動存活對象，尤其是在老年代這種每次回收都有大量對象存活區(qū)域，移動存活對象會是一種極為負(fù)重的操作，而且這種對象移動操作必須全程暫停用戶應(yīng)用程序才能進(jìn)行。

但如果跟標(biāo)記-清除算法那樣完全不考慮移動和整理存活對象的話，彌散于堆中的存活對象導(dǎo)致的內(nèi)存碎片問題就只能依賴更為復(fù)雜的內(nèi)存分配器和內(nèi)存訪問器來解決。

譬如通過「分區(qū)空閑分配鏈表」來解決內(nèi)存分配問題。

內(nèi)存的訪問是用戶程序最頻繁的操作，甚至都沒有之一，假如在這個環(huán)節(jié)上增加了額外的負(fù)擔(dān)，勢必會直接影響應(yīng)用程序的吞吐量。

基于以上兩點(diǎn)，是否移動對象都存在弊端，移動則內(nèi)存回收時會更復(fù)雜，不移動則內(nèi)存分配時會更復(fù)雜。從垃圾收集的停頓時間來看，不移動對象停頓時間會更短，但是從整個程序的吞吐量來看，移動對象會更劃算。

HotSpot虛擬機(jī)里面關(guān)注吞吐量的Parallel Scavenge收集器是基于標(biāo)記-整理算法的，而關(guān)注延遲的CMS收集器則是基于標(biāo)記-清除算法的，這也從側(cè)面印證這點(diǎn)。

另外，還有一種「和稀泥式」解決方案可以不在內(nèi)存分配和訪問上增加太大額外負(fù)擔(dān)，做法是讓虛擬機(jī)平時多數(shù)時間都采用標(biāo)記-清除算法，暫時容忍內(nèi)存碎片的存在，直到內(nèi)存空間的碎片化程度已經(jīng)大到影響對象分配時，再采用標(biāo)記-整理算法收集一次，以獲得規(guī)整的內(nèi)存空間。

基于標(biāo)記-清除算法的CMS收集器采用的就是這種處理辦法。

當(dāng)CMS出現(xiàn)「并發(fā)失敗”（Concurrent Mode Failure）」時，這時會啟用Serial Old收集器來重新進(jìn)行老年代的垃圾收集，而Serial Old正是基于標(biāo)記-整理算法。

好了，本篇文章到這就結(jié)束了，這篇文章主要是講JVM是怎么回收對象的，明白了這個，JVM算是初窺門徑了。