概述

說起垃圾收集（Garbage Collection贫途，GC）吧彪，大部分人都把這項技術(shù)當做Java語言的伴生產(chǎn)物。事實上丢早，GC的歷史遠遠比Java久遠姨裸，1960年誕生于MIT的Lisp是第一門真正使用內(nèi)存動態(tài)分配和垃圾收集技術(shù)的語言。當Lisp還在胚胎時期時怨酝，人們就在思考GC需要完成的三件事：

• 那些內(nèi)存需要回收傀缩？
• 什么時候回收？
• 如何回收农猬？

經(jīng)過半個世紀的發(fā)展赡艰，內(nèi)存的動態(tài)分配與內(nèi)存回收技術(shù)已經(jīng)相當成熟，一切看起來都進入了“自動化”時代盛险，那為什么我們還要去了解GC和內(nèi)存分配呢瞄摊？答案很簡單：當需要排查各種內(nèi)存溢出勋又、內(nèi)存泄漏問題時苦掘，當垃圾收集成為系統(tǒng)達到更高并發(fā)量的瓶頸時，我們就需要堆這些”自動化“的技術(shù)實施必要的監(jiān)控和調(diào)節(jié)楔壤。

在自動內(nèi)存管理機制中介紹了內(nèi)存運行時區(qū)域的各個部分鹤啡，其中程序計數(shù)器、虛擬機棧蹲嚣、本地方法棧三個區(qū)域隨線程而生递瑰，歲線程而滅：棧中的棧幀隨著方法的進入和退出有條不紊地執(zhí)行著出棧和入棧操作祟牲。每一個棧幀中分配多少內(nèi)存基本上是在類結(jié)構(gòu)確定下來時就已知地（盡管在運行期會由JIT編譯器進行一些優(yōu)化，但在本章基于概念模型地討論中抖部，大體上可以認為是編譯器可知地）说贝，因此這幾個區(qū)域地內(nèi)存分配和回收都具備確定性，在這幾個區(qū)域內(nèi)不需要過多考慮回收的問題慎颗，因為方法結(jié)束或線程結(jié)束時乡恕，內(nèi)存自然就跟隨著回收了。而Java堆和方法區(qū)則不一樣俯萎，一個接口中的多個實現(xiàn)類需要的內(nèi)存可能不一樣傲宜，一個方法中多個分支需要的內(nèi)存也可能不一樣，我們只有在程序處于運行期間時才能指定會創(chuàng)建那些對象夫啊，這部分內(nèi)存的分配和回收時動態(tài)地函卒，垃圾收集器所關(guān)注的是這部分內(nèi)存。

對象已死撇眯？

堆中幾乎存放著Java世界中所有的對象實例报嵌，垃圾收集器在對堆進行回收前，第一件事情就是要確定這些對象有哪些還”存活“著熊榛，那些已經(jīng)”死去“（即不可能再被任何途徑使用的對象）沪蓬。

引用計數(shù)算法

很多教科書判斷對象是否存活的算法是這樣的：給對象中添加一個引用計數(shù)器，每當有一個地方引用它時来候，計數(shù)器值就加1跷叉；當引用失效時，計數(shù)器值就減1营搅；任何時刻計數(shù)器都為0的對象就是不可能再被使用的云挟。

但是，Java語言中沒有選用引用計數(shù)器來管理內(nèi)存转质，其中最主要的原因是它很難解決對象之間的相互循環(huán)引用的問題园欣。

舉個栗子：

public class ReferenceCountingGC{
    public Object instance = null;
    private static final int _1MB = 1024 * 1024;
    private byte[] bigSize = new byte[2 * _1MB];
    public static void testGC(){
        ReferenceCountingGC objA = new ReferenceCountingGC();
        RferenceCountingGC objB = new ReferenceCountingGC();
        objA.instance = objB;
        ObjB.instance = objA;
        objA = null;
        objB = null;
        System.gc();
    }
}

在testGC()中：對象objA和objB都有字段instance，賦值另objA.instance = objB及objB.instance = objA休蟹，除此之外沸枯，這兩個對象再無任何引用，實際上這兩個對象已經(jīng)不可能再被訪問赂弓，但是它們因為相互引用著對方绑榴，導(dǎo)致它們的引用計數(shù)都不為0，于是引用計數(shù)器算法無法通知GC收集回收它們盈魁。

根搜索算法

在主流的商用程序語言中（Java和C#翔怎，甚至包括前面提到的古老的Lisp），都是使用根搜索算法（GC Roots Tracing）判定對象是否存活的。這個算法的基本思路就是通過一系列的名為“GC Roots”的對象作為起始點赤套，從這些節(jié)點開始向下搜索飘痛，搜索所走過的路徑稱為引用鏈（Reference Chain），當一個對象到GC Roots沒有任何引用鏈相連（用圖論的話來說就是從GC Roots到這個對象不可達）時容握，則證明此對象是不可用的宣脉。

