jvm - 垃圾回收

時間 2019-12-12

標籤 jvm 垃圾回收欄目 Java 简体版

原文原文鏈接

jvm - 垃圾回收

注意 : 本系列文章爲學習系列,部份內容會取自相關書籍或者網絡資源,在文章中間和末尾處會有標註java

垃圾回收的意義

它使得java程序員再也不時時刻刻的關注內存管理方面的工做.git

垃圾回收機制會自動的管理jvm內存空間,將那些已經不會被使用到了的"垃圾對象"清理掉",釋放出更多的空間給其餘對象使用.程序員

何爲對象的引用?

Java中的垃圾回收通常是在Java堆中進行，由於堆中幾乎存放了Java中全部的對象實例算法

在java中,對引用的概念簡述以下(引用強度依次減弱) :網絡

強引用 : 這類引用是Java程序中最廣泛的,只要強引用還存在，垃圾收集器就永遠不會回收掉被引用的對象多線程
軟引用 : 用來描述一些非必須的對象,在系統內存不夠使用時,這類對象會被垃圾收集器回收,JDK提供了SoftReference類來實現軟引用併發
弱引用 : 用來描述一些非必須的對象,只要發生GC,不管可是內存是否夠用,這類對象就會被垃圾收集器回收,JDK提供了WeakReference類來實現弱引用框架
虛引用 : 與其餘幾種引用不一樣,它不影響對象的生命週期,若是這個對象是虛運用,則就跟沒有引用同樣,在任什麼時候刻均可能會回收,JDK提供了PhantomReference類來實現虛引用jvm

以下爲相關示例代碼oop

public class ReferenceDemo {
    public static void main(String[] arge) {
        //強引用
        Object object = new Object();
        Object[] objects = new Object[100];

        //軟引用
        SoftReference<String> stringSoftReference = new SoftReference<>(new String("SoftReference"));
        System.out.println(stringSoftReference.get());
        System.gc();
        System.out.println(stringSoftReference.get()); //手動GC,這時內存充足,對象沒有被回收

        System.out.println();

        //弱引用
        WeakReference<String> stringWeakReference = new WeakReference<>(new String("WeakReference"));
        System.out.println(stringWeakReference.get());
        System.gc();
        System.out.println(stringWeakReference.get()); //手動gc,這時,返回null,對象已經被回收

        System.out.println();

        //虛引用
        //虛引用主要用來跟蹤對象被垃圾回收器回收的活動。
        //虛引用與軟引用和弱引用的一個區別在於：虛引用必須和引用隊列 （ReferenceQueue）聯合使用。
        //當垃圾回收器準備回收一個對象時，若是發現它還有虛引用，就會在回收對象的內存以前，把這個虛引用加入到與之 關聯的引用隊列中
        ReferenceQueue<String> stringReferenceQueue = new ReferenceQueue<>();
        PhantomReference<String> stringPhantomReference = new PhantomReference<>(new String("PhantomReference"), stringReferenceQueue);
        System.out.println(stringPhantomReference.get());
    }
}

固然,關於這幾種引用還有不少知識點,本文只作簡單的介紹,後續有機會再單獨的文章詳細介紹.

如何肯定須要回收的垃圾對象?

引用計數器

每一個對象都有一個引用計數器 , 新增一個引用的時候就+1,引用釋放的時候就-1,當計數器爲0的時候,就表示能夠回收

引用計數算法的實現簡單，斷定效率也很高，在大部分狀況下它都是一個不錯的選擇，當Java語言並無選擇這種算法來進行垃圾回收，主要緣由是它很難解決對象之間的相互循環引用問題

public class LoopReferenceDemo {
    
    public static void main(String[] args) {
        TestA a = new TestA(); //1
        TestB b = new TestB(); //2
        a.b = b; //3
        b.a = a; //4
        a = null; //5
        b = null; //6
    }
    
}

class TestA {
    public TestB b;

}

class TestB {
    public TestA a;
}

雖然a和b都爲null,可是a和b存在循環引用,這樣a和b就永遠不會被回收

