[效能][JVM]jvm垃圾回收機制

一、垃圾回收機制的意義

Java語言中一個顯著的特點就是引入了垃圾回收機制，使c++程式設計師最頭疼的記憶體管理的問題迎刃而解，它使得Java程式設計師在編寫程式的時候不再需要考慮記憶體管理。由於有個垃圾回收機制，Java中的物件不再有“作用域”的概念，只有物件的引用才有“作用域”。垃圾回收可以有效的防止記憶體洩露，有效的使用空閒的記憶體。

ps:記憶體洩露是指該記憶體空間使用完畢之後未回收，在不涉及複雜資料結構的一般情況下，Java 的記憶體洩露表現為一個記憶體物件的生命週期超出了程式需要它的時間長度，我們有時也將其稱為“物件遊離”。

二、垃圾回收機制中的演算法

Java語言規範沒有明確地說明JVM使用哪種垃圾回收演算法，但是任何一種垃圾回收演算法一般要做2件基本的事情：（1）發現無用資訊物件；（2）回收被無用物件佔用的記憶體空間，使該空間可被程式再次使用。

1.引用計數法(Reference Counting Collector)

1.1演算法分析

引用計數是垃圾收集器中的早期策略。在這種方法中，堆中每個物件例項都有一個引用計數。當一個物件被建立時，且將該物件例項分配給一個變數，該變數計數設定為1。當任何其它變數被賦值為這個物件的引用時，計數加1（a = b,則b引用的物件例項的計數器+1），但當一個物件例項的某個引用超過了生命週期或者被設定為一個新值時，物件例項的引用計數器減1。任何引用計數器為0的物件例項可以被當作垃圾收集。當一個物件例項被垃圾收集時，它引用的任何物件例項的引用計數器減1。

1.2優缺點

優點：

引用計數收集器可以很快的執行，交織在程式執行中。對程式需要不被長時間打斷的實時環境比較有利。

缺點：

無法檢測出迴圈引用。如父物件有一個對子物件的引用，子物件反過來引用父物件。這樣，他們的引用計數永遠不可能為0.

1.3引用計數演算法無法解決迴圈引用問題，例如：

public class Main {     public static void main(String[] args) {         MyObject object1 = new MyObject();         MyObject object2 = new MyObject();                    object1.object = object2;         object2.object = object1;                    object1 = null;         object2 = null;     } }

最後面兩句將object1和object2賦值為null，也就是說object1和object2指向的物件已經不可能再被訪問，但是由於它們互相引用對方，導致它們的引用計數器都不為0，那麼垃圾收集器就永遠不會回收它們。

2.tracing演算法(Tracing Collector) 或 標記-清除演算法(mark and sweep)

2.1根搜尋演算法

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

java中可作為GC Root的物件有

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

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

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

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

2.2tracing演算法的示意圖

2.3標記-清除演算法分析

標記-清除演算法採用從根集合進行掃描，對存活的物件物件標記，標記完畢後，再掃描整個空間中未被標記的物件，進行回收，如上圖所示。標記-清除演算法不需要進行物件的移動，並且僅對不存活的物件進行處理，在存活物件比較多的情況下極為高效，但由於標記-清除演算法直接回收不存活的物件，因此會造成記憶體碎片。

3.compacting演算法 或 標記-整理演算法

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

4.copying演算法(Compacting Collector)

該演算法的提出是為了克服控制程式碼的開銷和解決堆碎片的垃圾回收。它開始時把堆分成 一個物件 面和多個空閒面， 程式從物件面為物件分配空間，當物件滿了，基於copying演算法的垃圾 收集就從根集中掃描活動物件，並將每個 活動物件複製到空閒面(使得活動物件所佔的記憶體之間沒有空閒洞)，這樣空閒面變成了物件面，原來的物件面變成了空閒面，程式會在新的物件面中分配記憶體。一種典型的基於coping演算法的垃圾回收是stop-and-copy演算法，它將堆分成物件面和空閒區域面，在物件面與空閒區域面的切換過程中，程式暫停執行。

5.generation演算法(Generational Collector)

分代的垃圾回收策略，是基於這樣一個事實：不同的物件的生命週期是不一樣的。因此，不同生命週期的物件可以採取不同的回收演算法，以便提高回收效率。

年輕代（Young Generation）

1.所有新生成的物件首先都是放在年輕代的。年輕代的目標就是儘可能快速的收集掉那些生命週期短的物件。

2.新生代記憶體按照8:1:1的比例分為一個eden區和兩個survivor(survivor0,survivor1)區。一個Eden區，兩個 Survivor區(一般而言)。大部分物件在Eden區中生成。回收時先將eden區存活物件複製到一個survivor0區，然後清空eden區，當這個survivor0區也存放滿了時，則將eden區和survivor0區存活物件複製到另一個survivor1區，然後清空eden和這個survivor0區，此時survivor0區是空的，然後將survivor0區和survivor1區交換，即保持survivor1區為空， 如此往復。