如圖所示，對象object 5剔氏、object 6脖旱、object 7雖然互相有關(guān)聯(lián)，但是它們到GC Roots是不可達的介蛉，所以它們將會被判定為是否可回收的對象萌庆。

19.jpg

在Java語言里，可作為GC Roots的對象包括下面幾種：

• 虛擬機棧（棧幀中的本地變量表）中的引用的對象币旧。
• 方法區(qū)中的類靜態(tài)屬性引用的對象践险。
• 方法區(qū)中的常量引用的對象。
• 本地方法棧中JNI（即一般說的Native方法）的引用的對象吹菱。

再談引用

在JDK1.2之前巍虫，Java中的引用的定義很傳統(tǒng)：如果reference類型的數(shù)據(jù)中存儲的數(shù)值代表的是另外一塊內(nèi)存的起始地址，就稱這塊內(nèi)存代表著一個引用鳍刷。

一個對象在這種定義下只有被引用或者沒有被引用兩種狀態(tài)占遥，對于如何描述一些“食之無味，棄之可惜”的對象就顯得無能為力输瓜。我們希望能描述這樣一類對象：當內(nèi)存空間還沒足夠時瓦胎，則能保留在內(nèi)存之中；如果內(nèi)存在進行垃圾收集后還是非常緊張尤揣，則可以拋棄這些對象搔啊。很多系統(tǒng)的緩存功能都符合這樣的應(yīng)用場景。

在JDK1.2之后北戏，Java對引用的概念進行了擴充负芋，將引用分為強引用（Strong Reference）、軟引用（Soft Reference）嗜愈、弱引用（Weak Reference）旧蛾、虛引用（Phantom Refence）四種，這四種引用強度依次逐漸減弱蠕嫁。

• 弱引用就是指程序代碼之中普遍存在的锨天，類似“Object obj = new Object()”這類的引用，只要強引用還存在拌阴，垃圾收集器永遠不會回收掉被引用的對象绍绘。
• 軟引用用來描述一些還有用，但并非必須的對象迟赃。對于軟引用關(guān)聯(lián)著的對象陪拘，在系統(tǒng)將要發(fā)生內(nèi)存溢出異常之前，將會把這些對象列進回收范圍之中并進行第二次回收纤壁。如果這次回收還是沒有足夠的內(nèi)存左刽，才會拋出內(nèi)存溢出異常。在JDK1.2之后酌媒，提供了SoftReference類來實現(xiàn)軟引用欠痴。
• 弱引用也是用來描述非必須對象的，但是它的強度比軟引用更弱一些秒咨，被弱引用關(guān)聯(lián)的對象只能生存到下一次垃圾收集器發(fā)生之前喇辽。當垃圾收集器工作時，無論當前內(nèi)存是否足夠雨席，都會回收掉只被弱引用關(guān)聯(lián)的對象菩咨。在JDK1.2之后，提供了WeakReference類來實現(xiàn)弱引用陡厘。
• 虛引用也成為幽靈引用或者幻影引用抽米，它是最弱的一種引用關(guān)系。一個對象是否有虛引用的存在糙置，完全不會對其生存時間構(gòu)成影響云茸，也無法通過虛引用來取得一個對象實例。

生成還是死亡谤饭？

在根搜索算法中不可達的對象标捺，也并非是“非死不可”的，這時候它們暫時處于“緩刑”階段揉抵，要真正宣告一個對象死亡宜岛，至少要經(jīng)歷兩次標記過程：如果對象在進行根搜索后發(fā)現(xiàn)沒有與GC Roots相鏈接的引用鏈，那它將會被第一次標記并且進行一次篩選功舀，篩選的條件是此對象是否有必要執(zhí)行finalize()方法萍倡。當對象沒有覆蓋finalize()方法，或者finalize()方法已經(jīng)被虛擬機調(diào)用過辟汰，虛擬機將這兩種情況都視為“沒有必要執(zhí)行”列敲。

如果這對象被判定為有必要執(zhí)行finalize()方法，那么這個對象將會被放置在一個名為F-Queue的隊列之中帖汞，并在稍后由一條由虛擬機自動建立的戴而、低優(yōu)先級的Finalizer線程去執(zhí)行。這里所謂的"執(zhí)行"是指虛擬機會觸發(fā)這個方法翩蘸，但并不承諾會等待它運行結(jié)束所意。這樣做的原因是，如果一個對象在finalize()方法中執(zhí)行緩慢，或者發(fā)生了死循環(huán)（更極端的情況）扶踊，將很可能會導(dǎo)致F-Queue的隊列中的其他對象永久處于等待狀態(tài)泄鹏，甚至導(dǎo)致整個內(nèi)存回收系統(tǒng)崩潰。finalize()方法是對象逃脫死亡命運的最后一次機會秧耗，稍后GC將對F-Queue中的對象進行第二次小規(guī)模的標記备籽，如果對象要在finalize()中成功拯救自己——只要重新與引用鏈上的任何一個對象建立關(guān)聯(lián)即可，譬如把自己（this關(guān)鍵字）賦值給某個類變量或?qū)ο蟮某蓡T變量分井，那在第二次標記時它將被移除出”即將回收的“集合车猬；如果對象這個時候還沒有逃逸，那它就真的離死不遠了尺锚。