若是你在互聯網上搜索"引用計數器"這個關鍵字,一般都會獲得以上這一個結論,可是究竟爲何a和b不會被回,收其實仍是沒有說清楚的,下面簡單說明一下 :

第一行 : TestA的引用計數器加1,TestA的引用數量爲1
第二行 : TestB的引用計數器加1,TestB的引用數量爲1
第三行 : TestB的引用計數器加1,TestB的引用數量爲2
第四行 : TestA的引用計數器加1,TestA的引用數量爲2

內存分佈以下圖

第五行 : 將a變量設置爲null,再也不指向堆中的引用,因此TestA的引用計數器減1,TestA的引用數量爲1
第六行 : 將b變量設置爲null,再也不指向堆中的引用,因此TestB的引用計數器減1,TestB的引用數量爲1

內存分佈以下圖

結論 : 雖然上面程序將a和b設置爲null了,可是在堆中,TestA和TestB仍是互相持有對方的引用,引用計數器依然不等於0,這個就稱爲循環引用,因此說"引用計數器"會存在這個問題,致使這類對象沒法被清理掉.

以上的知識點參考 : https://www.zhihu.com/question/21539353

可達性分析

雖然以上的"引用計數器"算法存在"循環引用"的問題,不過目前主流的虛擬機都採用"可達性分析(GC Roots Tracing)"算法來標記那些對象是能夠被回收的.

該算法是從GC Roots開始向下搜索,搜索走過的路徑稱之爲引用鏈.當一個對象到GC Roots沒有任何引用鏈相連時,就表明這個對象是不可用的.稱爲"不可達對象"

GC Roots包括:

虛擬機棧(棧幀中的本地變量表)中的引用對象
方法區中的靜態屬性實體引用的對象
方法區中常量引用的對象
本地方法棧中JNI(Native方法)引用的對象

實際上，在根搜索算法中，要真正宣告一個對象死亡，至少要經歷兩次標記過程 :

若是對象在進行根搜索後發現沒有與GC Roots相鏈接的引用鏈，那它會被第一次標記而且進行一次篩選，篩選的條件是此對象是否有必要執行finalize（）方法
當對象沒有覆蓋finalize（）方法，或finalize（）方法已經被虛擬機調用過，虛擬機將這兩種狀況都視爲沒有必要執行
若是該對象被斷定爲有必要執行finalize（）方法，那麼這個對象將會被放置在一個名爲F-Queue隊列中，並在稍後由一條由虛擬機自動創建的、低優先級的Finalizer線程去執行finalize（）方法
finalize（）方法是對象逃脫死亡命運的最後一次機會（由於一個對象的finalize（）方法最多隻會被系統自動調用一次）, 稍後GC將對F-Queue中的對象進行第二次小規模的標記，若是要在finalize（）方法中成功拯救本身，只要在finalize（）方法中讓該對象重引用鏈上的任何一個對象創建關聯便可
而若是對象這時尚未關聯到任何鏈上的引用，那它就會被回收掉

以下圖所示

從上圖上看,reference1,2,3都是gc roots

reference1指向instance1,reference2指向instance4,而且instance4又指向了instance6,reference3則指向了instance2

因此說instance1,2,4,6都具備gc roots可達性,是存活着的對象,不會被垃圾回收器回收掉

而instance3,5則不具有gc roots可達性,是不可用對象,將會被垃圾回收器回收掉

從上圖描述"引用計數器"的圖例場景來看,TestA和TestB雖然互相有持有引用,可是並不具有gc roots可達性,因此,在"可達性分析"算法下,是會被垃圾回收器回收掉的

垃圾收集的算法

標記-清除算法

算法分爲"標記"和"清除"兩個階段,首先標記出須要回收的對象,在標記完成後,統一回收掉以前被標記的全部對象. 它是最基礎的收集算法 . 後續的收集算法都是基於這種思想,而且對其缺點進行改進而產生的

主要缺點:

效率問題 : 須要標記和清除兩次掃描
空間問題 : 標記和清除以後會產生大量的不連續的內存碎片,可能會致使,當程序須要分配一個較大內存空間的時候,沒法找到足夠的連續內存,從而不得不提早出發另一次垃圾回收動做

複製算法

