淺談java垃圾回收機制


一、問題

  筆者最近遇到超級多的關於java中垃圾回收機制的問題,所以特地寫一遍博客來和大家交流一下java中的垃圾回收到底是什么鬼。所謂垃圾回收即使jvm覺得你這個對象沒有存在的必要,將你清理出去,那么問題來了。

  1. 如何確定某個對象是需要被回收?
  2. 典型的垃圾收集算法,是怎么回收對象的?
  3. 典型的垃圾收集器有哪些?

  下面我來一個一個看問題

二、如何確定某個對象是需要被回收的

  這里我們先了解一個的問題:如果確定某個對象是“垃圾”?既然垃圾收集器的任務是回收垃圾對象所占的空間供新的對象使用,那么垃圾收集器如何確定某個對象是“垃圾”?—即通過什么方法判斷一個對象可以被回收了。有些對象是jvm內存不足需要清理內存空間,會將下一輪需要回收的對象進行清理。

  在java中是通過引用來和對象進行關聯的,也就是說如果要操作對象,必須通過引用來進行。那么很顯然一個簡單的辦法就是通過引用計數來判斷一個對象是否可以被回收。不失一般性,如果一個對象沒有任何引用與之關聯,則說明該對象基本不太可能在其他地方被使用到,那么這個對象就成為可被回收的對象了。這種方式成為引用計數法。

  這樣的方法簡單粗暴,而且效率很高。效率高必然會暴露一些問題,如果某些對象唄循環引用,即使你把對象賦值為null,這種算法照樣不能回收。看下下面的代碼

public class GcTest {

    public Object object = null;
    
    public static void main(String[] args) {
        
        GcTest gcTest1 = new GcTest();
        GcTest gcTest2 = new GcTest();
        
        gcTest1.object = gcTest1;
        gcTest2.object = gcTest2;
        
        gcTest1 = null;
        gcTest2 = null;
    }
}

 

  雖然gcTest1,gcTest2是null,他們指向的對象已經不會被訪問到了,但是由於它們互相引用對方,導致它們的引用計數都不為0,那么垃圾收集器就永遠不會回收它們。

  上面的問題已經暴露出來了,下面看看jvm是怎么解決這個問題的。為了解決這個問題,在Java中采取了可達性分析法。該方法的基本思想是通過一系列的“GC Roots”對象作為起點進行搜索,如果在“GC Roots”和一個對象之間沒有可達路徑,則稱該對象是不可達的,不過要注意的是被判定為不可達的對象不一定就會成為可回收對象。被判定為不可達的對象要成為可回收對象必須至少經歷兩次標記過程,如果在這兩次標記過程中仍然沒有逃脫成為可回收對象的可能性,則基本上就真的成為可回收對象了。在《深入理解jvm》講解的很仔細,筆者就簡單介紹下GC Roots的概念,想深入了解的可以去讀下筆者介紹的這本書。

  以下三類對象在jvm中作為GC roots,來判斷一個對象是否可以被回收 (通常來說我們只要知道虛擬機棧和靜態引用就夠了)

   1、虛擬機棧(JVM stack)中引用的對象(准確的說是虛擬機棧中的棧幀(frames)) 。我們知道,每個方法執行的時候,jvm都會創建一個相應的棧幀(棧幀中包括操作數棧、局部變量表、運行時常量池的引用),棧幀中包含這在方法內部使用的所有對象的引用(當然還有其他的基本類型數據),當方法執行完后,該棧幀會從虛擬機棧中彈出,這樣一來,臨時創建的對象的引用也就不存在了,或者說沒有任何gc roots指向這些臨時對象,這些對象在下一次GC時便會被回收掉

  2、方法區中類靜態屬性引用的對象 。靜態屬性是該類型(class)的屬性,不單獨屬於任何實例,因此該屬性自然會作為gc roots。只要這個class存在,該引用指向的對象也會一直存在。class 也是會被回收的,在面后說明

   3、本地方法棧(Native Stack)引用的對象

   下面介紹下關於軟引用(softReference)和弱引用(weakReference)的對象垃圾回收對他們做的處理

String str = new String("hello");//A
SoftReference<String> sr = new SoftReference<String>(new String("java"));//B
WeakReference<String> wr = new WeakReference<String>(new String("world"));//C

   上面的幾個對象中回收情況如下,B在內存不足的情況下會將String對象判定為可回收對象,C無論什么情況下String對象都會被判定為可回收對象。也就是說軟引用會在內存溢出(OOM)的時候回收,而弱引用無論什么情況都會在下一輪回收的時候回收掉。

  一般jvm會對這些對象回收

  1、顯示地將某個引用賦值為null或者將已經指向某個對象的引用指向新的對象。

  2、局部引用所指向的對象。

  3、上面說的弱引用(weakReference)。

三、垃圾收集算法

  在確定了哪些垃圾可以被回收后,垃圾收集器要做的事情就是開始進行垃圾回收,但是這里面涉及到一個問題是:如何高效地進行垃圾回收。由於Java虛擬機規范並沒有對如何實現垃圾收集器做出明確的規定,因此各個廠商的虛擬機可以采用不同的方式來實現垃圾收集器,就以最常用的HotShot為例,所以在此只討論幾種常見的垃圾收集算法的核心思想。

1、Mark-Sweep(標記-清除)算法

  這是最基礎的垃圾回收算法,之所以說它是最基礎的是因為它最容易實現,思想也是最簡單的。標記-清除算法分為兩個階段:標記階段和清除階段。標記階段的任務是標記出所有需要被回收的對象,清除階段就是回收被標記的對象所占用的空間。圖解來自網絡,很好的說明了標記-清楚算法的處理前和處理后的內存分布。

