JVM學習之GC經常使用算法

出處：博客園左瀟龍的技術博客--http://www.cnblogs.com/zuoxiaolong，多謝分享

GC策略解決了哪些問題？

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

一、哪些對象能夠被回收。

二、什麼時候回收這些對象。

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

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標註了一、二、3三個數字，當第1個地方的語句執行完之後，兩個對象的引用計數所有爲1。當第2個地方的語句執行完之後，兩個對象的引用計數就所有變成了2。當第3個地方的語句執行完之後，也就是將兩者所有歸爲空值之後，兩者的引用計數仍然爲1。根據引用計數算法的回收規則，引用計數沒有歸0的時候是不會被回收的。

根搜索算法

    因爲引用計數算法的缺陷，因此JVM通常會採用一種新的算法，叫作根搜索算法。它的處理方式就是，設立若干種根對象，當任何一個根對象到某一個對象均不可達時，則認爲這個對象是能夠被回收的。

    就拿上圖來講，ObjectD和ObjectE是互相關聯的，可是因爲GC roots到這兩個對象不可達，因此最終D和E仍是會被當作GC的對象，上圖如果採用引用計數法，則A-E五個對象都不會被回收，說到GC roots（GC根），在JAVA語言中，能夠當作GC roots的對象有如下幾種：

一、虛擬機棧中的引用的對象。

二、方法區中的類靜態屬性引用的對象。

三、方法區中的常量引用的對象。

四、本地方法棧中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了，這還怎麼玩？

標記/清除算法缺點

一、首先，它的缺點就是效率比較低（遞歸與全堆對象遍歷），並且在進行GC的時候，須要中止應用程序，這會致使用戶體驗很是差勁，尤爲對於交互式的應用程序來講簡直是沒法接受。試想一下，若是你玩一個網站，這個網站一個小時就掛五分鐘，你還玩嗎？

二、第二點主要的缺點，則是這種方式清理出來的空閒內存是不連續的，這點不難理解，咱們的死亡對象都是隨即的出如今內存的各個角落的，如今把它們清除以後，內存的佈局天然會亂七八糟。而爲了應付這一點，JVM就不得不維持一個內存的空閒列表，這又是一種開銷。並且在分配數組對象的時候，尋找連續的內存空間會不太好找。

複製算法

    咱們首先一塊兒來看一下複製算法的作法，複製算法將內存劃分爲兩個區間，在任意時間點，全部動態分配的對象都只能分配在其中一個區間（稱爲活動區間），而另一個區間（稱爲空閒區間）則是空閒的，當有效內存空間耗盡時，JVM將暫停程序運行，開啓複製算法GC線程。接下來GC線程會將活動區間內的存活對象，所有複製到空閒區間，且嚴格按照內存地址依次排列，與此同時，GC線程將更新存活對象的內存引用地址指向新的內存地址。此時，空閒區間已經與活動區間交換，而垃圾對象如今已經所有留在了原來的活動區間，也就是如今的空閒區間。事實上，在活動區間轉換爲空間區間的同時，垃圾對象已經被一次性所有回收，LZ給各位繪製一幅圖來講明問題，以下所示。

    其實這個圖依然是上一章的例子，只不過此時內存被複制算法分紅了兩部分，下面咱們看下當複製算法的GC線程處理以後，兩個區域會變成什麼樣子，以下所示。

    能夠看到，1和4號對象被清除了，而二、三、五、6號對象則是規則的排列在剛纔的空閒區間，也就是如今的活動區間以內。此時左半部分已經變成了空閒區間，不難想象，在下一次GC以後，左邊將會再次變成活動區間。很明顯，複製算法彌補了標記/清除算法中，內存佈局混亂的缺點。不過與此同時，它的缺點也是至關明顯的。

一、它浪費了一半的內存，這太要命了。

二、若是對象的存活率很高，咱們能夠極端一點，假設是100%存活，那麼咱們須要將全部對象都複製一遍，並將全部引用地址重置一遍。複製這一工做所花費的時間，在對象存活率達到必定程度時，將會變的不可忽視。