將可用內存按容量劃分爲兩塊,每次只使用其中的一塊,當內存使用完了後,就將還存活着的對象複製到另一塊上面,而後在把前面一塊內存一次性清理掉

優勢 :

每次只操做一塊內存,分配內存的時候無需考慮內存碎片的狀況,只須要移動對象的指針,按順序分配內存便可,實現簡單,運行高效

缺點 :

會將內存縮小爲原來的一半
持續複製長生期的對象則致使效率下降 (沒理解) (對於存活率較高的對象,就會對其進行屢次複製,從而致使效率下降)

標記-壓縮算法

和標記-清除算法同樣,只不過標記後的動做不是清除,而是將全部對象向一端移動,而後直接清理掉邊界之外的對象(被標記的對象)

特色 :

複製算法比較適合於新生代，在老年代中，對象存活率比較高，若是執行較多的複製操做，效率將會變低，因此老年代通常會選用其餘算法，如標記—清理算法
該算法標記的過程與標記—清除算法中的標記過程同樣，但對標記後出的垃圾對象的處理狀況有所不一樣，它不是直接對可回收對象進行清理，而是讓全部的對象都向一端移動，而後直接清理掉端邊界之外的內存

分代收集算法

把java的堆分爲"新生代"和"老年代",對於不一樣的年代採用不一樣算法

在新生代中,因爲對象生命週期很是短暫,因此每次垃圾回收的時候都會有大量的對象死去,只有少許存活,這樣,採用"複製算法",就只須要付出少許存活對象的複製成本,就能完成回收

在老年代中,因爲對象生命週期比較長,存活率較高,沒有額外的空間對它進行分配和擔保,那就必須使用"標記-清除算法"或者"標記-壓縮算法"來進行回收

Minor GC: 從年輕代空間(包括Eden和Survivor區域)回收內存被稱爲Minor GC

Major GC: 清理老年代

Full GC: 清理整個堆空間—包括年輕代和老年代

年輕代: 是全部新對象產生的地方.年輕代被分爲3個部分(Enden區和兩個Survivor區,也叫From和To),當Eden區被對象填滿時,就會執行Minor GC,並把全部存活下來的對象轉移到其中一個survivor區(Form),Minor GC一樣會檢查存活下來的對象,並把它們轉移到另外一個survivor區(To),這樣在一段時間內,總會有一個空的survivor區,通過屢次GC週期後，仍然存活下來的對象會被轉移到年老代內存空間,常這是在年輕代有資格提高到年老代前經過設定年齡閾值來完成的,須要注意，Survivor的兩個區是對稱的,沒前後關係,from和to是相對的.

老年代: 在年輕代中經歷了N次回收後仍然沒有被清除的對象,就會被放到年老代中,都是生命週期較長的對象.對於年老代,則會執行Major GC,來清理.在某些狀況下,則會觸發Full GC,來清理整個堆內存

元空間: 堆外的一部份內存,一般直接使用的是系統內存,用於存放運行時常量池,等內容,垃圾回收對應元空間來講沒有明顯的影響

垃圾收集器

垃圾收集器是內存回收算法的具體實現，Java虛擬機規範中對垃圾收集器應該如何實現並無任何規定，所以不一樣廠商、不一樣版本的虛擬機所提供的垃圾收集器均可能會有很大的差異

Sun HotSpot虛擬機1.6版包含了以下收集器：Serial、ParNew、Parallel Scavenge、CMS、Serial Old、Parallel Old

這些收集器以不一樣的組合形式配合工做來完成不一樣分代區的垃圾收集工做,以下是垃圾收集器簡單介紹 :

Serial收集器

串行收集器,最古老,最穩定,以及效率高的收集器,可是可能會形成程序較長時間的停頓,只使用一個線程去回收.新生代,老年代使用串行回收

新生代使用"複製算法"

老年代使用"標記壓縮算法"

垃圾回收的過程當中會"程序暫停"(Stop the world)

ParNew收集器

是Serial收集器的多線程版,新生代並行,老年代串行

新生代使用"複製算法"

老年代使用"標記壓縮算法"

垃圾回收的過程當中會"程序暫停"(Stop the world)

