參考書籍《深入理解java虛擬機器器》周志明著
本文主要介紹垃圾回收理論知識
虛擬機器器棧,本地方法棧,程式計數器都是執行緒私有的,隨執行緒而生,隨執行緒而滅
。其中棧中的棧幀隨著方法的進入和退出而有條不紊的執行出棧和入棧操作,每一個棧幀需要分配記憶體基本上在類結構確定下來的時候就已知了,因此這幾個區域的記憶體分配時具備確定性的,這個幾個區域不需要考慮如何回收,當方法或者執行緒結束的時候,這些區域自然隨之被回收。
堆
堆是儲存物件的為止,執行緒共用。程式設計師在方法中new一個物件,通常在這個棧幀中的本地變數存在一個reference型別指向堆中一個物件範例資料。這部分是垃圾回收的重災,畢竟java中萬物皆物件
方法區
在方法區中,儲存了每個類的資訊(包括類的名稱、方法資訊、欄位資訊)、靜態變數、常數以及編譯器編譯後的程式碼等。java可以使用動態代理生成類,可以在執行的時候載入類到方法區。
java 8 使用元空間實現方法區,我們可以使用MaxMetaspaceSize
這個虛擬機器器引數現在元空間大小,對於不會再使用的類,和類載入器以及廢棄的常數可以進行回收。
這部分下面會進行著重介紹,首先我們要判斷一個物件是否為垃圾,然後使用特定演演算法進行垃圾收集
回收常數
如果一個常數曾經進入到方法區,但是後續再也沒用被參照到,那麼垃圾收集器覺得合適的時候將進行清理
回收類
回收類的條件十分苛刻,首先必須保證該類的範例物件都以及被回收
,其次保證載入類的類載入器也已經被回收
,該類對應的Class物件沒有在任何位置被參照,無法在任何位置通過反射存取該類的方法
。
正因如此,回收方法區價效比很低,以下是一些控制方法區垃圾回收的虛擬機器器引數
引數 | 含義 |
---|---|
-Xnoclassgc | 是否對型別進行回收 |
-XX:TraceClassLoading | 列印類載入資訊 |
-XX:TraceClassUnLoading | 列印類解除安裝資訊 |
-verbose:class | 列印類載入和解除安裝資訊 |
大量使用反射,動態代理,CGLib位元組碼框架,動態生成jsp等技術,通常需要java虛擬機器器具備型別解除安裝的能力。避免方法區的溢位(jdk7之前,可以使用-XX:MaxPermSize設定方法區大小,-XX:PermSize設定方法區初始大小,方法區溢位通常紀錄檔資訊為java.lang.OutOfMemoryError:PermGen pace
。jdk7之後方法區使用基於本地記憶體的元空間實現可以使用-XX:MaxMetaspaceSize設定元空間最大值,-XX:MetaSpaceSize指定元空間初始大小,-XX:MinMetaSpaceFreeRatio設定在垃圾收集後控制元空間最小剩餘百分比,-XX:MaxMetaSpaceFreeRatio 設定在垃圾收集後控制元空間最大小剩餘百分比)
不會被使用到的物件就是垃圾,那麼使用什麼方法定位到不會被使用到的物件呢?
在物件中新增一個參照計數器,每當一個物件參照了它,計數器的值就加1,當參照失效時就減1,任何時候參照計數器為0的物件就是不可以再使用的。
參照計數器法佔用少許額外記憶體,但是原理簡單,判定效率也很高,大多數情況下都是一個不錯的選擇,但是存在迴圈參照的問題,物件A參照了物件B,物件B參照了物件A,二者不再被其他物件參照,這時候二者計數器都為1,但是已然是垃圾
A a = new A();
B b = new B()
a.f1 = b;
b.f2 = a;
a = null;
b = null;
//這時候發生GC 物件A 和 物件B互相參照彼此,但是可以被回收
Java虛擬機器器並非使用 參照計數器法 來判斷物件是否存活。
通過一些類稱為GC Roots的根物件為起始節點集合,從這些節點起,根據參照關係向下搜尋,搜尋過程所走過的路徑稱為"參照鏈"
,如果某個物件到GC Roots沒有任何參照鏈相連,即GC Roots到這個物件不可達,那麼證明此物件不能再被使用。
可以作為GC Roots的物件有以下這些:
強參照
指程式碼間的參照賦值,Object a = new Object()
,這種關係,只要存在強參照關係,那麼垃圾回收器就無法回收被參照的物件
軟參照
使用SoftReference類實現的參照關係,只被軟參照關聯的物件在,在系統將發生記憶體溢位異常前,會將這些物件列入垃圾回收的範圍進行第二次回收,如果回收後還沒有足夠的記憶體,才會丟擲記憶體溢位異常。下面這個程式碼不斷向集合中加入物件,但是不會發生OOM。另外配合ReferenceQueue
可以實現基於軟參照的快取,在mybatis中的SoftCache
存在類似的使用
public static void main(String[] args) {
ArrayList<Object> objects = new ArrayList<>();
while (true) {
objects.add(new SoftReference<>(new byte[1024*1024],q));
}
}
弱參照
用來描述非必須的物件,使用WeakReference實現這種關係,它的強度比軟參照更弱一些,關聯的物件只能生存到下一次垃圾收集為止,當垃圾收集器開始工作,無論記憶體是否足夠,都會回收只被弱參照關聯的物件。
同樣配合ReferenceQueue 可以實現弱參照快取,在WeakHashMap,mybatis中的WeakCache
,guava的快取中均有類似使用
虛參照
使用PhantomReference實現這種參照關係,是最弱的一種關係,虛參照的存在絲毫不影響物件的回收,也無法根據虛參照來獲取一個物件範例,為物件設定虛參照的唯一目的就是能在物件被回收的時候收到一個系統通知(搭配ReferenceQueue實現)
一個物件確保需要回收,需要進行兩次篩選
待物件執行完finalize方法
,後對F-Queue中物件進行第二次篩選,依舊和GC Roots無聯絡的物件將被回收經歷第一次篩選後,如果物件沒有必要執行finalize方法(物件沒有覆蓋finalize方法,或者該物件的finalize方法已經被虛擬機器器呼叫過
)那麼不會將物件放置在F-Queue。被放置到F-Queue佇列中的物件,稍後有虛擬機器器自動建立的,低優先順序的Finalizer執行緒去執行finalize方法,但是並不一定保證等待執行完成(因為不能由於物件本身finalize方法執行時間長,而導致垃圾不能及時回收造成oom),稍後收集器將對F-Queue中的物件進行第二次小規模標記,如果任然沒有和GC Roots建立聯絡,那麼將被回收。(finalize方法只會被呼叫一次)
大部分垃圾收集器都是使用分代收集的策略實現堆的垃圾回收。
為什麼需要分代
分代存在兩個重要的假說促使了,垃圾收集器進行分代收集。
弱分代假說
大部分物件都是朝生夕滅的
像我們再方法中區域性變數參照的物件,方法結束就會死去,因為再也沒用任何參照可以指向它了。如:
void m(){
Object o = new Object();
}
//這裡的o m方法結束,new出的object物件將不會被任何參照指向
//這種物件在java這種是佔絕大多數的
強分代假說
熬過越多垃圾收集的物件越是難以消亡
可以熬過多次垃圾收集,說明和GC Roots關聯非常緊密,後續肯定更加難被收集,類似我們定義的 static final
屬性指向的物件
在兩個假說促使收集器將堆劃分出不同的區域,然後根據物件的年齡(年齡指熬過gc的次數)分配到不同的區域儲存。如是便有了新生代和老年代
新生代物件和老年代存亡特徵存在差異,促使這兩部分使用不同的演演算法進行收集(標記清除,標記整理,標記複製,見後續講解)
分代收集也具備缺點——跨代參照,老年代和新生代物件存在關聯。這時候加入只想進行 新生代的gc難道需要掃描所有老年代的物件,確保新生代物件是否存在跨代參照麼?(老年代物件全部遍歷是一個非常耗時的操作)。
為了解決這個問題,提出了第三個假說:跨代參照假說:存在跨代參照的物件相對於同代參照的物件是很少的
。因為如果存在跨代參照的兩個物件往往是趨向一起消亡的,比如老年代參照了新生代,由於老年代物件不容易被回收,促使這個新生代物件也不易被回收,進而新生代物件熬過多次gc最終進入老年代,消除了跨代參照。
根據這個假說,指導了我們不應該為了少量跨代參照物件去掃描所有老年代物件,只需要在新生代建立一個全域性的資料結構:記憶集
,將老年代分為多個小塊,標識哪一塊的老年代記憶體存在跨代參照,當發生新生代gc的時候,將包含跨代參照的小塊記憶體中的物件加入到GC Roots中進行掃描
。使用少量空間減少了掃描整個老年代的開銷。
Minor GC,Major GC,Full GC
Minor GC
新生代收集,針對新生代(又稱young gc)
Major GC
老年代GC,針對老年代(又稱old gc)
Full GC
回收整個堆和方法區
的垃圾收集
演演算法分為標記和清除兩個步驟,十分好理解,首先標記所有需要回收的物件,在標記完成後,統一回收掉被標記的物件。也可以反過來,標記不需要回收的物件,然後回收沒被標記的物件。
標記清除的缺點
效率不穩定
需要被標記的物件越多,標記和回收過程越耗時。
容易造成記憶體碎片
標記清除後容易產生大量記憶體碎片,導致後續執行的時候無法為大物件分配連續記憶體,而被迫再次進行GC。
將可用記憶體分為兩部分,每次只使用其中一部分,當這一部分A被使用完後,標記出存活的物件複製到另外一塊B上面,然後將A全部清理,後續繼續使用B,B使用完後標記B然後將可用物件複製到A上,迴圈往復。由於需要複製的物件是存活的物件,這部分物件根據"弱分代假說"
是較少的部分,每次都是對一半的區域進行回收,所以可避免記憶體碎片的產生。但是缺點也很明顯:"過於浪費空間,每次只能使用一半"
。
java新生代並沒有採用上面的演演算法,而是使用改進後的演演算法:即將新生代分為 一個Eden
和兩個Survivor(from區和to區)
,三者的比值是8:1:1
,發生新生代垃圾收集的時候,將Eden
和Survivor from
中仍然存活的物件,一次性複製到Survivor to,然後清理掉Eden 和 Survivor from
,然後下次使用Eden
和Survivor to
分配記憶體給新物件,然後標記複製,迴圈往復。
這種演演算法的優點是,浪費的空間比較少,只浪費10%的空間,獲得複製然後直接刪除Eden 和一個Survivor記憶體的效率。
缺點是:如果一個Eden和Survivor標記後存活的物件,大於另外一個Survivor空間的小,這時候需要使用逃生門
——當Survivor容納不下一個Minor GC後存活的物件的時候,需要依賴另外的空間(老年代)進行擔保,讓這部分物件直接進行老年代
。
標記複製演演算法,在物件存活率高的時候需要進行較多複製操作,效率將會降低。如果不使用一半使用,一半浪費的傳統標記複製演演算法,那麼需要老年代需要擔保,所以老年代一般不使用這種演演算法(沒人為老年代擔保)。
標記整理演演算法,標記過程和標記清除演演算法一樣,但是後續步驟不是清理所有存活物件,而是讓所有存活物件向記憶體空間的一側進行移動,然後清理邊界外的物件
。
這種演演算法的缺點是:如果存活的物件比較多,需要更新指向這些物件的參照為移動後的地址,這是一個比較耗時的操作,必須停止所有使用者執行緒才能進行——"Stop the world"
。但是如果不進行移動的話,將造成大量記憶體碎片,必須使用更復雜的結構(空閒連結串列)來解決記憶體分配問題。因此存在另外一種和稀泥
的方式——先使用標記清理,然後碎片化程度無法容忍的時候,再使用標記整理收集一次。
對於基於分代收集理論的垃圾回收器,下圖成立。
後面將繼續總結,hotspot虛擬機器器如何實現這些演演算法,以及常見的經典垃圾收集器