因此從以上描述不難看出，複製算法要想使用，最起碼對象的存活率要很是低才行，並且最重要的是，咱們必需要克服50%內存的浪費。

標記/整理算法

標記/整理算法與標記/清除算法很是類似，它也是分爲兩個階段：標記和整理。

（1）標記：它的第一個階段與標記/清除算法是如出一轍的，均是遍歷GC Roots，而後將存活的對象標記。

（2）整理：移動全部存活的對象，且按照內存地址次序依次排列，而後將末端內存地址之後的內存所有回收。所以，第二階段才稱爲整理階段。

它GC先後的圖示與複製算法的圖很是類似，只不過沒有了活動區間和空閒區間的區別，而過程又與標記/清除算法很是類似，咱們來看GC前內存中對象的狀態與佈局，以下圖所示。

    這張圖其實與標記/清楚算法如出一轍，只是LZ爲了方便表示內存規則的連續排列，加了一個矩形表示內存區域。假若此時GC線程開始工做，那麼緊接着開始的就是標記階段了。此階段與標記/清除算法的標記階段是同樣同樣的，咱們看標記階段事後對象的狀態，以下圖。

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

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

一、三個算法都基於根搜索算法去判斷一個對象是否應該被回收，而支撐根搜索算法能夠正常工做的理論依據，就是語法中變量做用域的相關內容。所以，要想防止內存泄露，最根本的辦法就是掌握好變量做用域，而不該該使用前面內存管理雜談一章中所提到的C/C++式內存管理方式。

二、在GC線程開啓時，或者說GC過程開始時，它們都要暫停應用程序（stop the world）。

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

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

內存整齊度：複製算法=標記/整理算法>標記/清除算法。

內存利用率：標記/整理算法=標記/清除算法>複製算法。

    能夠看到標記/清除算法是比較落後的算法了，可是後兩種算法倒是在此基礎上創建的，俗話說「吃水不忘挖井人」，所以各位也莫要忘記了標記/清除這一算法前輩。並且，在某些時候，標記/清除也會有用武之地。

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

對象分類

    上一章已經說過，分代蒐集算法是針對對象的不一樣特性，而使用適合的算法，這裏面並無實際上的新算法產生。與其說分代蒐集算法是第四個算法，不如說它是對前三個算法的實際應用。首先咱們來探討一下對象的不一樣特性，接下來LZ和各位來一塊兒給這些對象選擇GC算法。內存中的對象按照生命週期的長短大體能夠分爲三種，如下命名均爲LZ我的的命名。

一、夭折對象：朝生夕滅的對象，通俗點講就是活不了多久就得死的對象。例子：某一個方法的局域變量、循環內的臨時變量等等。

二、老不死對象：這類對象通常活的比較久，歲數很大還不死，但歸根結底，老不死對象也幾乎遲早要死的，但也只是幾乎而已。例子：緩存對象、數據庫鏈接對象、單例對象（單例模式）等等。

三、不滅對象：此類對象通常一旦出生就幾乎不死了，它們幾乎會一直永生不滅，記得，只是幾乎不滅而已。例子：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堆分紅兩部分來處理，上述三個區域則是第一部分，稱爲新生代或者年輕代，而餘下的一部分，專門存放老不死對象的則稱爲年老代。是否是很貼切的名字呢？下面咱們看看老不死對象的處理方式。老不死對象：這一類對象存活率很是高，由於它們大可能是重新生代轉過來的，就像人同樣，活的年月久了，就變成老不死了。

一般狀況下，如下兩種狀況發生的時候，對象會重新生代區域轉到年老帶區域。

一、在新生代裏的每個對象，都會有一個年齡，當這些對象的年齡到達必定程度時（年齡就是熬過的GC次數，每次GC若是對象存活下來，則年齡加1），則會被轉到年老代，而這個轉入年老代的年齡值，通常在JVM中是能夠設置的。

二、在新生代存活對象佔用的內存超過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。