1.1。那究竟GC為我們做了什麼操作呢？

這時候有人就會疑惑了，既然GC 已經為我們解決了這個矛盾，我們還需要學習GC 麼？當然當然是肯定的，那究竟什麼時候我們還需要用到的呢？

1.1.1。JVM怎麼判斷物件可以回收了？

我們知道，GC 主要處理的是物件的回收操作，那麼什麼時候會觸發一個物件的回收的呢？

1，物件沒有引用

2，作用域發生未捕獲異常

3，程式在作用域正常執行完畢

4，程式執行了System.exit（）

5，程式發生意外終止（被殺程序等）

其實，我們最容易想到的就是當物件沒有引用的時候會將這個物件標記為可回收物件

並不是這個物件被賦值為空之後就一定被標記為可回收，有可能會發生逃逸！

1.2。下面我們來看一下幾種垃圾收集演算法

1.2.1。在JDK1.2之前，使用的是引用計數器演算法，

即當這個類被載入到記憶體以後，就會產生方法區，堆疊，程式計數器等一系列資訊，當建立物件的時候，為這個物件在堆疊空間中分配物件，同時會產生一個引用計數器，同時引用計數器1，當有新的引用的時候，引用計數器繼續1，而當其中一個引用銷燬的時候，引用計數器-1，當引用計數器被減為零的時候，標誌著這個物件已經沒有引用了，可以回收了！這種演算法在JDK1.2之前的版本被廣泛使用，但是隨著業務的發展，很快出現了一個問題

當我們的程式碼出現下面的情形時，該演算法將無法適應

a）ObjA.obj = ObjB

b）ObjB.obj - ObjA

這樣的程式碼會產生如下引用情形 objA 指向objB ，而objB 又指向objA ，這樣當其他所有的引用都消失了之後，objA 和objB 還有一個相互的引用，也就是說兩個物件的引用計數器各為1 ，而實際上這兩個物件都已經沒有額外的引用，已經是垃圾了。

1.2.2。根搜尋演算法

根搜尋演算法是從離散數學中的圖論引入的，程式把所有的引用關係看作一張圖，從一個節點GC ROOT 開始，尋找對應的引用節點，找到這個節點以後，繼續尋找這個節點的引用節點，當所有的引用節點尋找完畢之後，剩餘的節點則被認為是沒有被引用到的節點

目前java 中可作為GC Root 的物件有

1，虛擬機器棧中引用的物件（本地變量表）

2，方法區中靜態屬性引用的物件

3，方法區中常量引用的物件

4，本地方法棧中引用的物件（Native Object）

1.2.3。        引用的分類

1，強引用

只要引用存在，垃圾回收器永遠不會回收

Objectobj = new Object（）;

// 可直接通過物鏡取得對應的物件如obj.equels（NEWOBJECT（））;

而這樣 obj物件對後面newObject的一個強引用，只有當obj這個引用被釋放之後，物件才會被釋放掉，這也是我們經常所用到的編碼形式。

2、  軟引用

非必須引用，記憶體溢位之前進行回收，可以通過以下程式碼實現

Objectobj = new Object();

SoftReference<Object>sf = new SoftReference<Object>(obj);

obj =null;

sf.get();//有時候會返回null

這時候sf是對obj的一個軟引用，通過sf.get()方法可以取到這個物件，當然，當這個物件被標記為需要回收的物件時，則返回null；軟引用主要使用者實現類似快取的功能，在記憶體足夠的情況下直接通過軟引用取值，無需從繁忙的真實來源查詢資料，提升速度；當記憶體不足時，自動刪除這部分快取資料，從真正的來源查詢這些資料。

3、  弱引用

第二次垃圾回收時回收，可以通過如下程式碼實現

Objectobj = new Object();

WeakReference<Object>wf = new WeakReference<Object>(obj);

obj =null;

wf.get();//有時候會返回null

wf.isEnQueued();//返回是否被垃圾回收器標記為即將回收的垃圾

弱引用是在第二次垃圾回收時回收，短時間內通過弱引用取對應的資料，可以取到，當執行過第二次垃圾回收時，將返回null。

弱引用主要用於監控物件是否已經被垃圾回收器標記為即將回收的垃圾，可以通過弱引用的isEnQueued方法返回物件是否被垃圾回收器

4、  虛引用（幽靈/幻影引用）

垃圾回收時回收，無法通過引用取到物件值，可以通過如下程式碼實現

Objectobj = new Object();

PhantomReference<Object>pf = new PhantomReference<Object>(obj);

obj=null;

pf.get();//永遠返回null

pf.isEnQueued();//返回從記憶體中已經刪除