下面所有的圖是模擬內存塊,紅色為未使用內存塊,灰色為待回收對象內存塊,黃色為存活對象

回收之前

回收之后

  很容易看出這樣的操作是有弊端的,這樣講標記的對象的清楚后,內存塊就變的零零散散,如果現在有一個對象占用的內存很大,這個時候必須要在執行一遍垃圾回收,為這個大的對象騰出空間。

2、Copying(復制)算法

  為了解決Mark-Sweep算法的缺陷,Copying算法就被提了出來。它將可用內存按容量划分為大小相等的兩塊,每次只使用其中的一塊。當這一塊的內存用完了,就將還存活着的對象復制到另外一塊上面,然后再把已使用的內存空間一次清理掉,這樣一來就不容易出現內存碎片的問題。

回收之前

回收之后

  復制算法會提前空出一般的內存,在垃圾回收的時候將存活的對象移動的另外一半內存,這樣內存的移動消耗太大,雖然內存不是零散的,但是代價太高。

3、Mark-Compact(標記-整理)算法

  為了解決Copying算法的缺陷,充分利用內存空間,提出了Mark-Compact算法。該算法標記階段和Mark-Sweep一樣,但是在完成標記之后,它不是直接清理可回收對象,而是將存活對象都向一端移動,然后清理掉端邊界以外的內存。具體過程如下圖所示:

回收之前

回收之后

4、Generational Collection(分代收集)算法

  分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根據對象存活的生命周期將內存划分為若干個不同的區域。一般情況下將堆區划分為老年代(Tenured Generation)和新生代(Young Generation),老年代的特點是每次垃圾收集時只有少量對象需要被回收,並不是回收所有,而新生代的特點是每次垃圾回收時都有大量的對象需要被回收,那么就可以根據不同代的特點采取最適合的收集算法。可以調用System.gc()方法查看回收情況。

  目前大部分垃圾收集器對於新生代都采取Copying算法,因為新生代中每次垃圾回收都要回收大部分對象,也就是說需要復制的操作次數較少,但是實際中並不是按照1:1的比例來划分新生代的空間的,一般來說是將新生代划分為一塊較大的Eden空間和兩塊較小的Survivor空間,每次使用Eden空間和其中的一塊Survivor空間,當進行回收時,將Eden和Survivor中還存活的對象復制到另一塊Survivor空間中,然后清理掉Eden和剛才使用過的Survivor空間。

  而由於老年代的特點是每次回收都只回收少量對象,一般使用的是Mark-Compact算法。

  注意,在堆區之外還有一個代就是永久代(Permanet Generation),它用來存儲class類、常量、方法描述等。對永久代的回收主要回收兩部分內容:廢棄常量和無用的類。

三、典型的垃圾收集器

  下面都是些概率性的東西,筆者看得也似懂非懂,直接搬過來分享給大家

1.Serial/Serial Old

  Serial/Serial Old收集器是最基本最古老的收集器,它是一個單線程收集器,並且在它進行垃圾收集時,必須暫停所有用戶線程。Serial收集器是針對新生代的收集器,采用的是Copying算法,Serial Old收集器是針對老年代的收集器,采用的是Mark-Compact算法。它的優點是實現簡單高效,但是缺點是會給用戶帶來停頓。

2.ParNew

  ParNew收集器是Serial收集器的多線程版本,使用多個線程進行垃圾收集。

3.Parallel Scavenge

  Parallel Scavenge收集器是一個新生代的多線程收集器(並行收集器),它在回收期間不需要暫停其他用戶線程,其采用的是Copying算法,該收集器與前兩個收集器有所不同,它主要是為了達到一個可控的吞吐量。

4.Parallel Old

  Parallel Old是Parallel Scavenge收集器的老年代版本(並行收集器),使用多線程和Mark-Compact算法。

5.CMS

  CMS(Current Mark Sweep)收集器是一種以獲取最短回收停頓時間為目標的收集器,它是一種並發收集器,采用的是Mark-Sweep算法。

6.G1

  G1收集器是當今收集器技術發展最前沿的成果,它是一款面向服務端應用的收集器,它能充分利用多CPU、多核環境。因此它是一款並行與並發收集器,並且它能建立可預測的停頓時間模型。

四、總結和補充

  對象的內存分配,往大方向上講就是在堆上分配,對象主要分配在新生代的Eden Space和From Space,少數情況下會直接分配在老年代。如果新生代的Eden Space和From Space的空間不足,則會發起一次GC,如果進行了GC之后,Eden Space和From Space能夠容納該對象就放在Eden Space和From Space。在GC的過程中,會將Eden Space和From  Space中的存活對象移動到To Space,然后將Eden Space和From Space進行清理。如果在清理的過程中,To Space無法足夠來存儲某個對象,就會將該對象移動到老年代中。在進行了GC之后,使用的便是Eden space和To Space了,下次GC時會將存活對象復制到From Space,如此反復循環。當對象在Survivor區躲過一次GC的話,其對象年齡便會加1,默認情況下,如果對象年齡達到15歲,就會移動到老年代中。

  一般來說,大對象會被直接分配到老年代,所謂的大對象是指需要大量連續存儲空間的對象,最常見的一種大對象就是大數組,比如:

  byte[] data = new byte[4*1024*1024]

  這種一般會直接在老年代分配存儲空間。

  當然分配的規則並不是百分之百固定的,這要取決於當前使用的是哪種垃圾收集器組合和JVM的相關參數。

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM