?如何判斷對象已“死”

Java堆中存放著幾乎所有的對象實例，垃圾回收器在堆進行垃圾回收前，首先要判斷這些對象那些還存活，那些已經“死去”。判斷對象是否已“死”有如下幾種算法：

1引用計數法

引用計數法描述的算法為：給對象增加一個引用計數器，每當有一個地方引用它時，計數器就+1；當引用失效時，計數器就-1；任何時刻計數器為0的對象就是不能再被使用的，即對象已“死”。

引用計數法實現簡單，判定效率也比較高，在大部分情況下都是一個比較好的算法。比如Python語言就是采用的引用計數法來進行內存管理的。

但是，在主流的JVM中沒有選用引用計數法來管理內存，最主要的原因是引用計數法無法解決對象的循環引用問題。

范例：循環引用問題

/*** JVM參數:-XX:+PrintGC* */ public class Test {public Object instance = null;private static int _1MB = 1024 * 1024;private byte[] bigSize = new byte[2 * _1MB];public static void testGC() {Test test1 = new Test();Test test2 = new Test();test1.instance = test2;test2.instance = test1;test1 = null;test2 = null;// 強制JVM進行垃圾回收System.gc();}public static void main(String[] args) {testGC();} } 程序輸出：[GC (System.gc()) 6092K->856K(125952K), 0.0007504 secs]

從結果可以看出，GC日志包含" 6092K->856K(125952K)"，意味著虛擬機并沒有因為這兩個對象互相引用就不回收他們。即JVM并不使用引用計數法來判斷對象是否存活。

2可達性分析算法

在上面講了，Java并不采用引用計數法來判斷對象是否已“死”，而采用“可達性分析”來判斷對象是否存活（同樣采用此法的還有C#、Lisp-最早的一門采用動態內存分配的語言）。

此算法的核心思想：通過一系列稱為“GC Roots”的對象作為起始點，從這些節點開始向下搜索，搜索走過的路徑稱為“引用鏈”，當一個對象到 GC Roots 沒有任何的引用鏈相連時(從 GC Roots 到這個對象不可達)時，證明此對象不可用。以下圖為例：

對象Object5 —Object7之間雖然彼此還有聯系，但是它們到 GC Roots 是不可達的，因此它們會被判定為可回收對象。

在Java語言中，可作為GC Roots的對象包含以下幾種：

1、虛擬機棧(棧幀中的本地變量表)中引用的對象。

2、方法區中靜態屬性引用的對象

3、方法區中常量引用的對象

4、本地方法棧中(Native方法)引用的對象

在JDK1.2以前，Java中引用的定義很傳統: 如果引用類型的數據中存儲的數值代表的是另一塊內存的起始地址，就稱這塊內存代表著一個引用。這種定義有些狹隘，一個對象在這種定義下只有被引用或者沒有被引用兩種狀態。

我們希望能描述這一類對象: 當內存空間還足夠時，則能保存在內存中；如果內存空間在進行垃圾回收后還是非常緊張，則可以拋棄這些對象。很多系統中的緩存對象都符合這樣的場景。

在JDK1.2之后，Java對引用的概念做了擴充，將引用分為強引用(Strong Reference)、軟引用(Soft Reference)、弱引用(Weak Reference)和虛引用(Phantom Reference)四種，這四種引用的強度依次遞減。

1、強引用: 強引用指的是在程序代碼之中普遍存在的，類似于"Object obj = new Object()"這類的引用，只要強引用還存在，垃圾回收器永遠不會回收掉被引用的對象實例。

2、軟引用: 軟引用是用來描述一些還有用但是不是必須的對象。對于軟引用關聯著的對象，在系統將要發生內存溢出之前，會把這些對象列入回收范圍之中進行第二次回收。如果這次回收還是沒有足夠的內存，才會拋出內存溢出異常。在JDK1.2之后，提供了SoftReference類來實現軟引用。

3、弱引用: 弱引用也是用來描述非必需對象的。但是它的強度要弱于軟引用。被弱引用關聯的對象只能生存到下一次垃圾回收發生之前。當垃圾回收器開始進行工作時，無論當前內容是否夠用，都會回收掉只被弱引用關聯的對象。在JDK1.2之后提供了WeakReference類來實現弱引用。

4、虛引用: 虛引用也被稱為幽靈引用或者幻影引用，它是最弱的一種引用關系。一個對象是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個對象實例。為一個對象設置虛引用的唯一目的就是能在這個對象被收集器回收時收到一個系統通知。在JDK1.2之后，提供了PhantomReference類來實現虛引用。

生存or死亡？

即使在可達性分析算法中不可達的對象，也并非"非死不可"的，這時候他們暫時處在"緩刑"階段。要宣告一個對象的真正死亡，至少要經歷兩次標記過程: 如果對象在進行可達性分析之后發現沒有與GC Roots相連接的引用鏈，那它將會被第一次標記并且進行一次篩選，篩選的條件是此對象是否有必要執行?nalize()方法。當對象沒有覆蓋?nalize()方法或者?nalize()方法已經被JVM調用過，虛擬機會將這兩種情況都視為"沒有必要執行"，此時的對象才是真正"死"的對象。

如果這個對象被判定為有必要執行?nalize()方法，那么這個對象將會被放置在一個叫做F-Queue的隊列之中，并在稍后由一個虛擬機自動建立的、低優先級的Finalizer線程去執行它（這里所說的執行指的是虛擬機會觸發?nalize()方法）。?nalize()方法是對象逃脫死亡的最后一次機會，稍后GC將對F-Queue中的對象進行第二次小規模標記，如果對象在?nalize()中成功拯救自己(只需要重新與引用鏈上的任何一個對象建立起關聯關系即可)，那在第二次標記時它將會被移除出"即將回收"的集合；如果對象這時候還是沒有逃脫，那基本上它就是真的被回收了。

范例：對象自我拯救

public class Test {public static Test test;public void isAlive() {System.out.println("I am alive :)");}@Overrideprotected void finalize() throws Throwable {super.finalize();System.out.println("finalize method executed!");test = this;}public static void main(String[] args)throws Exception {test = new Test();test = null;System.gc();Thread.sleep(500);if (test != null) {test.isAlive();}else {System.out.println("no,I am dead :(");}// 下面代碼與上面完全一致，但是此次自救失敗test = null;System.gc();Thread.sleep(500);if (test != null) {test.isAlive();}else {System.out.println("no,I am dead :(");}} }

從上面代碼示例我們發現，?nalize方法確實被JVM觸發，并且對象在被收集前成功逃脫。

但是從結果上我們發現，兩個完全一樣的代碼片段，結果是一次逃脫成功，一次失敗。這是因為，任何一個對象的?nalize()方法都只會被系統自動調用一次，如果相同的對象在逃脫一次后又面臨一次回收，它的?nalize()方法不會被再次執行，因此第二段代碼的自救行動失敗。

2

回收方法區

方法區(永久代)的垃圾回收主要收集兩部分內容：廢棄常量和無用類。

回收廢棄常量和回收Java堆中的對象十分類似。以常量池中字面量(直接量)的回收為例，假如一個字符串"abc"已經進入了常量池中，但是當前系統沒有任何一個String對象引用常量池中的"abc"常量，也沒有其他地方引用這個字面量，如果此時發生GC并且有必要的話，這個"abc"常量會被系統清理出常量池。常量池中的其他類(接口)、方法、字段的符號引用也與此類似。

判定一個類是否是"無用類"則相對復雜很多。

類需要同時滿足下面三個條件才會被算是"無用的類"

1.該類的所有實例都已經被回收(即在Java堆中不存在任何該類的實例)

2.加載該類的ClassLoader已被回收

3.該類對應的Class對象沒有任何其他地方被引用，無法在任何地方通過反射訪問該類的方法

JVM可以對同時滿足上述3個條件的無用類進行回收，也僅僅是“可以”而不是必然。在大量使用反射、動態代理等場景都需要JVM具備類卸載的功能來防止永久代的溢出。

2

垃圾回收算法

1標記-清除算法

“標記-清除”算法是最基礎的收集算法。算法分為標記和清除兩個階段：首先標記出所有需要回收的對象，在標記完成后統一回收所有被標記的對象(標記過程參見1.2可達性分析)。后續的收集算法都是基于這種思路并對其不足加以改進而已。

“標記-清除”算法的不足主要有兩個：

效率問題：標記和清除這兩個過程的效率都不高

空間問題：標記清除后會產生大量不連續的內存碎片，空間碎片太多可能會導致以后在程序運行中需要分配較大對象時，無法找到足夠連續內存而不得不提前觸發另一次垃圾收集。

2復制算法(新生代回收算法)

“復制”算法是為了解決“標記-清除”的效率問題。它將可用內存按容量劃分為大小相等的兩塊，每次只使用其中一塊。當這塊內存需要進行垃圾回收時，會將此區域還存活著的對象復制到另一塊上面，然后再把已經使用過的內存區域一次清理掉。這樣做的好處是每次都是對整個半區進行內存回收，內存分配時也就不需要考慮內存碎片等的復雜情況，只需要移動堆頂指針，按順序分配即可。此算法實現簡單，運行高效。算法的執行流程如下圖：

現在的商用虛擬機(包括HotSpot)都是采用這種收集算法來回收新生代

新生代中98%的對象都是"朝生夕死"的，所以并不需要按照1 : 1的比例來劃分內存空間，而是將內存(新生代內存)分為一塊較大的Eden(伊甸園)空間和兩塊較小的Survivor(幸存者)空間，每次使用Eden和其中一塊Survivor（兩個Survivor區域一個稱為From區，另一個稱為To區域）。當回收時，將Eden和Survivor中還存活的對象一次性復制到另一塊Survivor空間上，最后清理掉Eden和剛才用過的Survivor空間。

當Survivor空間不夠用時，需要依賴其他內存(老年代)進行分配擔保。

HotSpot默認Eden與Survivor的大小比例是8 : 1，也就是說Eden:Survivor From : Survivor To = 8:1:1。所以每次新生代可用內存空間為整個新生代容量的90%,而剩下的10%用來存放回收后存活的對象。

HotSpot實現的復制算法流程如下：

1、當Eden區滿的時候，會觸發第一次Minor gc，把還活著的對象拷貝到Survivor From區；當Eden區再次出發Minor gc的時候，會掃描Eden區和From區，對兩個區域進行垃圾回收，經過這次回收后還存活的對象，則直接復制到To區域，并將Eden區和From區清空。

2、當后續Eden區又發生Minor gc的時候，會對Eden區和To區進行垃圾回收，存活的對象復制到From區，并將Eden區和To區清空

3、部分對象會在From區域和To區域中復制來復制去，如此交換15次(由JVM參數MaxTenuringThreshold決定，這個參數默認是15)，最終如果還存活，就存入老年代。

3標記整理算法(老年代回收算法)

復制收集算法在對象存活率較高時會進行比較多的復制操作，效率會變低。因此在老年代一般不能使用復制算法。

針對老年代的特點，提出了一種稱之為“標記-整理算法”。標記過程仍與“標記-清除”過程一致，但后續步驟不是直接對可回收對象進行清理，而是讓所有存活對象向一端移動，然后直接清理掉端邊界以外的內存。流程圖如下：

4分代收集算法

當前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，這個算法并沒有新思想，只是根據對象存活周期的不同將內存劃分為幾塊。

一般是把Java堆分為新生代和老年代。在新生代中，每次垃圾回收都有大批對象死去，只有少量存活，因此我們采用復制算法；而老年代中對象存活率高、沒有額外空間對它進行分配擔保，就必須采用"標記-清理"或者"標記-整理"算法。

面試題: 請問了解Minor GC和Full GC么，這兩種GC有什么不一樣嗎？

Minor GC又稱為新生代GC : 指的是發生在新生代的垃圾收集。因為Java對象大多都具備朝生夕滅的特性，因此Minor GC(采用復制算法)非常頻繁，一般回收速度也比較快。

Full GC 又稱為老年代GC或者Major GC : 指發生在老年代的垃圾收集。出現了Major GC，經常會伴隨至少一次的Minor GC(并非絕對，在Parallel Scavenge收集器中就有直接進行Full GC的策略選擇過程)。Major GC的速度一般會比Minor GC慢10倍以上。

閱讀原文：深入理解JVM的垃圾回收機制

總結

以上是生活随笔為你收集整理的jvm垃圾回收机制_深入理解JVM的垃圾回收机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。