Paralle收集器

相似於ParNew收集器,可是更關注系統的吞吐量.

能夠經過參數來打開"自適應調節策略",虛擬機會根據系統當前的運行狀況收集性能監控信息,動態調整這些參數以便提供最合適的停頓時間和最大的吞吐量

也能夠經過參數控制GC的時間不大於多少毫秒或者比例

新生代使用"複製算法"

老年代使用"標記壓縮算法"

Parallel Old收集器

是Paralle收集器的老年代版本 , 使用多線程和"標記-整理算法",這個收集器在JDK1.6中才開始使用

CMS收集器

是基於"標記-清除"算法實現的,它的運做過程相對於前面的其中收集器要複雜一些,整個過程分爲4個步驟,包括 :

初始標記(CMS initial mark)
併發標記(CMS concurrent mark)
從新標記(CMS remark)
併發清除(CMS concurrent sweep)

初始標記和併發標記仍須要Stop the World.

初始標記僅僅只是標記一下GC Root能直接關聯到的對象,速度很快.

併發標記階段就是進行GC Root Tracing的過程.

從新標記這是爲了修正併發標記期間,因用戶程序繼續運做而致使標記變更的那一部分的標記記錄,這一階段的停頓時間會比初始標記階段的時間稍長一些,但遠比並發標記時間短

整個過程當中耗時最長的併發標記和併發清除過程當中,收集器線程能夠與用戶線程一塊兒工做,因此整體來講,CMS收集器的內存回收是與用戶線程一塊兒併發執行的

優勢 : 併發收集,低停頓

缺點 : 產生大量的空間碎片,併發階段會下降吞吐量

G1收集器

與CMS收集器項目,G1收集器有如下特色 :

空間整合 :
- G1收集器採用標記-整理算法,不會產生空間碎片.分配大對象時不會應爲找不到連續的空間而提早觸發下一次GC
可預測停頓 :
- 下降停頓時間是G1和CMS的共同關注點
- G1除了追求低停頓外,還能創建可預測的停頓時間模型.
- 能讓使用者明確指定在一個長度爲N毫秒的時間片斷內,消耗在垃圾收集上的時間不得超過N毫秒,幾乎已是實時java(RTSJ)垃圾回收的特徵了

上面提到的垃圾收集器,收集的範圍都是整個新生代或者老年代,而G1不在是這樣.

使用G1收集器的時候,JAVA堆的內存佈局與其餘的收集器有很大的差異,它將這個java堆劃分爲多個大小相等的獨立區域(Region),雖然還保留新生代和老年代的概念,但新生代和老年代再也不是物理隔閡了,他們都是一部分(能夠不連續)Region的集合

G1的新生代收集器跟ParNew相似,當新生代佔用達到必定的比例的時候,開始觸發收集

和CMS相似,G1收集器收集老年代對象的時候會有短暫停頓

收集步驟以下 :

標記階段 :
- 首先初始標記(initial mark),這個階段是停頓的(Stop the world event),而且會觸發一次普通的Mintor GC(從年輕代空間回收)
Root Region Scanning :
- 運行程序過程當中會回收survivor區(存活到老年代),這一過程必須在young GC以前完成
Concurrent Marking :
- 在整個java堆中進行併發標記(和應用程序併發執行),此過程可能會被young GC中斷
- 若發現區域對象中的全部對象都是垃圾,那個區域就會被當即回收
- 同時,併發標記過程當中,會去計算每一個區域的對象活性(區域中存活對象的比例)
Remark :
- 再標記,會有短暫停頓(STW)
- 是用來收集併發標記階段,產生新的垃圾(併發階段和應用程序一同執行)
- G1中採用了比CMS更快的初始快照算法 : snapshot-at-the-beginning (SATB)
Copy / Clean up :
- 多線程清除失活對象,會有STW
- G1將回收區域的存活對象拷貝到新的區域,清除Remember Sets,併發清空回收區域,並把它返回到空閒的區域鏈表中
複製/清除過程後 :
- 回收區域的活性對象已經被收集器回收到"最近複製的年輕代"(recently copied in young generation)和"最近複製的老年代"(recently copied in old generation)區域中了