Java內存分代、垃圾回收

內存分代

    一個應用啓動，操做系統會給他分配一個初始的內存大小，由上可知，這部份內存大部分應該屬於堆內存，JVM 爲了更好地利用管理這部份內存，對該區域作了劃分。一部分紅爲新生代，另外一部分稱爲老年代。

    一開始對象的建立都發生在新生代，隨着對象的不斷建立，若是新生代沒有空間建立新對象，將會發生 GC ，這時的 GC 稱之爲 Minor GC，位於新生代的對象每通過一次 Minor GC 後，若是這個對象沒有被回收，則爲本身的標記數加1，這個標記數用於標識這個對象經歷了多少次的 Minor GC，對於 Sun 的 Hotspot 虛擬機，若是這個次數超過 15 ，該對象纔會被移動到老年代。

    隨着時間的推移，若是老年代也沒有足夠的空間容納對象，老年代也會試着發起 GC，這時的 GC 被稱爲 Full GC。

    相比 Minor GC，Full GC 發生的次數比較少，可是每發生一次 Full GC，整個堆內存區域都須要執行一次垃圾回收，這對程序性能形成的影響比 Minor GC 大不少。因此咱們應該儘可能避免或者減小 Full GC 的發生。

    同時，在堆內存區域，發生最多的 GC 情形就是新生代的 Minor GC 了，由於全部的對象會優先去新生代開闢空間，因此這塊的內存變化會很快，只有內存不夠用，就會發生 GC，可是通常的 Minor GC 執行比 Full GC 快不少。爲何呢？由於新生代和老年代的垃圾回收算法不同。

 

垃圾回收算法

標記-清除算法（Mark-Sweep）

這是最基礎的收集算法，如它的名字同樣，算法分爲「標記」和「清除」兩個階段：

首先標記出全部須要回收的對象，在標記完成後統一回收掉全部被標記的對象。

之因此說它是最基礎的收集算法，是由於後續的收集算法都是基於這種思路並對其缺點進行改進而獲得的。

它的主要缺點有兩個：一個是效率問題，標記和清除過程的效率都不高；另一個是空間問題，標記清除以後會產生大量不連續的內存碎片，空間碎片太多可能會致使，當程序在之後的運行過程當中須要分配較大對象時沒法找到足夠的連續內存而不得不提早觸發另外一次垃圾收集動做。

複製算法（Copying）

爲了解決效率問題，一種稱爲「複製」（Copying）的收集算法出現了，它將可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活着的對象複製到另一塊上面，而後再把已使用過的內存空間一次清理掉。

這樣使得每次都是對其中的一塊進行內存回收，內存分配時也就不用考慮內存碎片等複雜狀況，只要移動堆頂指針，按順序分配內存便可，實現簡單，運行高效。只是這種算法的代價是將內存縮小爲原來的一半，未免過高了一點。

可是這種算法的效率至關高，因此，如今的商業虛擬機都採用這種收集算法來回收新生代。爲何新生代可使用複製算法呢？

IBM 有專門研究代表，新生代中的對象 98% 都是朝生夕死，因此就不須要按照1:1的比例來劃份內存空間。這裏鑑於此，新生代採用了以下的劃分策略。

如今把新生代再劃分爲三部分，一塊較大的 Eden(伊甸園) 和兩塊較小的 Survivor(倖存者) 區域。

當回收時，將 Eden 和 Survivor 中還存活着的對象一次性地拷貝到另一塊Survivor空間上，最後清理掉Eden和剛纔用過的Survivor的空間。HotSpot 虛擬機默認Eden和Survivor的大小比例是8∶1，也就是每次新生代中可用內存空間爲整個新生代容量的90%（80%+10%），只有10%的內存是會被「浪費」的。

這樣清理完成後，原來的 Survivor 就空了，並一直保持爲空，直到下次 Minor GC 時，它再做爲存活對象的盛放地。兩個 Survivor 就這樣輪流當作 GC 過程當中新生代存活對象的中轉站。

可是，若是使用複製算法的內存區域有大量的存活對象時，複製算法就會變得捉襟見肘，這時須要更大的 Survivor 區用於盛放那些存活對象，甚至可能須要 1:1的比例。因此針對堆內存區域的老年代，就有了下面的算法。

標記-整理算法

標記過程仍然與「標記-清除」算法同樣，但後續步驟不是直接對可回收對象進行清理，而是讓全部存活的對象都向一端移動，而後直接清理掉端邊界之外的內存。這種方法避免了碎片的產生，同時也不須要一塊額外的內存空間，對於老年代會比較合適。

可是相比複製算法，雖然該算法佔用的內存空間少，可是耗費的垃圾回收時間會比複製算法久，因此上面也說了

咱們應該儘可能避免或者減小 Full GC 的發生。

這兩種算法用精煉的語言描述就是

• 複製算法:用空間換時間
• 標記-整理算法：用時間換空間

一句話 魚與熊掌不可兼得，可是針對新生代和老年代，他們都是最佳的選擇。