GC策略解決了哪些問題？

既然是要進行自動GC，那必然會有相應的策略，而這些策略解決了哪些問題呢，粗略的來說，主要有以下幾點。

1、哪些物件可以被回收。

2、何時回收這些物件。

3、採用什麼樣的方式回收。

GC策略採用的何種演算法

    有關上面所提到的三個問題，其實最主要的一個問題就是第一個，也就是哪些物件才是可以回收的,有一種比較簡單直觀的辦法，它的效率較高，被稱作引用計數演算法，其原理是：此物件有一個引用，則+1；刪除一個引用，則-1。只用收集計數為0的物件。缺點是： （1）無法處理迴圈引用的問題。如：物件A和B分別有欄位b、a，令A.b=B和B.a=A，除此之外這2個物件再無任何引用，那實際上這2個物件已經不可能再被訪問，但是引用計數演算法卻無法回收他們。（2）引用計數的方法需要編譯器的配合，編譯器需要為此物件生成額外的程式碼。如賦值函式將此物件賦值給一個引用時，需要增加此物件的引用計數。還有就是，當一個引用變數的生命週期結束時，需要更新此物件的引用計數器。引用計數的方法由於存在顯著的缺點，實際上並未被JVM所使用。想象一下，假設JVM採用這種GC策略，那麼程式猿在編寫的程式的時候，下面這樣的程式碼就不要指望再出現了。

 1 public class Object {
 2     
 3     Object field = null;
 4         
 5     public static void main(String[] args) {
 6         Thread thread = new Thread(new Runnable() {
 7             public void run() {
 8                 Object objectA = new Object();
 9                 Object objectB = new Object();//1
10                 objectA.field = objectB;
11                 objectB.field = objectA;//2
12                 //to do something
13                 objectA = null;
14                 objectB = null;//3
15             }
16         });
17         thread.start();
18         while (true);
19     }
20         
21 }

      這段程式碼看起來有點刻意為之，但其實在實際程式設計過程當中，是經常出現的，比如兩個一對一關係的資料庫物件，各自保持著對方的引用,最後一個無限迴圈只是為了保持JVM不退出，沒什麼實際意義。

      對於我們現在使用的GC來說，當thread執行緒執行結束後，會將objectA和objectB全部作為待回收的物件,而如果我們的GC採用上面所說的引用計數演算法，則這兩個物件永遠不會被回收，即便我們在使用後顯示的將物件歸為空值也毫無作用。

      這裡LZ大致解釋一下，在程式碼中LZ標註了1、2、3三個數字，當第1個地方的語句執行完以後，兩個物件的引用計數全部為1。當第2個地方的語句執行完以後，兩個物件的引用計數就全部變成了2。當第3個地方的語句執行完以後，也就是將二者全部歸為空值以後，二者的引用計數仍然為1。根據引用計數演算法的回收規則，引用計數沒有歸0的時候是不會被回收的。

根搜尋演算法

    由於引用計數演算法的缺陷，所以JVM一般會採用一種新的演算法，叫做根搜尋演算法。它的處理方式就是，設立若干種根物件，當任何一個根物件到某一個物件均不可達時，則認為這個物件是可以被回收的。

    就拿上圖來說，ObjectD和ObjectE是互相關聯的，但是由於GC roots到這兩個物件不可達，所以最終D和E還是會被當做GC的物件，上圖若是採用引用計數法，則A-E五個物件都不會被回收，說到GC roots（GC根），在JAVA語言中，可以當做GC roots的物件有以下幾種：

1、虛擬機器棧中的引用的物件。

2、方法區中的類靜態屬性引用的物件。

3、方法區中的常量引用的物件。

4、本地方法棧中JNI的引用的物件。

