JVM学习之GC常用算法
2019獨角獸企業(yè)重金招聘Python工程師標準>>>
出處：博客園左瀟龍的技術博客--http://www.cnblogs.com/zuoxiaolong，多謝分享
GC策略解決了哪些問題？
既然是要進行自動GC，那必然會有相應的策略，而這些策略解決了哪些問題呢，粗略的來說，主要有以下幾點。
1、哪些對象可以被回收。
2、何時回收這些對象。
3、采用什么樣的方式回收。
GC策略采用的何種算法
? ? 有關上面所提到的三個問題，其實最主要的一個問題就是第一個，也就是哪些對象才是可以回收的,有一種比較簡單直觀的辦法，它的效率較高，被稱作引用計數(shù)算法，其原理是：此對象有一個引用，則+1；刪除一個引用，則-1。只用收集計數(shù)為0的對象。缺點是： （1）無法處理循環(huán)引用的問題。如：對象A和B分別有字段b、a，令A.b=B和B.a=A，除此之外這2個對象再無任何引用，那實際上這2個對象已經(jīng)不可能再被訪問，但是引用計數(shù)算法卻無法回收他們。（2）引用計數(shù)的方法需要編譯器的配合，編譯器需要為此對象生成額外的代碼。如賦值函數(shù)將此對象賦值給一個引用時，需要增加此對象的引用計數(shù)。還有就是，當一個引用變量的生命周期結束時，需要更新此對象的引用計數(shù)器。引用計數(shù)的方法由于存在顯著的缺點，實際上并未被JVM所使用。想象一下，假設JVM采用這種GC策略，那么程序猿在編寫的程序的時候，下面這樣的代碼就不要指望再出現(xiàn)了。
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 }??? ? 這段代碼看起來有點刻意為之，但其實在實際編程過程當中，是經(jīng)常出現(xiàn)的，比如兩個一對一關系的數(shù)據(jù)庫對象，各自保持著對方的引用,最后一個無限循環(huán)只是為了保持JVM不退出，沒什么實際意義。
? ? ? 對于我們現(xiàn)在使用的GC來說，當thread線程運行結束后，會將objectA和objectB全部作為待回收的對象,而如果我們的GC采用上面所說的引用計數(shù)算法，則這兩個對象永遠不會被回收，即便我們在使用后顯示的將對象歸為空值也毫無作用。
? ? ? 這里LZ大致解釋一下，在代碼中LZ標注了1、2、3三個數(shù)字，當?shù)?個地方的語句執(zhí)行完以后，兩個對象的引用計數(shù)全部為1。當?shù)?個地方的語句執(zhí)行完以后，兩個對象的引用計數(shù)就全部變成了2。當?shù)?個地方的語句執(zhí)行完以后，也就是將二者全部歸為空值以后，二者的引用計數(shù)仍然為1。根據(jù)引用計數(shù)算法的回收規(guī)則，引用計數(shù)沒有歸0的時候是不會被回收的。
根搜索算法
? ? 由于引用計數(shù)算法的缺陷，所以JVM一般會采用一種新的算法，叫做根搜索算法。它的處理方式就是，設立若干種根對象，當任何一個根對象到某一個對象均不可達時，則認為這個對象是可以被回收的。
? ? 就拿上圖來說，ObjectD和ObjectE是互相關聯(lián)的，但是由于GC roots到這兩個對象不可達，所以最終D和E還是會被當做GC的對象，上圖若是采用引用計數(shù)法，則A-E五個對象都不會被回收，說到GC roots（GC根），在JAVA語言中，可以當做GC roots的對象有以下幾種：
1、虛擬機棧中的引用的對象。
2、方法區(qū)中的類靜態(tài)屬性引用的對象。
3、方法區(qū)中的常量引用的對象。
4、本地方法棧中JNI的引用的對象。
第一和第四種都是指的方法的本地變量表，第二種表達的意思比較清晰，第三種主要指的是聲明為final的常量值。
? ? 根搜索算法解決的是垃圾搜集的基本問題，也就是上面提到的第一個問題，也是最關鍵的問題，就是哪些對象可以被回收，不過垃圾收集顯然還需要解決后兩個問題，什么時候回收以及如何回收，在根搜索算法的基礎上，現(xiàn)代虛擬機的實現(xiàn)當中，垃圾搜集的算法主要有三種，分別是標記-清除算法、復制算法、標記-整理算法，這三種算法都擴充了根搜索算法，不過它們理解起來還是非常好理解的。
? ? 首先，我們回想一下上一章提到的根搜索算法，它可以解決我們應該回收哪些對象的問題，但是它顯然還不能承擔垃圾搜集的重任，因為我們在程序（程序也就是指我們運行在JVM上的JAVA程序）運行期間如果想進行垃圾回收，就必須讓GC線程與程序當中的線程互相配合，才能在不影響程序運行的前提下，順利的將垃圾進行回收。
? ? 為了達到這個目的，標記/清除算法就應運而生了，它的做法是當堆中的有效內(nèi)存空間（available memory）被耗盡的時候，就會停止整個程序（也被成為stop the world），然后進行兩項工作，第一項則是標記，第二項則是清除。
（1）標記：標記的過程其實就是，遍歷所有的GC Roots，然后將所有GC Roots可達的對象標記為存活的對象。
（2）清除：清除的過程將遍歷堆中所有的對象，將沒有標記的對象全部清除掉。
? ? 其實這兩個步驟并不是特別復雜，也很容易理解。LZ用通俗的話解釋一下標記/清除算法，就是當程序運行期間，若可以使用的內(nèi)存被耗盡的時候，GC線程就會被觸發(fā)并將程序暫停，隨后將依舊存活的對象標記一遍，最終再將堆中所有沒被標記的對象全部清除掉，接下來便讓程序恢復運行。
下面LZ給各位制作了一組描述上面過程的圖片，結合著圖片，我們來直觀的看下這一過程，首先是第一張圖。
? ? 這張圖代表的是程序運行期間所有對象的狀態(tài)，它們的標志位全部是0（也就是未標記，以下默認0就是未標記，1為已標記），假設這會兒有效內(nèi)存空間耗盡了，JVM將會停止應用程序的運行并開啟GC線程，然后開始進行標記工作，按照根搜索算法，標記完以后，對象的狀態(tài)如下圖。
? ? 可以看到，按照根搜索算法，所有從root對象可達的對象就被標記為了存活的對象，此時已經(jīng)完成了第一階段標記。接下來，就要執(zhí)行第二階段清除了，那么清除完以后，剩下的對象以及對象的狀態(tài)如下圖所示。
? ? 可以看到，沒有被標記的對象將會回收清除掉，而被標記的對象將會留下，并且會將標記位重新歸0。接下來就不用說了，喚醒停止的程序線程，讓程序繼續(xù)運行即可，其實這一過程并不復雜，甚至可以說非常簡單，各位說對嗎。不過其中有一點值得LZ一提，就是為什么非要停止程序的運行呢？這個其實也不難理解，LZ舉個最簡單的例子，假設我們的程序與GC線程是一起運行的，各位試想這樣一種場景。
? ? 假設我們剛標記完圖中最右邊的那個對象，暫且記為A，結果此時在程序當中又new了一個新對象B，且A對象可以到達B對象，但是由于此時A對象已經(jīng)標記結束，B對象此時的標記位依然是0，因為它錯過了標記階段，因此當接下來輪到清除階段的時候，新對象B將會被苦逼的清除掉。如此一來，不難想象結果，GC線程將會導致程序無法正常工作。上面的結果當然令人無法接受，我們剛new了一個對象，結果經(jīng)過一次GC，忽然變成null了，這還怎么玩？
標記/清除算法缺點
1、首先，它的缺點就是效率比較低（遞歸與全堆對象遍歷），而且在進行GC的時候，需要停止應用程序，這會導致用戶體驗非常差勁，尤其對于交互式的應用程序來說簡直是無法接受。試想一下，如果你玩一個網(wǎng)站，這個網(wǎng)站一個小時就掛五分鐘，你還玩嗎？
2、第二點主要的缺點，則是這種方式清理出來的空閑內(nèi)存是不連續(xù)的，這點不難理解，我們的死亡對象都是隨即的出現(xiàn)在內(nèi)存的各個角落的，現(xiàn)在把它們清除之后，內(nèi)存的布局自然會亂七八糟。而為了應付這一點，JVM就不得不維持一個內(nèi)存的空閑列表，這又是一種開銷。而且在分配數(shù)組對象的時候，尋找連續(xù)的內(nèi)存空間會不太好找。
復制算法
? ? 我們首先一起來看一下復制算法的做法，復制算法將內(nèi)存劃分為兩個區(qū)間，在任意時間點，所有動態(tài)分配的對象都只能分配在其中一個區(qū)間（稱為活動區(qū)間），而另外一個區(qū)間（稱為空閑區(qū)間）則是空閑的，當有效內(nèi)存空間耗盡時，JVM將暫停程序運行，開啟復制算法GC線程。接下來GC線程會將活動區(qū)間內(nèi)的存活對象，全部復制到空閑區(qū)間，且嚴格按照內(nèi)存地址依次排列，與此同時，GC線程將更新存活對象的內(nèi)存引用地址指向新的內(nèi)存地址。此時，空閑區(qū)間已經(jīng)與活動區(qū)間交換，而垃圾對象現(xiàn)在已經(jīng)全部留在了原來的活動區(qū)間，也就是現(xiàn)在的空閑區(qū)間。事實上，在活動區(qū)間轉換為空間區(qū)間的同時，垃圾對象已經(jīng)被一次性全部回收，LZ給各位繪制一幅圖來說明問題，如下所示。
? ? 其實這個圖依然是上一章的例子，只不過此時內(nèi)存被復制算法分成了兩部分，下面我們看下當復制算法的GC線程處理之后，兩個區(qū)域會變成什么樣子，如下所示。
? ? 可以看到，1和4號對象被清除了，而2、3、5、6號對象則是規(guī)則的排列在剛才的空閑區(qū)間，也就是現(xiàn)在的活動區(qū)間之內(nèi)。此時左半部分已經(jīng)變成了空閑區(qū)間，不難想象，在下一次GC之后，左邊將會再次變成活動區(qū)間。很明顯，復制算法彌補了標記/清除算法中，內(nèi)存布局混亂的缺點。不過與此同時，它的缺點也是相當明顯的。
1、它浪費了一半的內(nèi)存，這太要命了。
2、如果對象的存活率很高，我們可以極端一點，假設是100%存活，那么我們需要將所有對象都復制一遍，并將所有引用地址重置一遍。復制這一工作所花費的時間，在對象存活率達到一定程度時，將會變的不可忽視。
所以從以上描述不難看出，復制算法要想使用，最起碼對象的存活率要非常低才行，而且最重要的是，我們必須要克服50%內(nèi)存的浪費。
標記/整理算法
標記/整理算法與標記/清除算法非常相似，它也是分為兩個階段：標記和整理。
（1）標記：它的第一個階段與標記/清除算法是一模一樣的，均是遍歷GC Roots，然后將存活的對象標記。
（2）整理：移動所有存活的對象，且按照內(nèi)存地址次序依次排列，然后將末端內(nèi)存地址以后的內(nèi)存全部回收。因此，第二階段才稱為整理階段。
它GC前后的圖示與復制算法的圖非常相似，只不過沒有了活動區(qū)間和空閑區(qū)間的區(qū)別，而過程又與標記/清除算法非常相似，我們來看GC前內(nèi)存中對象的狀態(tài)與布局，如下圖所示。
? ? 這張圖其實與標記/清楚算法一模一樣，只是LZ為了方便表示內(nèi)存規(guī)則的連續(xù)排列，加了一個矩形表示內(nèi)存區(qū)域。倘若此時GC線程開始工作，那么緊接著開始的就是標記階段了。此階段與標記/清除算法的標記階段是一樣一樣的，我們看標記階段過后對象的狀態(tài)，如下圖。
沒什么可解釋的，接下來，便應該是整理階段了，我們來看當整理階段處理完以后，內(nèi)存的布局是如何的，如下圖。
? ? 可以看到，標記的存活對象將會被整理，按照內(nèi)存地址依次排列，而未被標記的內(nèi)存會被清理掉。如此一來，當我們需要給新對象分配內(nèi)存時，JVM只需要持有一個內(nèi)存的起始地址即可，這比維護一個空閑列表顯然少了許多開銷，不難看出，標記/整理算法不僅可以彌補標記/清除算法當中，內(nèi)存區(qū)域分散的缺點，也消除了復制算法當中，內(nèi)存減半的高額代價，標記/整理算法唯一的缺點就是效率也不高，不僅要標記所有存活對象，還要整理所有存活對象的引用地址。從效率上來說，標記/整理算法要低于復制算法。這里LZ給各位總結一下三個算法的共同點以及它們各自的優(yōu)勢劣勢，讓各位對比一下，想必會更加清晰，它們的共同點主要有以下兩點。
1、三個算法都基于根搜索算法去判斷一個對象是否應該被回收，而支撐根搜索算法可以正常工作的理論依據(jù)，就是語法中變量作用域的相關內(nèi)容。因此，要想防止內(nèi)存泄露，最根本的辦法就是掌握好變量作用域，而不應該使用前面內(nèi)存管理雜談一章中所提到的C/C++式內(nèi)存管理方式。
2、在GC線程開啟時，或者說GC過程開始時，它們都要暫停應用程序（stop the world）。
它們的區(qū)別LZ按照下面幾點來給各位展示。（>表示前者要優(yōu)于后者，=表示兩者效果一樣）
效率：復制算法>標記/整理算法>標記/清除算法（此處的效率只是簡單的對比時間復雜度，實際情況不一定如此）。
內(nèi)存整齊度：復制算法=標記/整理算法>標記/清除算法。
內(nèi)存利用率：標記/整理算法=標記/清除算法>復制算法。
? ? 可以看到標記/清除算法是比較落后的算法了，但是后兩種算法卻是在此基礎上建立的，俗話說“吃水不忘挖井人”，因此各位也莫要忘記了標記/清除這一算法前輩。而且，在某些時候，標記/清除也會有用武之地。
? ? 到此我們已經(jīng)將三個算法了解清楚了，可以看出，效率上來說，復制算法是當之無愧的老大，但是卻浪費了太多內(nèi)存，而為了盡量兼顧上面所提到的三個指標，標記/整理算法相對來說更平滑一些，但效率上依然不盡如人意，它比復制算法多了一個標記的階段，又比標記/清除多了一個整理內(nèi)存的過程。最后介紹GC算法中的神級算法-----分代搜集算法。那么分代搜集算法是怎么處理GC的呢？
對象分類
? ? 上一章已經(jīng)說過，分代搜集算法是針對對象的不同特性，而使用適合的算法，這里面并沒有實際上的新算法產(chǎn)生。與其說分代搜集算法是第四個算法，不如說它是對前三個算法的實際應用。首先我們來探討一下對象的不同特性，接下來LZ和各位來一起給這些對象選擇GC算法。內(nèi)存中的對象按照生命周期的長短大致可以分為三種，以下命名均為LZ個人的命名。
1、夭折對象：朝生夕滅的對象，通俗點講就是活不了多久就得死的對象。例子：某一個方法的局域變量、循環(huán)內(nèi)的臨時變量等等。
2、老不死對象：這類對象一般活的比較久，歲數(shù)很大還不死，但歸根結底，老不死對象也幾乎早晚要死的，但也只是幾乎而已。例子：緩存對象、數(shù)據(jù)庫連接對象、單例對象（單例模式）等等。
3、不滅對象：此類對象一般一旦出生就幾乎不死了，它們幾乎會一直永生不滅，記得，只是幾乎不滅而已。例子：String池中的對象（享元模式）、加載過的類信息等等。
對象對應的內(nèi)存區(qū)域
? ? 還記得前面介紹內(nèi)存管理時，JVM對內(nèi)存的劃分嗎？我們將上面三種對象對應到內(nèi)存區(qū)域當中，就是夭折對象和老不死對象都在JAVA堆，而不滅對象在方法區(qū)，之前的一章中我們就已經(jīng)說過，對于JAVA堆，JVM規(guī)范要求必須實現(xiàn)GC，因而對于夭折對象和老不死對象來說，死幾乎是必然的結局，但也只是幾乎，還是難免會有一些對象會一直存活到應用結束，然而JVM規(guī)范對方法區(qū)的GC并不做要求，所以假設一個JVM實現(xiàn)沒有對方法區(qū)實現(xiàn)GC，那么不滅對象就是真的不滅對象了。由于不滅對象的生命周期過長，因此分代搜集算法就是針對的JAVA堆而設計的，也就是針對夭折對象和老不死對象。
JAVA堆的對象回收（夭折對象和老不死對象）
? ? 有了以上分析，我們來看看分代搜集算法如何處理JAVA堆的內(nèi)存回收的，也就是夭折對象與老不死對象的回收。夭折對象：這類對象朝生夕滅，存活時間短，還記得復制算法的使用要求嗎？那就是對象存活率不能太高，因此夭折對象是最適合使用復制算法的。小疑問：50%內(nèi)存的浪費怎么辦？答疑：因為夭折對象一般存活率較低，因此可以不使用50%的內(nèi)存作為空閑，一般的，使用兩塊10%的內(nèi)存作為空閑和活動區(qū)間，而另外80%的內(nèi)存，則是用來給新建對象分配內(nèi)存的，一旦發(fā)生GC，將10%的活動區(qū)間與另外80%中存活的對象轉移到10%的空閑區(qū)間，接下來，將之前90%的內(nèi)存全部釋放，以此類推。為了讓各位更加清楚的看出來這個GC流程，LZ給出下面圖示。
? ? 圖中標注了三個區(qū)域中在各個階段，各自內(nèi)存的情況。相信看著圖，它的GC流程已經(jīng)不難理解了。不過有兩點LZ需要提一下，第一點是使用這樣的方式，我們只浪費了10%的內(nèi)存，這個是可以接受的，因為我們換來了內(nèi)存的整齊排列與GC速度。第二點是，這個策略的前提是，每次存活的對象占用的內(nèi)存不能超過這10%的大小，一旦超過，多出的對象將無法復制。
? ? 為了解決上面的意外情況，也就是存活對象占用的內(nèi)存太大時的情況，高手們將JAVA堆分成兩部分來處理，上述三個區(qū)域則是第一部分，稱為新生代或者年輕代，而余下的一部分，專門存放老不死對象的則稱為年老代。是不是很貼切的名字呢？下面我們看看老不死對象的處理方式。老不死對象：這一類對象存活率非常高，因為它們大多是從新生代轉過來的，就像人一樣，活的年月久了，就變成老不死了。
通常情況下，以下兩種情況發(fā)生的時候，對象會從新生代區(qū)域轉到年老帶區(qū)域。
1、在新生代里的每一個對象，都會有一個年齡，當這些對象的年齡到達一定程度時（年齡就是熬過的GC次數(shù)，每次GC如果對象存活下來，則年齡加1），則會被轉到年老代，而這個轉入年老代的年齡值，一般在JVM中是可以設置的。
2、在新生代存活對象占用的內(nèi)存超過10%時，則多余的對象會放入年老代。這種時候，年老代就是新生代的“備用倉庫”。
? ? 針對老不死對象的特性，顯然不再適合使用復制算法，因為它的存活率太高，而且不要忘了，如果年老代再使用復制算法，它可是沒有備用倉庫的。因此一般針對老不死對象只能采用標記/整理或者標記/清除算法。
方法區(qū)的對象回收（不滅對象）
? ? 以上兩種情況已經(jīng)解決了GC的大部分問題，因為JAVA堆是GC的主要關注對象，而以上也已經(jīng)包含了分代搜集算法的全部內(nèi)容，接下來對于不滅對象的回收，已經(jīng)不屬于分代搜集算法的內(nèi)容。不滅對象存在于方法區(qū)，在我們常用的hotspot虛擬機（JDK默認的JVM）中，方法區(qū)也被親切的稱為永久代，又是一個很貼切的名字不是嗎？其實在很久很久以前，是不存在永久代的。當時永久代與年老代都存放在一起，里面包含了JAVA類的實例信息以及類信息。但是后來發(fā)現(xiàn)，對于類信息的卸載幾乎很少發(fā)生，因此便將二者分離開來。幸運的是，這樣做確實提高了不少性能，于是永久代便被拆分出來了。這一部分區(qū)域的GC與年老代采用相似的方法，由于都沒有“備用倉庫”，二者都是只能使用標記/清除和標記/整理算法。
回收的時機
? ? JVM在進行GC時，并非每次都對上面三個內(nèi)存區(qū)域一起回收的，大部分時候回收的都是指新生代。因此GC按照回收的區(qū)域又分了兩種類型，一種是普通GC（minor GC），一種是全局GC（major GC or Full GC），它們所針對的區(qū)域如下。普通GC（minor GC）：只針對新生代區(qū)域的GC。全局GC（major GC or Full GC）：針對年老代的GC，偶爾伴隨對新生代的GC以及對永久代的GC。由于年老代與永久代相對來說GC效果不好，而且二者的內(nèi)存使用增長速度也慢，因此一般情況下，需要經(jīng)過好幾次普通GC，才會觸發(fā)一次全局GC。
轉載于:https://my.oschina.net/RainyZou/blog/1591306
總結
以上是生活随笔為你收集整理的JVM学习之GC常用算法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mac connect to host
- 下一篇： iOS开发的一些事