虛引用是每次垃圾回收的時候都會被回收，通過虛引用的get方法永遠獲取到的資料為null，因此也被成為幽靈引用。

虛引用主要用於檢測物件是否已經從記憶體中刪除。

1.3.         方法區也是會被回收的

！但是方法區的回收條件非常苛刻，只有同時滿足以下三個條件才會被回收！

1、所有例項被回收

2、載入該類的ClassLoader被回收

3、Class物件無法通過任何途徑訪問(包括反射)

好了，我們現在切入正題，Java1.2之前主要通過引用計數器來標記是否需要垃圾回收，而1.2之後都使用根搜尋演算法來收集垃圾，而收集後的垃圾是通過什麼演算法來回收的呢？

1、    標記-清除演算法

2、    複製演算法

複製演算法採用從根集合掃描，並將存活物件複製到一塊新的，沒有使用過的空間中，這種演算法當控制元件存活的物件比較少時，極為高效，但是帶來的成本是需要一塊記憶體交換空間用於進行物件的移動。也就是我們前面提到的

s0 s1等空間。

3、    標記-整理演算法

我們來逐一過一下

1、    標記-清除演算法

標記-清除演算法採用從根集合進行掃描，對存活的物件物件標記，標記完畢後，再掃描整個空間中未被標記的物件，進行回收，如上圖所示。

標記-清除演算法不需要進行物件的移動，並且僅對不存活的物件進行處理，在存活物件比較多的情況下極為高效，但由於標記-清除演算法直接回收不存活的物件，因此會造成記憶體碎片！

2、    複製演算法

 複製演算法採用從根集合掃描，並將存活物件複製到一塊新的，沒有使用過的空間中，這種演算法當控制元件存活的物件比較少時，極為高效，但是帶來的成本是需要一塊記憶體交換空間用於進行物件的移動。也就是我們前面提到的

s0 s1等空間。

3、    標記-整理演算法

 標記

-整理演算法採用標記-清除演算法一樣的方式進行物件的標記，但在清除時不同，在回收不存活的物件佔用的空間後，會將所有的存活物件往左端空閒空間移動，並更新對應的指標。標記-整理演算法是在標記-清除演算法的基礎上，又進行了物件的移動，因此成本更高，但是卻解決了記憶體碎片的問題。

我們知道，JVM為了優化記憶體的回收，進行了分代回收的方式，對於新生代記憶體的回收（minor GC）主要採用複製演算法，下圖展示了minor GC的執行過程。

1.4.         下面我們來逐一介紹一下每個垃圾回收器。

1.4.1.    1、    Serial收集器

看名字我們都可以看的出來，這個屬於序列收集器。其執行示意圖如下

 Serial

收集器是歷史最悠久的一個回收器，JDK1.3之前廣泛使用這個收集器，目前也是ClientVM下 ServerVM 4核4GB以下機器的預設垃圾回收器。序列收集器並不是只能使用一個CPU進行收集，而是當JVM需要進行垃圾回收的時候，需要中斷所有的使用者執行緒，知道它回收結束為止，因此又號稱“Stop The World”的垃圾回收器。注意，JVM中文名稱為java虛擬機器，因此它就像一臺虛擬的電腦一樣在工作，而其中的每一個執行緒就被認為是JVM的一個處理器，因此大家看到圖中的CPU0、CPU1實際為使用者的執行緒，而不是真正機器的CPU，大家不要誤解哦。

序列回收方式適合低端機器，是Client模式下的預設收集器，對CPU和記憶體的消耗不高，適合使用者互動比較少，後臺任務較多的系統。

Serial收集器預設新舊生代的回收器搭配為Serial+SerialOld

1.4.2.    2、    ParNew收集器

ParNew收集器其實就是多執行緒版本的Serial收集器，其執行示意圖如下

 同樣有

Stop The World的問題，他是多CPU模式下的首選回收器（該回收器在單CPU的環境下回收效率遠遠低於Serial收集器，所以一定要注意場景哦），也是Server模式下的預設收集器。

1.4.3.    3、    ParallelScavenge

ParallelScavenge又被稱為是吞吐量優先的收集器，器執行示意圖如下

 ParallelScavenge

所提到的吞吐量=程式執行時間/(JVM執行回收的時間+程式執行時間),假設程式運行了100分鐘，JVM的垃圾回收佔用1分鐘，那麼吞吐量就是99%。在當今網路告訴發達的今天，良好的響應速度是提升使用者體驗的一個重要指標，多核並行雲端計算的發展要求程式儘可能的使用CPU和記憶體資源，儘快的計算出最終結果，因此在互動不多的雲端，比較適合使用該回收器。

1.4.4.    4、    ParallelOld

