Java內存回收機制總結

以前看過幾回的內存回收機制，老是感受有些模糊，因此在這裏總結一下，以便往後查詢。

此處將引用《深刻理解Java虛擬機——JVM高級特性與最佳實踐》這本書的一些內容。

一、對象已死？

    垃圾回收是對堆中對象的管理，首先就要肯定什麼是垃圾，即什麼狀況下堆中的對象能夠被回收。

    最經常使用的斷定算法是引用計數算法，即每當有一個對象被其它對象所引用，則將對象的引用數+1，當對象的引用數爲0時，則認爲對象將再也不被使用，能夠回收。但引用計數算法有一個缺陷，即沒法解決對象循環引用的問題。當對象相互引用時，將會給引用的雙方的對象的引用計數+1，這樣的話對象的引用計數將一直沒法被清零，也便是說，GC（Garbage Collection）沒法斷定對象爲可回收對象，該對象將一直佔據在內存中沒法被釋放。

    Java中使用的斷定算法爲根搜索算法（GC Roots Tracing），這個算法的基本思路是經過一系列名爲「GC Roots」的對象做爲起始點，由該起始點出發向下搜索對象，搜索走過的路徑稱爲引用鏈（Reference Chain），當一個對象到GC Roots沒有任何引用鏈鏈接，即此對象不可達時，則認爲此對象不可用。

    Java中能夠做爲GC Roots的對象包括如下幾種：

    a、虛擬機棧（棧幀中的本地變量表）中的引用的對象

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

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

    d、本地方法棧中JNI的引用的對象

    我的對於以上幾種GC Roots對象的理解是這樣的：根搜索算法的斷定條件是對象不可達，而不是引用計數歸零，便是說當從某個引用出發去搜索對象時，某個對象沒法再被搜索到，則斷定該對象能夠被回收，這樣一來，一旦引用被重置爲null，假設該引用所指向的對象只被該引用所索引，那麼此時對象將再也不被任何引用所索引，此時對象將處於可回收狀態，而不會出現因爲循環引用而使引用計數沒法被清零的問題。具體情形以下：

    Java中對於引用的概念進行了擴充，以描述這樣一類對象：當內存空間還足夠時，則能保留在內存之中，若是內存在進行垃圾收集後仍是很是緊張，則能夠拋棄這些對象。

    Java中的引用分爲強引用（Strong Reference），軟引用（Soft Reference），弱引用（Weak Reference），虛引用（Phantom Reference）四種，強度依次減弱。

    a、強引用：相似"Object obj = new Object();"這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的對象

    b、軟引用：經過SoftReference類實現，SoftReference<Person> p = new SoftReference<Person>(new Person(「Rain」));內存很是緊張的時候會被回收，其餘時候不會被回收，因此在使用以前要判斷是否爲null從而判斷他是否已經被回收了。

    c、經過WeakReference類實現，eg : WeakReference<Person> p = new WeakReference<Person>(new Person(「Rain」));無論內存是否足夠，系統垃圾回收時一定會回收。

    d、不能單獨使用，主要是用於追蹤對象被垃圾回收的狀態。經過PhantomReference類和引用隊列ReferenceQueue類聯合使用實現。

    回顧完引用問題，來繼續看對象何時被回收的問題，前面已經講了當對象被斷定不可達時，則能夠被回收。可是否必定被回收呢？

    當對象被斷定不可達時，此時虛擬機會對該對象進行標記並篩選，篩選的條件是此對象有沒有必要執行finalize()方法。當對象沒有覆蓋finalize()方法或是虛擬仙已經調用過finalize()方法，則虛擬機將這兩種狀況都視爲沒有必要執行。如果斷定爲沒有必要執行，則直接回收對象。

    若對象被斷定爲有必要執行finalize()方法，虛擬機會把該對象放入一個F-Queue的隊列中，稍後會由虛擬機創建的一條優先級的線程Finalizer去執行。注意，此處的執行是指虛擬機會觸發這個方法，但不保證會等待方法的執行直至結束（避免因爲執行緩慢或是死循環而致使整個內存回收系統崩潰）。finalize()方法是對象逃脫被回收命運的最後一次機會，(若想要保留對象不被回收，可覆蓋finalize()方法並在方法中添加到這個對象的引用。)在F-Queue隊列開始執行後，過一會時間GC會對隊列中的對象進行第二次標記，標記和篩選方法和第一次的相同，但有一點有所不一樣，即任何對象的finalize()方法將被會且只會被系統自動調用一次，只要執行過一次後，之後將再也不執行，所以，在第二次標記後，依舊被斷定爲不可達的對象將被虛擬機直接回收。

    以上對對象的回收進行了回顧，而對於方法區的回收，JVM規範不要求虛擬機實現方法區的垃圾收集，虛擬機不必定會實現這方面的回收。在這裏就簡單的說一下永久代的回收內容和斷定條件。

    永久代的垃圾收集主要包括廢棄常量和無用的類，廢棄常量的判斷比較簡單，只要檢查該常量是否被引用就能夠了。而類的「無用」斷定則要同時知足三個條件：a、該類全部的實例已經被回收，即Java堆中不存在該類的任何實例；b、加載該類的ClassLoader已經被回收；c、該類對應的java.lang.Class對象沒有在任何地方被引用，沒法在任何地方經過反射訪問該類的方法。

    在大量使用反射、動態代理、CGLib等bytecode框架的場景，以及動態生成JSP和OSGi這類頻繁自定義的ClassLoader的場景都須要虛擬機具有類卸載的功能，以保證永久代不會溢出。

