更多Android高級架構進階視頻學習請點擊：https://space.bilibili.com/474380680面試

對於程序計數器、虛擬機棧、本地方法棧這三個部分而言，其生命週期與相關線程有關，隨線程而生，隨線程而滅。而且這三個區域的內存分配與回收具備肯定性，由於當方法結束或者線程結束時，內存就天然跟着線程回收了。所以本篇文章所講的有關內存分配和回收關注的是Java堆與方法區這兩個區域。算法

一、如何判斷對象已「死」

Java堆中存放着幾乎全部的對象實例，垃圾回收器在堆進行垃圾回收前，首先要判斷這些對象那些還存活，那些已經「死去」。判斷對象是否已「死」有以下幾種算法：緩存

1.1 引用計數法
引用計數法描述的算法爲：給對象增長一個引用計數器，每當有一個地方引用它時，計數器就+1；當引用失效時，計數器就-1；任什麼時候刻計數器爲0的對象就是不能再被使用的，即對象已「死」。
引用計數法實現簡單，斷定效率也比較高，在大部分狀況下都是一個比較好的算法。好比Python語言就是採用的引用計數法來進行內存管理的。
可是，在主流的JVM中沒有選用引用計數法來管理內存，最主要的緣由是引用計數法沒法解決對象的循環引用問題。架構

範例：循環引用問題app