3.當survivor1區不足以存放 eden和survivor0的存活物件時，就將存活物件直接存放到老年代。若是老年代也滿了就會觸發一次Full GC，也就是新生代、老年代都進行回收

4.新生代發生的GC也叫做Minor GC，MinorGC發生頻率比較高(不一定等Eden區滿了才觸發)

年老代（Old Generation）

1.在年輕代中經歷了N次垃圾回收後仍然存活的物件，就會被放到年老代中。因此，可以認為年老代中存放的都是一些生命週期較長的物件。

2.記憶體比新生代也大很多(大概比例是1:2)，當老年代記憶體滿時觸發Major GC即Full GC，Full GC發生頻率比較低，老年代物件存活時間比較長，存活率標記高。

持久代（Permanent Generation）

用於存放靜態檔案，如Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者呼叫一些class，例如Hibernate 等，在這種時候需要設定一個比較大的持久代空間來存放這些執行過程中新增的類。

三.GC（垃圾收集器）

新生代收集器使用的收集器：Serial、PraNew、Parallel Scavenge

老年代收集器使用的收集器：Serial Old、Parallel Old、CMS

Serial收集器（複製演算法)

新生代單執行緒收集器，標記和清理都是單執行緒，優點是簡單高效。

Serial Old收集器(標記-整理演算法)

老年代單執行緒收集器，Serial收集器的老年代版本。

ParNew收集器(停止-複製演算法)　

新生代收集器，可以認為是Serial收集器的多執行緒版本,在多核CPU環境下有著比Serial更好的表現。

Parallel Scavenge收集器(停止-複製演算法)

並行收集器，追求高吞吐量，高效利用CPU。吞吐量一般為99%， 吞吐量= 使用者執行緒時間/(使用者執行緒時間+GC執行緒時間)。適合後臺應用等對互動相應要求不高的場景。

Parallel Old收集器(停止-複製演算法)

Parallel Scavenge收集器的老年代版本，並行收集器，吞吐量優先

CMS(Concurrent Mark Sweep)收集器（標記-清理演算法）

高併發、低停頓，追求最短GC回收停頓時間，cpu佔用比較高，響應時間快，停頓時間短，多核cpu 追求高響應時間的選擇

四、GC的執行機制

由於物件進行了分代處理，因此垃圾回收區域、時間也不一樣。GC有兩種型別：Scavenge GC和Full GC。

Scavenge GC

一般情況下，當新物件生成，並且在Eden申請空間失敗時，就會觸發Scavenge GC，對Eden區域進行GC，清除非存活物件，並且把尚且存活的物件移動到Survivor區。然後整理Survivor的兩個區。這種方式的GC是對年輕代的Eden區進行，不會影響到年老代。因為大部分物件都是從Eden區開始的，同時Eden區不會分配的很大，所以Eden區的GC會頻繁進行。因而，一般在這裡需要使用速度快、效率高的演算法，使Eden去能儘快空閒出來。

Full GC

對整個堆進行整理，包括Young、Tenured和Perm。Full GC因為需要對整個堆進行回收，所以比Scavenge GC要慢，因此應該儘可能減少Full GC的次數。在對JVM調優的過程中，很大一部分工作就是對於FullGC的調節。有如下原因可能導致Full GC：

1.年老代（Tenured）被寫滿

2.持久代（Perm）被寫滿

3.System.gc()被顯示呼叫

4.上一次GC之後Heap的各域分配策略動態變化

五、Java有了GC同樣會出現記憶體洩露問題

1.靜態集合類像HashMap、Vector等的使用最容易出現記憶體洩露，這些靜態變數的生命週期和應用程式一致，所有的物件Object也不能被釋放，因為他們也將一直被Vector等應用著。

Static Vector v = new Vector(); for (int i = 1; i<100; i++) {     Object o = new Object();     v.add(o);       o = null;    }

在這個例子中，程式碼棧中存在Vector 物件的引用 v 和 Object 物件的引用 o 。在 For 迴圈中，我們不斷的生成新的物件，然後將其新增到 Vector 物件中，之後將 o 引用置空。問題是當 o 引用被置空後，如果發生 GC，我們建立的 Object 物件是否能夠被 GC 回收呢？答案是否定的。因為， GC 在跟蹤程式碼棧中的引用時，會發現 v 引用，而繼續往下跟蹤，就會發現 v 引用指向的記憶體空間中又存在指向 Object 物件的引用。也就是說盡管o 引用已經被置空，但是 Object 物件仍然存在其他的引用，是可以被訪問到的，所以 GC 無法將其釋放掉。如果在此迴圈之後， Object 物件對程式已經沒有任何作用，那麼我們就認為此 Java 程式發生了記憶體洩漏。

2.各種連線，資料庫連線，網路連線，IO連線等沒有顯示呼叫close關閉，不被GC回收導致記憶體洩露。

3.監聽器的使用，在釋放物件的同時沒有相應刪除監聽器的時候也可能導致記憶體洩露。