ParallelOld是老生代並行收集器的一種，使用標記整理演算法、是老生代吞吐量優先的一個收集器。這個收集器是JDK1.6之後剛引入的一款收集器，我們看之前那個圖之間的關聯關係可以看到，早期沒有ParallelOld之前，吞吐量優先的收集器老生代只能使用序列回收收集器，大大的拖累了吞吐量優先的效能，自從JDK1.6之後，才能真正做到較高效率的吞吐量優先。其執行示意圖如下

1.4.5.     5、   SerialOld

SerialOld是舊生代Client模式下的預設收集器，單執行緒執行；在JDK1.6之前也是ParallelScvenge回收新生代模式下舊生代的預設收集器，同時也是併發收集器CMS回收失敗後的備用收集器。其執行示意圖如下

1.4.6.        6、CMS

CMS又稱響應時間優先(最短回收停頓)的回收器，使用併發模式回收垃圾，使用標記-清除演算法，CMS對CPU是非常敏感的，它的回收執行緒數=（CPU+3）/4，因此當CPU是2核的實惠，回收執行緒將佔用的CPU資源的50%，而當CPU核心數為4時僅佔用25%。他的執行示意圖如下

 CMS

模式主要分為4個過程

 在初始標記的時候，需要中斷所有使用者執行緒，在併發標記階段，使用者執行緒和標記執行緒

併發執行，而在這個過程中，隨著記憶體引用關係的變化，可能會發生原來標記的物件被釋放，進而引發新的垃圾，因此可能會產生一系列的浮動垃圾，不能被回收。

CMS 為了確保能夠掃描到所有的物件，避免在InitialMarking 中還有未標識到的物件，採用的方法為找到標記了的物件，並將這些物件放入Stack 中，掃描時尋找此物件依賴的物件，如果依賴的物件的地址在其之前，則將此物件進行標記，並同時放入Stack 中，如依賴的物件地址在其之後，則僅標記該物件。

在進行ConcurrentMarking 時minor GC 也可能會同時進行，這個時候很容易造成舊生代物件引用關係改變，CMS 為了應對這樣的並發現象，提供了一個Mod UnionTable 來進行記錄，在這個Mod Union Table中記錄每次minor GC 後修改了的Card 的資訊。這也是ParallelScavenge不能和CMS一起使用的原因。

CMS產生浮動垃圾的情況請見如下示意圖

在執行回收過後，c就變成了浮動垃圾。

由於CMS會產生浮動垃圾，當回收過後，浮動垃圾如果產生過多，同時因為使用標記-清除演算法會產生碎片，可能會導致回收過後的連續空間仍然不能容納新生代移動過來或者新建立的大資源，因此會導致CMS回收失敗，進而觸發另外一次FULL GC，而這時候則採用SerialOld進行二次回收。

同時CMS因為可能產生浮動垃圾，而CMS在執行回收的同時新生代也有可能在進行回收操作，為了保證舊生代能夠存放新生代轉移過來的資料，CMS在舊生代記憶體到達全部容量的68%就觸發了CMS的回收！

1.4.7.    7、    GarbageFirst(G1 )

我們再來看垃圾回收器的總圖，剛才我們可以看到，我在圖上標記了一個？，其實這是一個新的垃圾回收器，既可以回收新生代也可以回收舊生代，SunHotSpot1.6u14以上EarlyAccess版本加入了這個回收器，sun公司預期SunHotSpot1.7釋出正式版，他是商用高效能垃圾回收器，通過重新劃分記憶體區域，整合優化CMS，同時注重吞吐量和響應時間，但是杯具的是被oracle收購之後這個收集器屬於商用收費收集器，因此目前基本上沒有人使用，我們在這裡也就不多介紹，更多資訊可以參考oracle新版本JDK說明。

下面我們再來看下JVM的一些記憶體分配與回收策略

1、    優先在Edon上分配物件

 對於新生代和舊生代，

JVM可使用很多種垃圾回收器進行垃圾回收，下圖展示了不同生代不通垃圾回收器，其中兩個回收器之間有連線表示這兩個回收器可以同時使用。
 

 而這些垃圾回收器又分為序列回收方式、並行回收方式合併發回收方式執行，分別運用於不同的場景。如下圖所示

2    大物件直接進入老生代

3、    年長者(長期存活物件)進入老生代

4、    群體效應(大批中年物件進入老生代)

5、    擔保GC(擔保minorGC)

擔保GC 就是擔保minorGC 能夠滿足當前的儲存空間，而無需觸發老生代的回收，由於大部分物件都是朝生夕死的，因此，在實際開發中這種很起效，但是也有可能會發生擔保失敗的情況，當擔保失敗的時候會觸發FullGC ，但是失敗畢竟是少數，因此這種一般是很划算的