第一和第四種都是指的方法的本地變量表，第二種表達的意思比較清晰，第三種主要指的是宣告為final的常量值。

    根搜尋演算法解決的是垃圾蒐集的基本問題，也就是上面提到的第一個問題，也是最關鍵的問題，就是哪些物件可以被回收，不過垃圾收集顯然還需要解決後兩個問題，什麼時候回收以及如何回收，在根搜尋演算法的基礎上，現代虛擬機器的實現當中，垃圾蒐集的演算法主要有三種，分別是標記-清除演算法、複製演算法、標記-整理演算法，這三種演算法都擴充了根搜尋演算法，不過它們理解起來還是非常好理解的。

    首先，我們回想一下上一章提到的根搜尋演算法，它可以解決我們應該回收哪些物件的問題，但是它顯然還不能承擔垃圾蒐集的重任，因為我們在程式（程式也就是指我們執行在JVM上的JAVA程式）執行期間如果想進行垃圾回收，就必須讓GC執行緒與程式當中的執行緒互相配合，才能在不影響程式執行的前提下，順利的將垃圾進行回收。

    為了達到這個目的，標記/清除演算法就應運而生了，它的做法是當堆中的有效記憶體空間（available memory）被耗盡的時候，就會停止整個程式（也被成為stop the world），然後進行兩項工作，第一項則是標記，第二項則是清除。

（1）標記：標記的過程其實就是，遍歷所有的GC Roots，然後將所有GC Roots可達的物件標記為存活的物件。

（2）清除：清除的過程將遍歷堆中所有的物件，將沒有標記的物件全部清除掉。

    其實這兩個步驟並不是特別複雜，也很容易理解。LZ用通俗的話解釋一下標記/清除演算法，就是當程式執行期間，若可以使用的記憶體被耗盡的時候，GC執行緒就會被觸發並將程式暫停，隨後將依舊存活的物件標記一遍，最終再將堆中所有沒被標記的物件全部清除掉，接下來便讓程式恢復執行。

下面LZ給各位製作了一組描述上面過程的圖片，結合著圖片，我們來直觀的看下這一過程，首先是第一張圖。

    這張圖代表的是程式執行期間所有物件的狀態，它們的標誌位全部是0（也就是未標記，以下預設0就是未標記，1為已標記），假設這會兒有效記憶體空間耗盡了，JVM將會停止應用程式的執行並開啟GC執行緒，然後開始進行標記工作，按照根搜尋演算法，標記完以後，物件的狀態如下圖。

    可以看到，按照根搜尋演算法，所有從root物件可達的物件就被標記為了存活的物件，此時已經完成了第一階段標記。接下來，就要執行第二階段清除了，那麼清除完以後，剩下的物件以及物件的狀態如下圖所示。

    可以看到，沒有被標記的物件將會回收清除掉，而被標記的物件將會留下，並且會將標記位重新歸0。接下來就不用說了，喚醒停止的程式執行緒，讓程式繼續執行即可，其實這一過程並不複雜，甚至可以說非常簡單，各位說對嗎。不過其中有一點值得LZ一提，就是為什麼非要停止程式的執行呢？這個其實也不難理解，LZ舉個最簡單的例子，假設我們的程式與GC執行緒是一起執行的，各位試想這樣一種場景。

    假設我們剛標記完圖中最右邊的那個物件，暫且記為A，結果此時在程式當中又new了一個新物件B，且A物件可以到達B物件，但是由於此時A物件已經標記結束，B物件此時的標記位依然是0，因為它錯過了標記階段，因此當接下來輪到清除階段的時候，新物件B將會被苦逼的清除掉。如此一來，不難想象結果，GC執行緒將會導致程式無法正常工作。上面的結果當然令人無法接受，我們剛new了一個物件，結果經過一次GC，忽然變成null了，這還怎麼玩？

標記/清除演算法缺點

1、首先，它的缺點就是效率比較低（遞迴與全堆物件遍歷），而且在進行GC的時候，需要停止應用程式，這會導致使用者體驗非常差勁，尤其對於互動式的應用程式來說簡直是無法接受。試想一下，如果你玩一個網站，這個網站一個小時就掛五分鐘，你還玩嗎？

2、第二點主要的缺點，則是這種方式清理出來的空閒記憶體是不連續的，這點不難理解，我們的死亡物件都是隨即的出現在記憶體的各個角落的，現在把它們清除之後，記憶體的佈局自然會亂七八糟。而為了應付這一點，JVM就不得不維持一個記憶體的空閒列表，這又是一種開銷。而且在分配陣列物件的時候，尋找連續的記憶體空間會不太好找。