二、經常使用的垃圾收集算法

    a、標記——清除算法（Mark——Sweep）

    首先標記出全部須要回收的對象，在標記完成後統一回收掉全部被標記的對象。

    缺點：

    效率問題，標記和清除過程的效率不高；

    空間問題，標記清除以後會產生大量的非連續空間碎片，過多的碎片將致使程序在之後的運行中找不到足夠大的連續內存空間來分配給較大的對象而不得不提早觸發另外一次垃圾收集事件。

    b、複製算法（Copying）

    爲了解決標記清除算法的效率問題，複製算法將可用的內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活的對象複製到另外一塊上，而後再把已使用過的內存空間一次清理掉。

    優勢：

    實現簡單，運行高效

    缺點：

    對內存空間的利用不高，可用內存變成一半，這代價太高

    如今的商業虛擬機基本都採用這種收集算法來回收新生代，因爲新生代中的對象存活率不高，所以不須要按1：1來劃份內存空間，而是將內存分爲一塊較大的Eden空間和兩塊較小的Survior空間，每次使用Eden和其中的一塊Survior，回收時將Eden和Survior中還存活的對象一次性地拷貝到另一塊Survior上，最後清理掉Eden和剛纔用過的Survior空間。（HotSpot虛擬機默認Eden和Survior大小比例是8：1）固然，Survior空間不可能一直夠用，此時還須要老年代來進行分配擔保（Handle Promotion）（主要是將新生代存活的大對象直接移到老年代，以減小對Survior內存空間的需求）。

    c、標記——整理算法（Mark——Compact）

    與標記清除算法的標記階段相同，但標記後會將全部存活的對象向一端移動，而後直接清理掉端邊界之外的內存。這種算法通常用於老年代的內存回收上，由於老年代中對象的存活時間都比較長，可能存在100%存活的極端狀況，所以不能選擇Copying算法來進行回收。

    d、分代收集算法（Generational Collection）

    這種算法只是根據對象的存活週期的不一樣將內存劃分爲幾塊，通常都劃分爲新生代和老年代，這樣能夠根據各個年代的特色採用最適當的收集算法。新生代中，每次垃圾收集時都發現有大批對象死去，只有少許存活，所以選取複製算法，只須要付出少許存活對象的複製成本就能夠完成收集；老年代中由於對象存活率高，沒有額外的空間對它進行分配擔保，就必須使用「標記——清除」或是「標記——整理」算法來進行回收。在以前的三種算法中已經有所描述。

三、內存分配與回收策略

    回顧完垃圾回收的斷定和算法後，咱們來看下內存分配和回收的策略。

    內存的回收分爲兩類：

    新生代GC（Minor GC）：指發生在新生代的垃圾收集動做，由於Java對象大多都具有朝生夕死的特性，因此Minor GC很是頻繁，通常回收速度也比較快。

    老年代GC（Major GC/Full GC）：指發生在老年代的GC，出現Major GC，常常會伴隨至少一次Minor GC。Major GC的速度通常會比Minor GC慢10倍以上，並且一次Full GC的執行是以整個程序徹底停滯做爲代價的，這對於不少實時或是高響應要求的應用來講是不可接受的，所以須要儘量地減小Full GC的出現。

    虛擬機通常會採用如下幾種內存分配策略來儘可能減小Full GC出現的頻率：

    a、對象優先在Eden分配

    b、大對象直接進行老年代（可經過參數設置直接進入老年代的對象的內存閾值）

    c、長期存活的對象將進入老年代（對Survior中的對象進行年齡計量，每通過一次Minor GC而不被回收，則對其年齡+1，當達到閾值時就晉升到老年代，閾值能夠經過參數設置）

    d、動態對象年齡斷定（當Survior空間中相同年齡全部對象大小的總和大於Survior空間的一半，則年齡大於或等於該年齡的對象就能夠直接進入老年代）

    e、空間分配擔保（在此前有提到過，老年代爲Survior進行空間擔保，當Survior空間不足時將對象轉移進老年代。前提是老年代也有足夠的空間來安置來自Survior的對象，但Survior中將要被移到老年代的對象的大小在完成內存回收以前是不可知的，只能取以前每一次回收晉升到老年代對象容量的平均大小值做爲經驗值，與老年代的剩餘空間進行比較，決定是否進行Full GC來讓老年代騰出空間。固然，若是出現某次Minor GC存活後的對象突增，遠遠高於平均值，此時可能會致使擔保失敗，則將從新發起一次Full GC）

 

    好了，終於完成了關於Java內存回收機制的複習，除了《深刻理解Java虛擬機》這本書外，還引用瞭如下頁面的內容，這篇博客對垃圾回收機制的描述更加細緻且易於理解。文章連接以下：

http://blog.jobbole.com/37273/