深入理解JVM(三)——垃圾收集策略詳解

http://blog.csdn.NET/u010425776/article/details/51189318


Java虛擬機的內存模型分爲五個部分,分別是:程序計數器、Java虛擬機棧、本地方法棧、堆、方法區。

這五個區域既然是存儲空間,那麼爲了避免Java虛擬機在運行期間內存存滿的情況,就必須得有一個垃圾收集者的角色,不定期地回收一些無效內存,以保障Java虛擬機能夠健康地持續運行。

這個垃圾收集者就是平常我們所說的“垃圾收集器”,那麼垃圾收集器在何時清掃內存?清掃哪些數據?這就是接下來我們要解決的問題。 

程序計數器、Java虛擬機棧、本地方法棧都是線程私有的,也就是每條線程都擁有這三塊區域,而且會隨着線程的創建而創建,線程的結束而銷燬。那麼,垃圾收集器在何時清掃這三塊區域的問題就解決了。

此外,Java虛擬機棧、本地方法棧中的棧幀會隨着方法的開始而入棧,方法的結束而出棧,並且每個棧幀中的本地變量表都是在類被加載的時候就確定的。因此以上三個區域的垃圾收集工作具有確定性,垃圾收集器能夠清楚地知道何時清掃這三塊區域中的哪些數據。

然而,堆和方法區中的內存清理工作就沒那麼容易了。 
堆和方法區所有線程共享,並且都在JVM啓動時創建,一直得運行到JVM停止時。因此它們沒辦法根據線程的創建而創建、線程的結束而釋放。

堆中存放JVM運行期間的所有對象,雖然每個對象的內存大小在加載該對象所屬類的時候就確定了,但究竟創建多少個對象只有在程序運行期間才能確定。 
方法區中存放類信息、靜態成員變量、常量。類的加載是在程序運行過程中,當需要創建這個類的對象時纔會加載這個類。因此,JVM究竟要加載多少個類也需要在程序運行期間確定。 
因此,堆和方法區的內存回收具有不確定性,因此垃圾收集器在回收堆和方法區內存的時候花了一些心思。 

堆內存的回收

1. 如何判定哪些對象需要回收?

在對堆進行對象回收之前,首先要判斷哪些是無效對象。我們知道,一個對象不被任何對象或變量引用,那麼就是無效對象,需要被回收。一般有兩種判別方式:

  • 引用計數法 
    每個對象都有一個計數器,當這個對象被一個變量或另一個對象引用一次,該計數器加一;若該引用失效則計數器減一。當計數器爲0時,就認爲該對象是無效對象。

  • 可達性分析法 
    所有和GC Roots直接或間接關聯的對象都是有效對象,和GC Roots沒有關聯的對象就是無效對象。 
    GC Roots是指:

    1. Java虛擬機棧所引用的對象(棧幀中局部變量表中引用類型的變量所引用的對象)
    2. 方法區中靜態屬性引用的對象
    3. 方法區中常量所引用的對象
    4. 本地方法棧所引用的對象 
      PS:注意!GC Roots並不包括堆中對象所引用的對象!這樣就不會出現循環引用。

兩者對比: 
引用計數法雖然簡單,但存在一個嚴重的問題,它無法解決循環引用的問題。 
因此,目前主流語言均使用可達性分析方法來判斷對象是否有效。


2. 回收無效對象的過程

當JVM篩選出失效的對象之後,並不是立即清除,而是再給對象一次重生的機會,具體過程如下:

  1. 判斷該對象是否覆蓋了finalize()方法

    • 若已覆蓋該方法,並該對象的finalize()方法還沒有被執行過,那麼就會將finalize()扔到F-Queue隊列中;
    • 若未覆蓋該方法,則直接釋放對象內存。
  2. 執行F-Queue隊列中的finalize()方法 
    虛擬機會以較低的優先級執行這些finalize()方法們,也不會確保所有的finalize()方法都會執行結束。如果finalize()方法中出現耗時操作,虛擬機就直接停止執行,將該對象清除。

  3. 對象重生或死亡 
    如果在執行finalize()方法時,將this賦給了某一個引用,那麼該對象就重生了。如果沒有,那麼就會被垃圾收集器清除。

注意: 
強烈不建議使用finalize()函數進行任何操作!如果需要釋放資源,請使用try-finally。 
因爲finalize()不確定性大,開銷大,無法保證順利執行。


方法區的內存回收

我們知道,如果使用複製算法實現堆的內存回收,堆就會被分爲新生代和老年代,新生代中的對象“朝生夕死”,每次垃圾回收都會清除掉大量的對象;而老年代中的對象生命較長,每次垃圾回收只有少量的對象被清除掉。

由於方法區中存放生命週期較長的類信息、常量、靜態變量,因此方法區就像是堆的老年代,每次垃圾收集的只有少量的垃圾被清除掉。

方法區中主要清除兩種垃圾: 
1. 廢棄常量 
2. 廢棄的類