複製演算法

    我們首先一起來看一下複製演算法的做法，複製演算法將記憶體劃分為兩個區間，在任意時間點，所有動態分配的物件都只能分配在其中一個區間（稱為活動區間），而另外一個區間（稱為空閒區間）則是空閒的，當有效記憶體空間耗盡時，JVM將暫停程式執行，開啟複製演算法GC執行緒。接下來GC執行緒會將活動區間內的存活物件，全部複製到空閒區間，且嚴格按照記憶體地址依次排列，與此同時，GC執行緒將更新存活物件的記憶體引用地址指向新的記憶體地址。此時，空閒區間已經與活動區間交換，而垃圾物件現在已經全部留在了原來的活動區間，也就是現在的空閒區間。事實上，在活動區間轉換為空間區間的同時，垃圾物件已經被一次性全部回收，LZ給各位繪製一幅圖來說明問題，如下所示。

    其實這個圖依然是上一章的例子，只不過此時記憶體被複制演算法分成了兩部分，下面我們看下當複製演算法的GC執行緒處理之後，兩個區域會變成什麼樣子，如下所示。

    可以看到，1和4號物件被清除了，而2、3、5、6號物件則是規則的排列在剛才的空閒區間，也就是現在的活動區間之內。此時左半部分已經變成了空閒區間，不難想象，在下一次GC之後，左邊將會再次變成活動區間。很明顯，複製演算法彌補了標記/清除演算法中，記憶體佈局混亂的缺點。不過與此同時，它的缺點也是相當明顯的。

1、它浪費了一半的記憶體，這太要命了。

2、如果物件的存活率很高，我們可以極端一點，假設是100%存活，那麼我們需要將所有物件都複製一遍，並將所有引用地址重置一遍。複製這一工作所花費的時間，在物件存活率達到一定程度時，將會變的不可忽視。

所以從以上描述不難看出，複製演算法要想使用，最起碼物件的存活率要非常低才行，而且最重要的是，我們必須要克服50%記憶體的浪費。

標記/整理演算法

標記/整理演算法與標記/清除演算法非常相似，它也是分為兩個階段：標記和整理。

（1）標記：它的第一個階段與標記/清除演算法是一模一樣的，均是遍歷GC Roots，然後將存活的物件標記。

（2）整理：移動所有存活的物件，且按照記憶體地址次序依次排列，然後將末端記憶體地址以後的記憶體全部回收。因此，第二階段才稱為整理階段。

它GC前後的圖示與複製演算法的圖非常相似，只不過沒有了活動區間和空閒區間的區別，而過程又與標記/清除演算法非常相似，我們來看GC前記憶體中物件的狀態與佈局，如下圖所示。

    這張圖其實與標記/清楚演算法一模一樣，只是LZ為了方便表示記憶體規則的連續排列，加了一個矩形表示記憶體區域。倘若此時GC執行緒開始工作，那麼緊接著開始的就是標記階段了。此階段與標記/清除演算法的標記階段是一樣一樣的，我們看標記階段過後物件的狀態，如下圖。

沒什麼可解釋的，接下來，便應該是整理階段了，我們來看當整理階段處理完以後，記憶體的佈局是如何的，如下圖。

    可以看到，標記的存活物件將會被整理，按照記憶體地址依次排列，而未被標記的記憶體會被清理掉。如此一來，當我們需要給新物件分配記憶體時，JVM只需要持有一個記憶體的起始地址即可，這比維護一個空閒列表顯然少了許多開銷，不難看出，標記/整理演算法不僅可以彌補標記/清除演算法當中，記憶體區域分散的缺點，也消除了複製演算法當中，記憶體減半的高額代價，標記/整理演算法唯一的缺點就是效率也不高，不僅要標記所有存活物件，還要整理所有存活物件的引用地址。從效率上來說，標記/整理演算法要低於複製演算法。這裡LZ給各位總結一下三個演算法的共同點以及它們各自的優勢劣勢，讓各位對比一下，想必會更加清晰，它們的共同點主要有以下兩點。