public class FinalizeEscapeGC{
    public static FinalizeEscapeGC SAVE_HOOK = null;
    public void isAlive(){
        System.out.println("yes, i am still alive :)");
    }
    
    @Override
    protected void finalize() throws Throwable{
        super.finalize();
        System.out.println("finalize method executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }
    
    public static void main(String[] args) throws Throwable{
        SAVE_HOOK = new FinalizeEscapeGC();
        
        //對象第一次成功拯救了自己
        SAVE_HOOK = null;
        System.gc();
        //因為Finalizer方法優(yōu)先級很低珠闰，暫定0.5秒，以等待它
        Thread.sleep(500);
        if(SAVE_HOOK != null){
            SAVE_HOOK.isAlive();
        }else{
            System.out.println("no, i am dead :(")瘫辩；
        }
    }
}

從上面代碼中我們可以看到一個對象的finalize()被執(zhí)行伏嗜，但是它仍然可以存活。

在這里插入圖片描述

從代碼運行結(jié)果可以看到杭朱，SAVE_HOOK對象的finalize()方法確實被GC收集器觸發(fā)過阅仔，并且在被收集前成功逃脫了。

另外一個值得注意的地方就是弧械，代碼中有兩段完全一樣的代碼片段八酒，執(zhí)行結(jié)果卻是一次逃脫成功，一次失敗刃唐，這是因為任何一個對象的finalize()方法都只會被系統(tǒng)自動調(diào)用一次羞迷，如果對象面臨下一次回收，它的finalize()方法不會被再次執(zhí)行画饥，因此第二段代碼的自救行動失敗了衔瓮。

回收方法區(qū)

很多人認為方法區(qū)（或者HotSpot虛擬機中的永久代）是沒有垃圾收集的，Java虛擬機規(guī)范中確實說過可以不要求虛擬機在方法區(qū)實現(xiàn)垃圾收集抖甘，而且在方法區(qū)進行垃圾收集的”性價比“一般比較低：在堆中热鞍，尤其是在新生代中，常規(guī)應(yīng)用進行一次垃圾收集一般可以回收70%~95%的空間衔彻，而永久代的垃圾收集效率遠低于此薇宠。

永久代的垃圾收集主要回收兩部分內(nèi)容：廢棄常量和無用的類〖瓒睿回收廢棄常量與回收Java堆中的對象非常類似澄港。以常量池中的字面量的回收為例，假如一個字符串”abc“已經(jīng)進入了常量池柄沮，但是當前系統(tǒng)沒有任何一個String對象是叫做”abc”的回梧，換句話說是沒有任何String對象引用常量池中的“abc"常量废岂，也沒有其他地方引用了這個字面量，如果在這個時候發(fā)生內(nèi)存回收狱意，而且必要的話湖苞，這個”abc“常量就會被系統(tǒng)”請“出常量池。常量池中的其他類（接口）髓涯、方法袒啼、字段的符號引用也與此類似哈扮。

判定一個常量是否是”廢棄常量“比較簡單纬纪，而要判定一個類是否是”無用的類“的條件則相對苛刻許多。類需要同時滿足下面3個條件才能算是”無用的類“：

• 該類所有的實例都已經(jīng)被回收滑肉，也就是Java堆中不存在該類的任何實例包各。
• 加載該類的ClassLoader已經(jīng)被回收。
• 該類對應(yīng)的java.lang.Class對象沒有在任何地方被引用靶庙，無法在任何地方通過反射訪問該類的方法问畅。

虛擬機可以對滿足上述3個條件的無用類進行回收，這里說的僅僅是”可以“六荒，而不是和對象一樣护姆，不使用了就必然會回收。是否對類進行回收掏击，HotSpot虛擬機提供了-Xnoclassgc參數(shù)進行控制卵皂，還可以使用-verbose:class及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看類的加載和卸載信息砚亭。-verbose:class和-XX:+TraceClassLoading可以在Product版的虛擬機中使用灯变，但是-XX:+TraceClassUnLoading參數(shù)需要fastdebug版的虛擬機支持。

在大量使用反射捅膘、動態(tài)代理添祸、CGLib等bytecode框架的場景，以及動態(tài)生成JSP和OSGi這類頻繁自定義ClassLoader的場景都需要虛擬機具備類卸載的功能寻仗，以保證永久代不會溢出刃泌。