/**
  * 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並不使用引用計數法來判斷對象是否存活。ide

1.2 可達性分析算法
在上面講了，Java並不採用引用計數法來判斷對象是否已「死」，而採用「可達性分析」來判斷對象是否存活（一樣採用此法的還有C#、Lisp-最先的一門採用動態內存分配的語言）。
此算法的核心思想：經過一系列稱爲「GC Roots」的對象做爲起始點，從這些節點開始向下搜索，搜索走過的路徑稱爲「引用鏈」，當一個對象到 GC Roots 沒有任何的引用鏈相連時(從 GC Roots 到這個對象不可達)時，證實此對象不可用。如下圖爲例：學習

對象Object5 —Object7之間雖然彼此還有聯繫，可是它們到 GC Roots 是不可達的，所以它們會被斷定爲可回收對象。this

在Java語言中，可做爲GC Roots的對象包含如下幾種：url

虛擬機棧(棧幀中的本地變量表)中引用的對象。
方法區中靜態屬性引用的對象
方法區中常量引用的對象
本地方法棧中(Native方法)引用的對象
在JDK1.2之前，Java中引用的定義很傳統: 若是引用類型的數據中存儲的數值表明的是另外一塊內存的起始地址，就稱這塊內存表明着一個引用。這種定義有些狹隘，一個對象在這種定義下只有被引用或者沒有被引用兩種狀態。
咱們但願能描述這一類對象: 當內存空間還足夠時，則能保存在內存中；若是內存空間在進行垃圾回收後仍是很是緊張，則能夠拋棄這些對象。不少系統中的緩存對象都符合這樣的場景。
在JDK1.2以後，Java對引用的概念作了擴充，將引用分爲強引用(Strong Reference)、軟引用(Soft Reference)、弱引用(Weak Reference)和虛引用(Phantom Reference)四種，這四種引用的強度依次遞減。spa

強引用: 強引用指的是在程序代碼之中廣泛存在的，相似於"Object obj = new Object()"這類的引用，只要強引用還存在，垃圾回收器永遠不會回收掉被引用的對象實例。
軟引用: 軟引用是用來描述一些還有用可是不是必須的對象。對於軟引用關聯着的對象，在系統將要發生內存溢出以前，會把這些對象列入回收範圍之中進行第二次回收。若是此次回收仍是沒有足夠的內存，纔會拋出內存溢出異常。在JDK1.2以後，提供了SoftReference類來實現軟引用。
弱引用: 弱引用也是用來描述非必需對象的。可是它的強度要弱於軟引用。被弱引用關聯的對象只能生存到下一次垃圾回收發生以前。當垃圾回收器開始進行工做時，不管當前內容是否夠用，都會回收掉只被弱引用關聯的對象。在JDK1.2以後提供了WeakReference類來實現弱引用。
虛引用: 虛引用也被稱爲幽靈引用或者幻影引用，它是最弱的一種引用關係。一個對象是否有虛引用的存在，徹底不會對其生存時間構成影響，也沒法經過虛引用來取得一個對象實例。爲一個對象設置虛引用的惟一目的就是能在這個對象被收集器回收時收到一個系統通知。在JDK1.2以後，提供了PhantomReference類來實現虛引用。
生存仍是死亡？
即便在可達性分析算法中不可達的對象，也並不是"非死不可"的，這時候他們暫時處在"緩刑"階段。要宣告一個對象的真正死亡，至少要經歷兩次標記過程: 若是對象在進行可達性分析以後發現沒有與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 :)");
    }
    @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 :(");
        }
    }
}

從上面代碼示例咱們發現，ﬁnalize方法確實被JVM觸發，而且對象在被收集前成功逃脫。
可是從結果上咱們發現，兩個徹底同樣的代碼片斷，結果是一次逃脫成功，一次失敗。這是由於，任何一個對象的ﬁnalize()方法都只會被系統自動調用一次，若是相同的對象在逃脫一次後又面臨一次回收，它的ﬁnalize()方法不會被再次執行，所以第二段代碼的自救行動失敗。

二、回收方法區

方法區(永久代)的垃圾回收主要收集兩部份內容：廢棄常量和無用類。
回收廢棄常量和回收Java堆中的對象十分相似。以常量池中字面量(直接量)的回收爲例，假如一個字符串"abc"怡景進入了常量池中，可是當前系統沒有任何一個String對象引用常量池中的"abc"常量，也沒有其餘地方引用這個字面量，若是此時發生GC而且有必要的話，這個"abc"常量會被系統清理出常量池。常量池中的其餘類(接口)、方法、字段的符號引用也與此相似。
斷定一個類是不是"無用類"則相對複雜不少。類須要同時知足下面三個條件纔會被算是"無用的類"

1.該類的全部實例都已經被回收(即在Java堆中不存在任何該類的實例)
2.加載該類的ClassLoader已被回收
3.該類對應的Class對象沒有任何其餘地方被引用，沒法在任何地方經過反射訪問該類的方法

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

三、垃圾回收算法

3.1 標記-清除算法
「標記-清除」算法是最基礎的收集算法。算法分爲標記和清除兩個階段：首先標記出全部須要回收的對象，在標記完成後統一回收全部被標記的對象(標記過程參見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實現的複製算法流程以下：

當Eden區滿的時候，會觸發第一次Minor gc，把還活着的對象拷貝到Survivor From區；當Eden區再次出發Minor gc的時候，會掃描Eden區和From區，對兩個區域進行垃圾回收，通過此次回收後還存活的對象，則直接複製到To區域，並將Eden區和From區清空。
當後續Eden區又發生Minor gc的時候，會對Eden區和To區進行垃圾回收，存活的對象複製到From區，並將Eden區和To區清空
部分對象會在From區域和To區域中複製來複制去，如此交換15次(由JVM參數MaxTenuringThreshold決定，這個參數默認是15)，最終若是還存活，就存入老年代。

3.3 標記整理算法(老年代回收算法)
複製收集算法在對象存活率較高時會進行比較多的複製操做，效率會變低。所以在老年代通常不能使用複製算法。
針對老年代的特色，提出了一種稱之爲「標記-整理算法」。標記過程仍與「標記-清除」過程一致，但後續步驟不是直接對可回收對象進行清理，而是讓全部存活對象向一端移動，而後直接清理掉端邊界之外的內存。流程圖以下：

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倍以上。

更多Android高級架構進階視頻學習請點擊：https://space.bilibili.com/474380680

原文連接：https://blog.csdn.net/yubujian_l/article/details/80804708

深刻理解JAVA虛擬機原理之垃圾回收器機制（一）

一、如何判斷對象已「死」

二、回收方法區

三、垃圾回收算法