1、三個演算法都基於根搜尋演算法去判斷一個物件是否應該被回收，而支撐根搜尋演算法可以正常工作的理論依據，就是語法中變數作用域的相關內容。因此，要想防止記憶體洩露，最根本的辦法就是掌握好變數作用域，而不應該使用前面記憶體管理雜談一章中所提到的C/C++式記憶體管理方式。

2、在GC執行緒開啟時，或者說GC過程開始時，它們都要暫停應用程式（stop the world）。

它們的區別LZ按照下面幾點來給各位展示。（>表示前者要優於後者，=表示兩者效果一樣）

效率：複製演算法>標記/整理演算法>標記/清除演算法（此處的效率只是簡單的對比時間複雜度，實際情況不一定如此）。

記憶體整齊度：複製演算法=標記/整理演算法>標記/清除演算法。

記憶體利用率：標記/整理演算法=標記/清除演算法>複製演算法。

    可以看到標記/清除演算法是比較落後的演算法了，但是後兩種演算法卻是在此基礎上建立的，俗話說“吃水不忘挖井人”，因此各位也莫要忘記了標記/清除這一演算法前輩。而且，在某些時候，標記/清除也會有用武之地。

    到此我們已經將三個演算法瞭解清楚了，可以看出，效率上來說，複製演算法是當之無愧的老大，但是卻浪費了太多記憶體，而為了儘量兼顧上面所提到的三個指標，標記/整理演算法相對來說更平滑一些，但效率上依然不盡如人意，它比複製演算法多了一個標記的階段，又比標記/清除多了一個整理記憶體的過程。最後介紹GC演算法中的神級演算法-----分代蒐集演算法。那麼分代蒐集演算法是怎麼處理GC的呢？

物件分類

    上一章已經說過，分代蒐集演算法是針對物件的不同特性，而使用適合的演算法，這裡面並沒有實際上的新演算法產生。與其說分代蒐集演算法是第四個演算法，不如說它是對前三個演算法的實際應用。首先我們來探討一下物件的不同特性，接下來LZ和各位來一起給這些物件選擇GC演算法。記憶體中的物件按照生命週期的長短大致可以分為三種，以下命名均為LZ個人的命名。

1、夭折物件：朝生夕滅的物件，通俗點講就是活不了多久就得死的物件。例子：某一個方法的局域變數、迴圈內的臨時變數等等。

2、老不死物件：這類物件一般活的比較久，歲數很大還不死，但歸根結底，老不死物件也幾乎早晚要死的，但也只是幾乎而已。例子：快取物件、資料庫連線物件、單例物件（單例模式）等等。

3、不滅物件：此類物件一般一旦出生就幾乎不死了，它們幾乎會一直永生不滅，記得，只是幾乎不滅而已。例子：String池中的物件（享元模式）、載入過的類資訊等等。

物件對應的記憶體區域

    還記得前面介紹記憶體管理時，JVM對記憶體的劃分嗎？我們將上面三種物件對應到記憶體區域當中，就是夭折物件和老不死物件都在JAVA堆，而不滅物件在方法區，之前的一章中我們就已經說過，對於JAVA堆，JVM規範要求必須實現GC，因而對於夭折物件和老不死物件來說，死幾乎是必然的結局，但也只是幾乎，還是難免會有一些物件會一直存活到應用結束，然而JVM規範對方法區的GC並不做要求，所以假設一個JVM實現沒有對方法區實現GC，那麼不滅物件就是真的不滅物件了。由於不滅物件的生命週期過長，因此分代蒐集演算法就是針對的JAVA堆而設計的，也就是針對夭折物件和老不死物件。