1. 如何判定廢棄常量?

清除廢棄的常量和清除對象類似,只要常量池中的常量不被任何變量或對象引用,那麼這些常量就會被清除掉。


2. 如何廢棄廢棄的類?

清除廢棄類的條件較爲苛刻: 
1. 該類的所有對象都已被清除 
2. 該類的java.lang.Class對象沒有被任何對象或變量引用 
只要一個類被虛擬機加載進方法區,那麼在堆中就會有一個代表該類的對象:java.lang.Class。這個對象在類被加載進方法區的時候創建,在方法區中該類被刪除時清除。 
3. 加載該類的ClassLoader已經被回收


垃圾收集算法

現在我們知道了判定一個對象是無效對象、判定一個類是廢棄類、判定一個常量是廢棄常量的方法,也就是知道了垃圾收集器會清除哪些數據,那麼接下來介紹如何清除這些數據。


1. 標記-清除算法

首先利用剛纔介紹的方法判斷需要清除哪些數據,並給它們做上標記;然後清除被標記的數據。

分析: 
這種算法標記和清除過程效率都很低,而且清除完後存在大量碎片空間,導致無法存儲大對象,降低了空間利用率。


2. 複製算法

將內存分成兩份,只將數據存儲在其中一塊上。當需要回收垃圾時,也是首先標記出廢棄的數據,然後將有用的數據複製到另一塊內存上,最後將第一塊內存全部清除。

分析: 
這種算法避免了碎片空間,但內存被縮小了一半。 
而且每次都需要將有用的數據全部複製到另一片內存上去,效率不高。

解決空間利用率問題: 
在新生代中,由於大量的對象都是“朝生夕死”,也就是一次垃圾收集後只有少量對象存活,因此我們可以將內存劃分成三塊:Eden、Survior1、Survior2,內存大小分別是8:1:1。分配內存時,只使用Eden和一塊Survior1。當發現Eden+Survior1的內存即將滿時,JVM會發起一次MinorGC,清除掉廢棄的對象,並將所有存活下來的對象複製到另一塊Survior2中。那麼,接下來就使用Survior2+Eden進行內存分配。

通過這種方式,只需要浪費10%的內存空間即可實現帶有壓縮功能的垃圾收集方法,避免了內存碎片的問題。

但是,當一個對象要申請內存空間時,發現Eden+Survior中剩下的空間無法放置該對象,此時需要進行Minor GC,如果MinorGC過後空閒出來的內存空間仍然無法放置該對象,那麼此時就需要將對象轉移到老年代中,這種方式叫做“分配擔保”。


什麼是分配擔保? 
當JVM準備爲一個對象分配內存空間時,發現此時Eden+Survior中空閒的區域無法裝下該對象,那麼就會觸發MinorGC,對該區域的廢棄對象進行回收。但如果MinorGC過後只有少量對象被回收,仍然無法裝下新對象,那麼此時需要將Eden+Survior中的所有對象都轉移到老年代中,然後再將新對象存入Eden區。這個過程就是“分配擔保”。


3. 標記-整理算法

在回收垃圾前,首先將所有廢棄的對象做上標記,然後將所有未被標記的對象移到一邊,最後清空另一邊區域即可。

分析: 
它是一種老年代的垃圾收集算法。老年代中的對象一般壽命比較長,因此每次垃圾回收會有大量對象存活,因此如果選用“複製”算法,每次需要複製大量存活的對象,會導致效率很低。而且,在新生代中使用“複製”算法,當Eden+Survior中都裝不下某個對象時,可以使用老年代的內存進行“分配擔保”,而如果在老年代使用該算法,那麼在老年代中如果出現Eden+Survior裝不下某個對象時,沒有其他區域給他作分配擔保。因此,老年代中一般使用“標記-整理”算法。


4. 分代收集算法

將內存劃分爲老年代和新生代。老年代中存放壽命較長的對象,新生代中存放“朝生夕死”的對象。然後在不同的區域使用不同的垃圾收集算法。


Java中引用的種類

Java中根據生命週期的長短,將引用分爲4類。

1. 強引用

我們平時所使用的引用就是強引用。 
A a = new A(); 
也就是通過關鍵字new創建的對象所關聯的引用就是強引用。 
只要強引用存在,該對象永遠也不會被回收。 

2. 軟引用

只有當堆即將發生OOM異常時,JVM纔會回收軟引用所指向的對象。 
軟引用通過SoftReference類實現。 
軟引用的生命週期比強引用短一些。 

3. 弱引用

只要垃圾收集器運行,軟引用所指向的對象就會被回收。 
弱引用通過WeakReference類實現。 
弱引用的生命週期比軟引用短。 

4. 虛引用

虛引用也叫幽靈引用,它和沒有引用沒有區別,無法通過虛引用訪問對象的任何屬性或函數。 
一個對象關聯虛引用唯一的作用就是在該對象被垃圾收集器回收之前會受到一條系統通知。 
虛引用通過PhantomReference類來實現。

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