JVM GC垃圾回收機制及算法

1、GC

          1.1 Minor GC

                 特點:發生在新生代上,發生的較頻繁,執行速度較快

                 觸發條件:Eden 區空間不足 \ 空間分配擔保

          1.2 Full GC

                  特點:主要發生在老年代上(新生代也會回收),較少發生,執行速度較慢

                  觸發條件:1)、調用 System.gc()

                                    2)、老年代區域空間不足

                                    3)、空間分配擔保失敗

                                    4)、JDK 1.7 及以前的永久代(方法區)空間不足

                                    5)、CMS GC 處理浮動垃圾時,如果新生代空間不足,則採用分配擔保機制,如果老年代空間不足,則                                                 觸發Full GC

2、垃圾回收算法

 

   2.1、複製算法

    將可用內存按容量劃分爲大小相同的兩塊,每塊只使用其中的一塊。當着一塊的內存用完了,就將還存活着的對象複製到另外一塊上面,然後再把已使用過的內存空間一次清理掉。這樣使得每次都是對整個半區進行內存回收,內存分配時也不需要考慮碎片化問題等複雜情況,只要按順序分配內存即可,實現簡單,運行高效。只是這種算法的代價是將內存縮小爲了原來的一半。

 

     注意:內存移動是必須實打實的移動(複製),不能使用指針玩

 

    有研究表明,新生代的對象 90% 是“朝生夕死” 的,所以一半來說回收佔據 10% 的空間夠用了,所以並不需要按照1:1 的比例來劃分空間,而是減內存分爲一塊較大的 Eden 的空間和兩塊較小的 Survivor空間,每次使用 Eden和其中一塊 Survivor[1]。當回收時,將 Eden 和 Survivor 中還存活着的對象  一次性的賦值到另外一塊 Survivor 空間上,然後清理掉 Eden 和剛纔用過的 Survivor空間。

   HotSpot 虛擬機默認 Eden 和 Survivor 的大小比例是 8:1 , 也就是每次使用新生代中可用內存空間爲整個新生代容量的 90% (80%+10%),只有 10% 的內存會被 “浪費”。

 

2.2、標記-清除算法:

      過程:

            1、首先標記所有需要回收的對象

             2、統一回收被標記的對象

        缺點:

            1、效率問題,標記和清除效率都不高

            2、標記清除之後會產生大量不聯繫的內存碎片,空間碎片太多可能會導致以後在程序運行過程中需要分配較大對象時,無法找到足夠的連續內存提前出發另一次垃圾收集動作

     

2.3、標記-整理算法

           首先標記出所有需要回收的對象,在標記完成後,後續步驟不是直接對可回收對象進行清除,而是讓所有存活的對象向一端移動,然後清理掉端邊界以外的內存

 

 

 

 

 

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章