JAVA堆的物件回收（夭折物件和老不死物件）

    有了以上分析，我們來看看分代蒐集演算法如何處理JAVA堆的記憶體回收的，也就是夭折物件與老不死物件的回收。夭折物件：這類物件朝生夕滅，存活時間短，還記得複製演算法的使用要求嗎？那就是物件存活率不能太高，因此夭折物件是最適合使用複製演算法的。小疑問：50%記憶體的浪費怎麼辦？答疑：因為夭折物件一般存活率較低，因此可以不使用50%的記憶體作為空閒，一般的，使用兩塊10%的記憶體作為空閒和活動區間，而另外80%的記憶體，則是用來給新建物件分配記憶體的，一旦發生GC，將10%的活動區間與另外80%中存活的物件轉移到10%的空閒區間，接下來，將之前90%的記憶體全部釋放，以此類推。為了讓各位更加清楚的看出來這個GC流程，LZ給出下面圖示。

    圖中標註了三個區域中在各個階段，各自記憶體的情況。相信看著圖，它的GC流程已經不難理解了。不過有兩點LZ需要提一下，第一點是使用這樣的方式，我們只浪費了10%的記憶體，這個是可以接受的，因為我們換來了記憶體的整齊排列與GC速度。第二點是，這個策略的前提是，每次存活的物件佔用的記憶體不能超過這10%的大小，一旦超過，多出的物件將無法複製。

    為了解決上面的意外情況，也就是存活物件佔用的記憶體太大時的情況，高手們將JAVA堆分成兩部分來處理，上述三個區域則是第一部分，稱為新生代或者年輕代，而餘下的一部分，專門存放老不死物件的則稱為年老代。是不是很貼切的名字呢？下面我們看看老不死物件的處理方式。老不死物件：這一類物件存活率非常高，因為它們大多是從新生代轉過來的，就像人一樣，活的年月久了，就變成老不死了。

通常情況下，以下兩種情況發生的時候，物件會從新生代區域轉到年老帶區域。

1、在新生代裡的每一個物件，都會有一個年齡，當這些物件的年齡到達一定程度時（年齡就是熬過的GC次數，每次GC如果物件存活下來，則年齡加1），則會被轉到年老代，而這個轉入年老代的年齡值，一般在JVM中是可以設定的。

2、在新生代存活物件佔用的記憶體超過10%時，則多餘的物件會放入年老代。這種時候，年老代就是新生代的“備用倉庫”。

    針對老不死物件的特性，顯然不再適合使用複製演算法，因為它的存活率太高，而且不要忘了，如果年老代再使用複製演算法，它可是沒有備用倉庫的。因此一般針對老不死物件只能採用標記/整理或者標記/清除演算法。

方法區的物件回收（不滅物件）

    以上兩種情況已經解決了GC的大部分問題，因為JAVA堆是GC的主要關注物件，而以上也已經包含了分代蒐集演算法的全部內容，接下來對於不滅物件的回收，已經不屬於分代蒐集演算法的內容。不滅物件存在於方法區，在我們常用的hotspot虛擬機器（JDK預設的JVM）中，方法區也被親切的稱為永久代，又是一個很貼切的名字不是嗎？其實在很久很久以前，是不存在永久代的。當時永久代與年老代都存放在一起，裡面包含了JAVA類的例項資訊以及類資訊。但是後來發現，對於類資訊的解除安裝幾乎很少發生，因此便將二者分離開來。幸運的是，這樣做確實提高了不少效能，於是永久代便被拆分出來了。這一部分割槽域的GC與年老代採用相似的方法，由於都沒有“備用倉庫”，二者都是隻能使用標記/清除和標記/整理演算法。

回收的時機

    JVM在進行GC時，並非每次都對上面三個記憶體區域一起回收的，大部分時候回收的都是指新生代。因此GC按照回收的區域又分了兩種型別，一種是普通GC（minor GC），一種是全域性GC（major GC or Full GC），它們所針對的區域如下。普通GC（minor GC）：只針對新生代區域的GC。全域性GC（major GC or Full GC）：針對年老代的GC，偶爾伴隨對新生代的GC以及對永久代的GC。由於年老代與永久代相對來說GC效果不好，而且二者的記憶體使用增長速度也慢，因此一般情況下，需要經過好幾次普通GC，才會觸發一次全域性GC。