深入理解JVM的垃圾回收機制
點擊上方藍(lán)色字體，選擇“標(biāo)星公眾號”
優(yōu)質(zhì)文章，第一時間送達(dá)
1、如何判斷對象已“死”
Java堆中存放著幾乎所有的對象實例，垃圾回收器在堆進(jìn)行垃圾回收前，首先要判斷這些對象那些還存活，那些已經(jīng)“死去”。判斷對象是否已“死”有如下幾種算法：
1.1 引用計數(shù)法
引用計數(shù)法描述的算法為：給對象增加一個引用計數(shù)器，每當(dāng)有一個地方引用它時，計數(shù)器就+1；當(dāng)引用失效時，計數(shù)器就-1；任何時刻計數(shù)器為0的對象就是不能再被使用的，即對象已“死”。
引用計數(shù)法實現(xiàn)簡單，判定效率也比較高，在大部分情況下都是一個比較好的算法。比如Python語言就是采用的引用計數(shù)法來進(jìn)行內(nèi)存管理的。
但是，在主流的JVM中沒有選用引用計數(shù)法來管理內(nèi)存，最主要的原因是引用計數(shù)法無法解決對象的循環(huán)引用問題。
范例：循環(huán)引用問題
/**
* JVM參數(shù):-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進(jìn)行垃圾回收
System.gc();
}
public static void main(String[] args) {
testGC();
}
}
程序輸出：[GC (System.gc()) 6092K->856K(125952K), 0.0007504 secs]
從結(jié)果可以看出，GC日志包含" 6092K->856K(125952K)"，意味著虛擬機并沒有因為這兩個對象互相引用就不回收他們。即JVM并不使用引用計數(shù)法來判斷對象是否存活。
1.2 可達(dá)性分析算法
在上面講了，Java并不采用引用計數(shù)法來判斷對象是否已“死”，而采用“可達(dá)性分析”來判斷對象是否存活（同樣采用此法的還有C#、Lisp-最早的一門采用動態(tài)內(nèi)存分配的語言）。
此算法的核心思想：通過一系列稱為“GC Roots”的對象作為起始點，從這些節(jié)點開始向下搜索，搜索走過的路徑稱為“引用鏈”，當(dāng)一個對象到 GC Roots 沒有任何的引用鏈相連時(從 GC Roots 到這個對象不可達(dá))時，證明此對象不可用。以下圖為例：
對象Object5 —Object7之間雖然彼此還有聯(lián)系，但是它們到 GC Roots 是不可達(dá)的，因此它們會被判定為可回收對象。
在Java語言中，可作為GC Roots的對象包含以下幾種：
（1）虛擬機棧(棧幀中的本地變量表)中引用的對象。
（2）方法區(qū)中靜態(tài)屬性引用的對象
（3）方法區(qū)中常量引用的對象
（4）本地方法棧中(Native方法)引用的對象
在JDK1.2以前，Java中引用的定義很傳統(tǒng): 如果引用類型的數(shù)據(jù)中存儲的數(shù)值代表的是另一塊內(nèi)存的起始地址，就稱這塊內(nèi)存代表著一個引用。這種定義有些狹隘，一個對象在這種定義下只有被引用或者沒有被引用兩種狀態(tài)。
我們希望能描述這一類對象: 當(dāng)內(nèi)存空間還足夠時，則能保存在內(nèi)存中；如果內(nèi)存空間在進(jìn)行垃圾回收后還是非常緊張，則可以拋棄這些對象。很多系統(tǒng)中的緩存對象都符合這樣的場景。
在JDK1.2之后，Java對引用的概念做了擴充，將引用分為強引用(Strong Reference)、軟引用(Soft Reference)、弱引用(Weak Reference)和虛引用(Phantom Reference)四種，這四種引用的強度依次遞減。
（1）強引用: 強引用指的是在程序代碼之中普遍存在的，類似于"Object obj = new Object()"這類的引用，只要強引用還存在，垃圾回收器永遠(yuǎn)不會回收掉被引用的對象實例。
（2）軟引用: 軟引用是用來描述一些還有用但是不是必須的對象。對于軟引用關(guān)聯(lián)著的對象，在系統(tǒng)將要發(fā)生內(nèi)存溢出之前，會把這些對象列入回收范圍之中進(jìn)行第二次回收。如果這次回收還是沒有足夠的內(nèi)存，才會拋出內(nèi)存溢出異常。在JDK1.2之后，提供了SoftReference類來實現(xiàn)軟引用。
（3）弱引用: 弱引用也是用來描述非必需對象的。但是它的強度要弱于軟引用。被弱引用關(guān)聯(lián)的對象只能生存到下一次垃圾回收發(fā)生之前。當(dāng)垃圾回收器開始進(jìn)行工作時，無論當(dāng)前內(nèi)容是否夠用，都會回收掉只被弱引用關(guān)聯(lián)的對象。在JDK1.2之后提供了WeakReference類來實現(xiàn)弱引用。
（4）虛引用: 虛引用也被稱為幽靈引用或者幻影引用，它是最弱的一種引用關(guān)系。一個對象是否有虛引用的存在，完全不會對其生存時間構(gòu)成影響，也無法通過虛引用來取得一個對象實例。為一個對象設(shè)置虛引用的唯一目的就是能在這個對象被收集器回收時收到一個系統(tǒng)通知。在JDK1.2之后，提供了PhantomReference類來實現(xiàn)虛引用。
生存還是死亡？
即使在可達(dá)性分析算法中不可達(dá)的對象，也并非"非死不可"的，這時候他們暫時處在"緩刑"階段。要宣告一個對象的真正死亡，至少要經(jīng)歷兩次標(biāo)記過程: 如果對象在進(jìn)行可達(dá)性分析之后發(fā)現(xiàn)沒有與GC Roots相連接的引用鏈，那它將會被第一次標(biāo)記并且進(jìn)行一次篩選，篩選的條件是此對象是否有必要執(zhí)行?nalize()方法。當(dāng)對象沒有覆蓋?nalize()方法或者?nalize()方法已經(jīng)被JVM調(diào)用過，虛擬機會將這兩種情況都視為"沒有必要執(zhí)行"，此時的對象才是真正"死"的對象。
如果這個對象被判定為有必要執(zhí)行?nalize()方法，那么這個對象將會被放置在一個叫做F-Queue的隊列之中，并在稍后由一個虛擬機自動建立的、低優(yōu)先級的Finalizer線程去執(zhí)行它（這里所說的執(zhí)行指的是虛擬機會觸發(fā)?nalize()方法）。?nalize()方法是對象逃脫死亡的最后一次機會，稍后GC將對F-Queue中的對象進(jìn)行第二次小規(guī)模標(biāo)記，如果對象在?nalize()中成功拯救自己(只需要重新與引用鏈上的任何一個對象建立起關(guān)聯(lián)關(guān)系即可)，那在第二次標(biāo)記時它將會被移除出"即將回收"的集合；如果對象這時候還是沒有逃脫，那基本上它就是真的被回收了。
范例：對象自我拯救
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 :(");
}
}
}
從上面代碼示例我們發(fā)現(xiàn)，?nalize方法確實被JVM觸發(fā)，并且對象在被收集前成功逃脫。
但是從結(jié)果上我們發(fā)現(xiàn)，兩個完全一樣的代碼片段，結(jié)果是一次逃脫成功，一次失敗。這是因為，任何一個對象的?nalize()方法都只會被系統(tǒng)自動調(diào)用一次，如果相同的對象在逃脫一次后又面臨一次回收，它的?nalize()方法不會被再次執(zhí)行，因此第二段代碼的自救行動失敗。
2、回收方法區(qū)
方法區(qū)(永久代)的垃圾回收主要收集兩部分內(nèi)容：廢棄常量和無用類。
回收廢棄常量和回收J(rèn)ava堆中的對象十分類似。以常量池中字面量(直接量)的回收為例，假如一個字符串"abc"怡景進(jìn)入了常量池中，但是當(dāng)前系統(tǒng)沒有任何一個String對象引用常量池中的"abc"常量，也沒有其他地方引用這個字面量，如果此時發(fā)生GC并且有必要的話，這個"abc"常量會被系統(tǒng)清理出常量池。常量池中的其他類(接口)、方法、字段的符號引用也與此類似。
判定一個類是否是"無用類"則相對復(fù)雜很多。類需要同時滿足下面三個條件才會被算是"無用的類"
1.該類的所有實例都已經(jīng)被回收(即在Java堆中不存在任何該類的實例)
2.加載該類的ClassLoader已被回收
3.該類對應(yīng)的Class對象沒有任何其他地方被引用，無法在任何地方通過反射訪問該類的方法
JVM可以對同時滿足上述3個條件的無用類進(jìn)行回收，也僅僅是“可以”而不是必然。在大量使用反射、動態(tài)代理等場景都需要JVM具備類卸載的功能來防止永久代的溢出。
3、垃圾回收算法
3.1 標(biāo)記-清除算法
“標(biāo)記-清除”算法是最基礎(chǔ)的收集算法。算法分為標(biāo)記和清除兩個階段：首先標(biāo)記出所有需要回收的對象，在標(biāo)記完成后統(tǒng)一回收所有被標(biāo)記的對象(標(biāo)記過程參見1.2可達(dá)性分析)。后續(xù)的收集算法都是基于這種思路并對其不足加以改進(jìn)而已。
“標(biāo)記-清除”算法的不足主要有兩個：
（1）效率問題：標(biāo)記和清除這兩個過程的效率都不高
（2）空間問題：標(biāo)記清除后會產(chǎn)生大量不連續(xù)的內(nèi)存碎片，空間碎片太多可能會導(dǎo)致以后在程序運行中需要分配較大對象時，無法找到足夠連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集。
3.2 復(fù)制算法(新生代回收算法)
“復(fù)制”算法是為了解決“標(biāo)記-清除”的效率問題。它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中一塊。當(dāng)這塊內(nèi)存需要進(jìn)行垃圾回收時，會將此區(qū)域還存活著的對象復(fù)制到另一塊上面，然后再把已經(jīng)使用過的內(nèi)存區(qū)域一次清理掉。這樣做的好處是每次都是對整個半?yún)^(qū)進(jìn)行內(nèi)存回收，內(nèi)存分配時也就不需要考慮內(nèi)存碎片等的復(fù)雜情況，只需要移動堆頂指針，按順序分配即可。此算法實現(xiàn)簡單，運行高效。算法的執(zhí)行流程如下圖：
現(xiàn)在的商用虛擬機(包括HotSpot)都是采用這種收集算法來回收新生代
新生代中98%的對象都是"朝生夕死"的，所以并不需要按照1 : 1的比例來劃分內(nèi)存空間，而是將內(nèi)存(新生代內(nèi)存)分為一塊較大的Eden(伊甸園)空間和兩塊較小的Survivor(幸存者)空間，每次使用Eden和其中一塊Survivor（兩個Survivor區(qū)域一個稱為From區(qū)，另一個稱為To區(qū)域）。當(dāng)回收時，將Eden和Survivor中還存活的對象一次性復(fù)制到另一塊Survivor空間上，最后清理掉Eden和剛才用過的Survivor空間。
當(dāng)Survivor空間不夠用時，需要依賴其他內(nèi)存(老年代)進(jìn)行分配擔(dān)保。
HotSpot默認(rèn)Eden與Survivor的大小比例是8 : 1，也就是說Eden:Survivor From : Survivor To = 8:1:1。所以每次新生代可用內(nèi)存空間為整個新生代容量的90%,而剩下的10%用來存放回收后存活的對象。
HotSpot實現(xiàn)的復(fù)制算法流程如下：
（1）當(dāng)Eden區(qū)滿的時候，會觸發(fā)第一次Minor gc，把還活著的對象拷貝到Survivor From區(qū)；當(dāng)Eden區(qū)再次出發(fā)Minor gc的時候，會掃描Eden區(qū)和From區(qū)，對兩個區(qū)域進(jìn)行垃圾回收，經(jīng)過這次回收后還存活的對象，則直接復(fù)制到To區(qū)域，并將Eden區(qū)和From區(qū)清空。
（2）當(dāng)后續(xù)Eden區(qū)又發(fā)生Minor gc的時候，會對Eden區(qū)和To區(qū)進(jìn)行垃圾回收，存活的對象復(fù)制到From區(qū)，并將Eden區(qū)和To區(qū)清空
（3）部分對象會在From區(qū)域和To區(qū)域中復(fù)制來復(fù)制去，如此交換15次(由JVM參數(shù)MaxTenuringThreshold決定，這個參數(shù)默認(rèn)是15)，最終如果還存活，就存入老年代。
3.3 標(biāo)記整理算法(老年代回收算法)
復(fù)制收集算法在對象存活率較高時會進(jìn)行比較多的復(fù)制操作，效率會變低。因此在老年代一般不能使用復(fù)制算法。
針對老年代的特點，提出了一種稱之為“標(biāo)記-整理算法”。標(biāo)記過程仍與“標(biāo)記-清除”過程一致，但后續(xù)步驟不是直接對可回收對象進(jìn)行清理，而是讓所有存活對象向一端移動，然后直接清理掉端邊界以外的內(nèi)存。流程圖如下：
3.4 分代收集算法
當(dāng)前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，這個算法并沒有新思想，只是根據(jù)對象存活周期的不同將內(nèi)存劃分為幾塊。
一般是把Java堆分為新生代和老年代。在新生代中，每次垃圾回收都有大批對象死去，只有少量存活，因此我們采用復(fù)制算法；而老年代中對象存活率高、沒有額外空間對它進(jìn)行分配擔(dān)保，就必須采用"標(biāo)記-清理"或者"標(biāo)記-整理"算法。
面試題: 請問了解Minor GC和Full GC么，這兩種GC有什么不一樣嗎？
（1）Minor GC又稱為新生代GC : 指的是發(fā)生在新生代的垃圾收集。因為Java對象大多都具備朝生夕滅的特性，因此Minor GC(采用復(fù)制算法)非常頻繁，一般回收速度也比較快。
（2）Full GC 又稱為老年代GC或者M(jìn)ajor GC : 指發(fā)生在老年代的垃圾收集。出現(xiàn)了Major GC，經(jīng)常會伴隨至少一次的Minor GC(并非絕對，在Parallel Scavenge收集器中就有直接進(jìn)行Full GC的策略選擇過程)。Major GC的速度一般會比Minor GC慢10倍以上。
————————————————
版權(quán)聲明：本文為CSDN博主「LiuWang_1122」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：
https://blog.csdn.net/yubujian_l/article/details/80804708
鋒哥最新SpringCloud分布式電商秒殺課程發(fā)布
??????
??長按上方微信二維碼 2 秒
感謝點贊支持下哈 