點選「 IT碼徒 」， 關註，置頂 公眾號
每日技術幹貨，第一時間送達！
1、如何判斷物件已「死」
Java堆中存放著幾乎所有的物件例項，垃圾回收器在堆進行垃圾回收前，首先要判斷這些物件那些還存活，那些已經「死去」。判斷物件是否已「死」有如下幾種演算法：
1.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並不使用參照計數法來判斷物件是否存活。
1.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類來實作虛參照。
生存還是死亡？
即使在可達性分析演算法中不可達的物件，也並非"非死不可"的，這時候他們暫時處在"緩刑"階段。要宣告一個物件的真正死亡，至少要經歷兩次標記過程: 如果物件在進行可達性分析之後發現沒有與GC Roots相連線的參照鏈，那它將會被第一次標記並且進行一次篩選，篩選的條件是此物件是否有必要執行finalize()方法。當物件沒有覆蓋finalize()方法或者finalize()方法已經被JVM呼叫過，虛擬機器會將這兩種情況都視為"沒有必要執行"，此時的物件才是真正"死"的物件。
如果這個物件被判定為有必要執行finalize()方法，那麽這個物件將會被放置在一個叫做F-Queue的佇列之中，並在稍後由一個虛擬機器自動建立的、低優先級的Finalizer執行緒去執行它（這裏所說的執行指的是虛擬機器會觸發finalize()方法）。finalize()方法是物件逃脫死亡的最後一次機會，稍後GC將對F-Queue中的物件進行第二次小規模標記，如果物件在finalize()中成功拯救自己(只需要重新與參照鏈上的任何一個物件建立起關聯關系即可)，那在第二次標記時它將會被移除出"即將回收"的集合；如果物件這時候還是沒有逃脫，那基本上它就是真的被回收了。
範例：
物件自我拯救
public class Test {
public static Test test;
public void isAlive() {
System.out.println("I am alive :)");
}
@Override
protected 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 :(");
}
}
}
從上面程式碼範例我們發現，finalize方法確實被JVM觸發，並且物件在被收集前成功逃脫。
但是從結果上我們發現，兩個完全一樣的程式碼片段，結果是一次逃脫成功，一次失敗。這是因為，任何一個物件的finalize()方法都只會被系統自動呼叫一次，如果相同的物件在逃脫一次後又面臨一次回收，它的finalize()方法不會被再次執行，因此第二段程式碼的自救行動失敗。
2、回收方法區
方法區(永久代)的垃圾回收主要收集兩部份內容：廢棄常量和無用類。
回收廢棄常量和回收Java堆中的物件十分類似。以常量池中字面量(直接量)的回收為例，假如一個字串"abc"怡景進入了常量池中，但是當前系統沒有任何一個String物件參照常量池中的"abc"常量，也沒有其他地方參照這個字面量，如果此時發生GC並且有必要的話，這個"abc"常量會被系統清理出常量池。常量池中的其他類(介面)、方法、欄位的符號參照也與此類似。
判定一個類是否是"無用類"則相對復雜很多。類需要同時滿足下面三個條件才會被算是"無用的類"
1.該類的所有例項都已經被回收(即在Java堆中不存在任何該類的例項)
2.載入該類的 classLoader已被回收
3.該類對應的 class物件沒有任何其他地方被參照，無法在任何地方透過反射存取該類的方法
JVM可以對同時滿足上述3個條件的無用類進行回收，也僅僅是「可以」而不是必然。在大量使用反射、動態代理等場景都需要JVM具備類解除安裝的功能來防止永久代的溢位。
3、垃圾回收演算法
3.1 標記-清除演算法
「標記-清除」演算法是最基礎的收集演算法。演算法分為標記和清除兩個階段：首先標記出所有需要回收的物件，在標記完成後統一回收所有被標記的物件(標記過程參見1.2可達性分析)。後續的收集演算法都是基於這種思路並對其不足加以改進而已。
「標記-清除」演算法的不足主要有兩個：
（1）效率問題：標記和清除這兩個過程的效率都不高
（2）空間問題：標記清除後會產生大量不連續的記憶體碎片，空間碎片太多可能會導致以後在程式執行中需要分配較大物件時，無法找到足夠連續記憶體而不得不提前觸發另一次垃圾收集。
3.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.3 標記整理演算法(老年代回收演算法)
復制收集演算法在物件存活率較高時會進行比較多的復制操作，效率會變低。因此在老年代一般不能使用復制演算法。
針對老年代的特點，提出了一種稱之為「標記-整理演算法」。標記過程仍與「標記-清除」過程一致，但後續步驟不是直接對可回收物件進行清理，而是讓所有存活物件向一端移動，然後直接清理掉端邊界以外的記憶體。流程圖如下：
3.4 分代收集演算法
當前JVM垃圾收集都采用的是"分代收集(Generational Collection)"演算法，這個演算法並沒有新思想，只是根據物件存活周期的不同將記憶體劃分為幾塊。
一般是把Java堆分為新生代和老年代。在新生代中，每次垃圾回收都有大批物件死去，只有少量存活，因此我們采用復制演算法；而老年代中物件存活率高、沒有額外空間對它進行分配擔保，就必須采用"標記-清理"或者"標記-整理"演算法。
面試題: 請問了解Minor GC和Full GC麽，這兩種GC有什麽不一樣嗎？
（1）Minor GC又稱為新生代GC : 指的是發生在新生代的垃圾收集。因為Java物件大多都具備朝生夕滅的特性，因此Minor GC(采用復制演算法)非常頻繁，一般回收速度也比較快。
（2）Full GC 又稱為老年代GC或者Major GC : 指發生在老年代的垃圾收集。出現了Major GC，經常會伴隨至少一次的Minor GC(並非絕對，在Parallel Scavenge收集器中就有直接進行Full GC的策略選擇過程)。Major GC的速度一般會比Minor GC慢10倍以上。
— END —
PS：防止找不到本篇文章，可以收藏點贊，方便翻閱尋找哦。
往期推薦
