refer to  http://www.cnblogs.com/zuoxiaolong/p/jvm5.html

在說以下兩種演算法前，說說他們的進化源——標記清除  有什麼問題。  第二點尤甚

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

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

複製演算法

         我們首先一起來看一下複製演算法的做法，複製演算法將記憶體劃分為兩個區間，在任意時間點，所有動態分配的物件都只能分配在其中一個區間（稱為活動區間），而另外一個區間（稱為空閒區間）則是空閒的。

         當有效記憶體空間耗盡時，JVM將暫停程式執行，開啟複製演算法GC執行緒。接下來GC執行緒會將活動區間內的存活物件，全部複製到空閒區間，且嚴格按照記憶體地址依次排列，與此同時，GC執行緒將更新存活物件的記憶體引用地址指向新的記憶體地址。

         此時，空閒區間已經與活動區間交換，而垃圾物件現在已經全部留在了原來的活動區間，也就是現在的空閒區間。事實上，在活動區間轉換為空間區間的同時，垃圾物件已經被一次性全部回收。

         聽起來複雜嗎？

         其實一點也不復雜，有了上一章的基礎，相信各位理解這個演算法不會費太多力氣。LZ給各位繪製一幅圖來說明問題，如下所示。

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

       可以看到，1和4號物件被清除了，而2、3、5、6號物件則是規則的排列在剛才的空閒區間，也就是現在的活動區間之內。此時左半部分已經變成了空閒區間，不難想象，在下一次GC之後，左邊將會再次變成活動區間。

       很明顯，複製演算法彌補了標記/清除演算法中，記憶體佈局混亂的缺點

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

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

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

標記/整理演算法

       標記/整理演算法與標記/清除演算法非常相似，它也是分為兩個階段：標記和整理。下面LZ給各位介紹一下這兩個階段都做了什麼。

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

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

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

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

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

       可以看到，標記的存活物件將會被整理，按照記憶體地址依次排列，而未被標記的記憶體會被清理掉。如此一來，當我們需要給新物件分配記憶體時，JVM只需要持有一個記憶體的起始地址即可，這比維護一個空閒列表顯然少了許多開銷。

       不難看出，標記/整理演算法不僅可以彌補標記/清除演算法當中，記憶體區域分散的缺點，也消除了複製演算法當中，記憶體減半的高額代價，可謂是一舉兩得，一箭雙鵰，一石兩鳥，一。。。。一女兩男？

       不過任何演算法都會有其缺點，標記/整理演算法唯一的缺點就是效率也不高，不僅要標記所有存活物件，還要整理所有存活物件的引用地址。從效率上來說，標記/整理演算法要低於複製演算法。

演算法總結

       這裡LZ給各位總結一下三個演算法的共同點以及它們各自的優勢劣勢，讓各位對比一下，想必會更加清晰。

       它們的共同點主要有以下兩點。

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

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

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

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

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

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

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

結束語

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

       難道就沒有一種最優演算法嗎？

       當然是沒有的，這個世界是公平的，任何東西都有兩面性，試想一下，你怎麼可能找到一個又漂亮又勤快又有錢又通情達理，性格又合適，家境也合適，身高長相等等等等都合適的女人？就算你找到了，至少有一點這個女人也肯定不滿足，那就是多半不會恰巧又愛上了與LZ相似的各位苦逼猿友們。你是不是想說你比LZ強太多了，那LZ只想對你說，高富帥是不會爬在電腦前看技術文章的，0.0。

       但是古人就是給力，古人說了，找媳婦不一定要找最好的，而是要找最合適的，聽完這句話，瞬間感覺世界美好了許多。

       演算法也是一樣的，沒有最好的演算法，只有最合適的演算法。 

       既然這三種演算法都各有缺陷，高人們自然不會容許這種情況發生。因此，高人們提出可以根據物件的不同特性，使用不同的演算法處理，類似於蘿蔔白菜各有所愛的原理。於是奇蹟發生了，高人們終於找到了GC演算法中的神級演算法-----分代蒐集演算法。

       至於這個神級演算法是如何處理的，LZ就在下一章再和各位猿友探討了，本次就到此為止了，希望各位有所收穫。