Java垃圾回收機制（GC策略）
核心：1，哪些是垃圾？【怎麼肯定這個是垃圾】；2，如何回收垃圾？【怎麼更好收垃圾】。java
Java語言相對於C++等語言有一個自動垃圾回收機制，只用管使用【實例化對象】，後續的垃圾回收有專門的後勤人員來處理【garbage collection-GC】；可是C++須要在實例化對象以後，還需手動進行垃圾回收，就和學校的自帶餐盤的食堂同樣，吃完飯還須要本身去洗碗筷，收拾一番。算法
1，哪些是垃圾？
1.1 垃圾分類【你是什麼垃圾！】
什麼是垃圾？通俗的講，咱們不會再使用到的東西就是垃圾。這裏須要注意：有些東西咱們可能後續還要使用也可能不會使用，這個就如同曹丞相口中的【雞肋】通常，因此這裏的垃圾也是分層次的，對象都是介於垃圾與非垃圾之間的東西。緩存
備註：假設1表示非垃圾，0表示垃圾，那麼這些實例化對象就是屬於[0,1]之間的類別。負載均衡
①垃圾成因jvm
1 package _3垃圾的分類; 2 3 public class GC1 {//對象失去索引稱爲垃圾 4 public static void main(String[] args) { 5 ObjString objString = new ObjString("hello"); 6 System.out.println(objString); 7 objString = null; 8 System.out.println(objString); 9 } 10 } 11 /* 12 ObjString: hello 13 null 14 */
②主動調用System.gc()進行垃圾空間處理ide
1 package _3垃圾的分類; 2 3 public class GC2 {//對象失去索引稱爲垃圾，調用GC處理 4 public static void main(String[] args) { 5 ObjString str = new ObjString("hello"); 6 ObjString str1 = new ObjString("world"); 7 System.out.println(str); 8 System.out.println(str1); 9 str = null; 10 str1 = null; 11 System.gc();//本質Runtime.getRuntime().gc(); 12 } 13 } 14 /* 15 ObjString: hello 16 ObjString: world 17 2垃圾回收 18 1垃圾回收 19 */
③內存空間不足，JVM自動調用GC處理性能
1 package _3垃圾的分類; 2 3 public class GC3 {//對象失去索引稱爲垃圾， 4 public static void main(String[] args) { 5 ObjString objString = new ObjString("hello"); 6 System.out.println(objString); 7 objString = null; 8 String[] array = new String[1024 * 500]; 9 for(int i = 0; i < 1024 * 500; i++) {//系統消耗大量內存，JVM須要進行內存回收 10 for(int j = 'a'; j <= 'z'; j++) { 11 array[i] += (char)j; 12 } 13 } 14 } 15 } 16 /* 17 ObjString: hello 18 1垃圾回收 19 */
④強引用對象，不是垃圾！this
1 package _3垃圾的分類; 2 3 public class GC4 {//①強引用，對象有索引存在，不是垃圾 4 public static void main(String[] args) { 5 ObjString objString = new ObjString("hello"); 6 System.out.println(objString); 7 System.gc(); 8 } 9 } 10 /* 11 ObjString: hello 12 */
⑤軟引用對象，內存不足的時候是垃圾，內存足夠的時候不是垃圾；depend on內存條件url
1 package _3垃圾的分類; 2 3 import java.lang.ref.SoftReference; 4 /* 5 ObjString objString = new ObjString(); 6 If(JVM.內存不足()) { 7 objString = null;//將該對象一併轉換爲垃圾 8 System.gc(); 9 } 10 */ 11 public class GC5 {//②軟引用，當系統內存不足的時候回收 12 public static void main(String[] args) { 13 SoftReference ref = new SoftReference(new ObjString("這是一個軟引用實例化對象")); 14 System.out.println(ref.get()); 15 // System.gc(); 16 String[] array = new String[1024 * 500]; 17 for(int i = 0; i < 1024 * 500; i++) {//系統消耗大量內存，JVM須要進行內存回收 18 for(int j = 'a'; j <= 'z'; j++) { 19 array[i] += (char)j; 20 } 21 } 22 } 23 } 24 /* 25 ObjString: 這是一個軟引用實例化對象 26 1垃圾回收 27 */
⑥弱引用是垃圾，當JVM垃圾回收的時候進行處理spa
1 package _3垃圾的分類; 2 3 import java.lang.ref.WeakReference ; 4 /* 5 等同於： 6 ObjString objString = new ObjString(); 7 if(JVM觸發垃圾回收操做){ 8 objString = null;//強制轉換爲垃圾 9 System.gc();//進行回收 10 } 11 */ 12 public class GC6 {//③弱引用，當JVM垃圾回收的時候進行處理 13 public static void main(String[] args) { 14 WeakReference ref = new WeakReference (new ObjString("這是一個弱引用實例化對象")); 15 System.out.println(ref.get()); 16 System.gc(); 17 } 18 } 19 /* 20 ObjString: 這是一個弱引用實例化對象 21 1垃圾回收 22 */
⑦假象引用，在實例化後就被置空拋棄！！！ ，就被終止回收
1 package _3垃圾的分類; 2 3 import java.lang.ref.PhantomReference; 4 import java.lang.ref.ReferenceQueue; 5 /* 6 等同於： 7 ObjString objString = new ObjString(); 8 objString = null; 9 */ 10 public class GC7 {//④假象引用，在實例化後就被置空拋棄！！！ ，就被終止回收 11 public static void main(String[] args) { 12 ReferenceQueue queue = new ReferenceQueue();//假象引用必須和ReferenceQueue聯合使用 13 PhantomReference ref = new PhantomReference(new ObjString("這是一個弱引用實例化對象"), queue); 14 System.out.println(ref.get()); 15 System.gc(); 16 } 17 } 18 /* 19 null 20 1垃圾回收 21 */
1.2 怎麼定義垃圾【你是否是垃圾!】
前一小節定義了垃圾分類，這一小結咱們來看看【你是否是垃圾】。沒有索引不可以被從新使用的對象！系統沒法從新複用這個對象了！
這裏有兩種方法來肯定失去索引的對象，是不是垃圾！①引用計數法；②可達性分析法；
1.2.1 引用計數法
引用計數算法（Reachability Counting）是經過在對象頭中分配一個空間來保存該對象被引用的次數（Reference Count）。若是該對象被其它對象引用，則它的引用計數加1，若是刪除對該對象的引用，那麼它的引用計數就減1，當該對象的引用計數爲0時，那麼該對象就會被回收。
String m = new String("jack");
先建立一個字符串，這時候"jack"有一個引用，就是 m。
圖1 引用計數原理圖【初始化】
圖2 引用計數原理圖【索引置空】
可是這樣作也有一個問題出現-交織空引用。首先兩個對象互相引用；以後，兩個索引都置空；可是RC並不等於零，由於他們交織引用了對方。這就形成了本應該是垃圾的對象，沒法被斷定爲垃圾，沒法收回！！！
圖3 空索引-交織引用
ReferenceGC.java
1 package _1引用計數算法; 2 3 class ReferenceGC{ 4 private int counter=0;//對象的索引數 5 public Object Root=null;//操做的對象 6 public Object instance=null; 7 public ReferenceGC(Object object){ 8 this.Root=object; 9 } 10 public void add(){//模擬計數器增長 11 this.counter++; 12 } 13 public void sub(){//模擬計數器減小 14 this.counter--; 15 } 16 public int getCounter() { 17 return this.counter; 18 } 19 }
testGC.java
1 package _1引用計數算法; 2 3 public class testGC { 4 public static void main(String[] args) { 5 ReferenceGC a=new ReferenceGC("Obj_A"); 6 ReferenceGC b=new ReferenceGC("Obj_B"); 7 8 String str1=(String) a.Root;//①對象第一次有索引 9 String str2=(String) b.Root; 10 a.add(); 11 b.add(); 12 a.instance=b.Root;//②對象互相引用 13 b.instance=a.Root; 14 a.add(); 15 b.add(); 16 a.Root=null; 17 b.Root=null; 18 a.sub(); 19 b.sub(); 20 System.out.println("a.instance="+a.instance+",b.instance="+b.instance); 21 System.out.println("a.getCounter()="+a.getCounter()+",b.getCounter()="+a.getCounter()); 22 } 23 } 24 /* 25 a.instance=Obj_B,b.instance=Obj_A 26 a.getCounter()=1,b.getCounter()=1 27 */
1.2.2 可達性分析法
可達性分析算法（Reachability Analysis）的基本思路是，經過一些被稱爲垃圾回收根（GC Roots）的對象做爲起點，從這些節點開始向下搜索，搜索走過的路徑被稱爲引用鏈（Reference Chain)，當一個對象到 GC Roots 沒有任何引用鏈相連時（即從 GC Roots 節點到該節點不可達），則證實該對象是不可用的。
圖4 可達性分析法
經過可達性算法，成功解決了引用計數所沒法解決的問題-「循環依賴」，只要你沒法與 GC Root 創建直接或間接的鏈接，系統就會斷定你爲可回收對象。那這樣就引伸出了另外一個問題，哪些屬於 GC Root。
在 Java 語言中，可做爲 GC Root 的對象包括如下4種：
- ①虛擬機棧（棧幀中的本地變量表）中引用的對象
- ②方法區中類靜態屬性引用的對象
- ③方法區中常量引用的對象
- ④本地方法棧中 JNI（即通常說的 Native 方法）引用的對象
圖5 Java內存區域
一、虛擬機棧（棧幀中的本地變量表）中引用的對象
此時的 s，即爲 GC Root，當s置空時，localParameter 對象也斷掉了與 GC Root 的引用鏈，將被回收。
StackLocalParameter.java
1 package _2可達性分析算法; 2 3 class StackLocalParameter { 4 public StackLocalParameter(String name){} 5 @Override 6 protected void finalize() throws Throwable { 7 System.out.println("垃圾回收"); 8 } 9 10 public static void testGC(){ 11 StackLocalParameter s = new StackLocalParameter("localParameter"); 12 s = null; 13 } 14 }
TestGC1.java
1 package _2可達性分析算法; 2 3 public class TestGC1 { 4 public static void main(String[] args) { 5 StackLocalParameter.testGC(); 6 System.gc(); 7 } 8 }
二、方法區中類靜態屬性引用的對象
s 爲 GC Root，s 置爲 null，通過 GC 後，s 所指向的 properties 對象因爲沒法與 GC Root 創建關係被回收。
而 m 做爲類的靜態屬性，也屬於 GC Root，parameter 對象依然與 GC root 創建着鏈接，因此此時 parameter 對象並不會被回收。
MethodAreaStaicProperties.java【其中parameter並無進行垃圾回收】
1 package _2可達性分析算法; 2 3 public class MethodAreaStaicProperties { 4 public static MethodAreaStaicProperties m; 5 public MethodAreaStaicProperties(String name){} 6 @Override 7 protected void finalize() throws Throwable { 8 System.out.println("垃圾回收"); 9 } 10 public static void testGC(){ 11 MethodAreaStaicProperties s = new MethodAreaStaicProperties("properties"); 12 MethodAreaStaicProperties s1 = new MethodAreaStaicProperties("properties"); 13 s.m = new MethodAreaStaicProperties("parameter"); 14 s = null; 15 s1 = null; 16 } 17 }
TestGC2.java
1 package _2可達性分析算法; 2 3 public class TestGC2 { 4 public static void main(String[] args) { 5 MethodAreaStaicProperties.testGC(); 6 System.gc(); 7 } 8 }
三、方法區中常量引用的對象
m 即爲方法區中的常量引用，也爲 GC Root，s 置爲 null 後，final 對象也不會因沒有與 GC Root 創建聯繫而被回收。
MethodAreaStaicProperties1.java
1 package _2可達性分析算法; 2 3 public class MethodAreaStaicProperties1 { 4 public static final MethodAreaStaicProperties1 m = new MethodAreaStaicProperties1("final");//常量索引，沒法修改 5 private String name; 6 public MethodAreaStaicProperties1(String name){ 7 this.name=name; 8 } 9 @Override 10 protected void finalize() throws Throwable { 11 System.out.println("垃圾回收"); 12 } 13 public static void testGC(){ 14 MethodAreaStaicProperties s = new MethodAreaStaicProperties("staticProperties"); 15 s = null; 16 } 17 }
TestGC3.java
1 package _2可達性分析算法; 2 3 public class TestGC3 { 4 public static void main(String[] args) { 5 MethodAreaStaicProperties1.testGC(); 6 System.gc(); 7 } 8 }
四、本地方法棧中引用的對象
任何 native 接口都會使用某種本地方法棧，實現的本地方法接口是使用 C 鏈接模型的話，那麼它的本地方法棧就是 C 棧。當線程調用 Java 方法時，虛擬機會建立一個新的棧幀並壓入 Java 棧。然而當它調用的是本地方法時，虛擬機會保持 Java 棧不變，再也不在線程的 Java 棧中壓入新的幀，虛擬機只是簡單地動態鏈接並直接調用指定的本地方法。
圖6 調用Java方法和本地方法
2，如何回收垃圾？
上文已經肯定標定了垃圾，後續要如何清理呢？【高效、快速、節能】
在肯定了哪些垃圾能夠被回收後，垃圾收集器要作的事情就是開始進行垃圾回收，可是這裏面涉及到一個問題是：如何高效地進行垃圾回收。因爲Java虛擬機規範並無對如何實現垃圾收集器作出明確的規定，所以各個廠商的虛擬機能夠採用不一樣的方式來實現垃圾收集器，這裏咱們討論幾種常見的垃圾收集算法的核心思想：①標記-清除法；②複製算法；③標記整理算法；④內存模型與回收策略
2.1 標記-清除法
標記清除算法（Mark-Sweep）是最基礎的一種垃圾回收算法，它分爲2部分，先把內存區域中的這些對象進行標記，哪些屬於可回收標記出來，而後把這些垃圾拎出來清理掉。就像上圖同樣，清理掉的垃圾就變成未使用的內存區域，等待被再次使用。
這邏輯再清晰不過了，而且也很好操做，但它存在一個很大的問題，那就是內存碎片。
上圖中等方塊的假設是 2M，小一些的是 1M，大一些的是 4M。等咱們回收完，內存就會切成了不少段。咱們知道開闢內存空間時，須要的是連續的內存區域，這時候咱們須要一個 2M的內存區域，其中有2個 1M 是無法用的。這樣就致使，其實咱們自己還有這麼多的內存的，但卻用不了。
圖7 標記-清除法
優勢：簡單快捷；缺點：內存碎片化嚴重
2.2 複製算法
複製算法（Copying）是在標記清除算法上演化而來，解決標記清除算法的內存碎片問題。它將可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活着的對象複製到另一塊上面，而後再把已使用過的內存空間一次清理掉。保證了內存的連續可用，內存分配時也就不用考慮內存碎片等複雜狀況，邏輯清晰，運行高效。
上面的圖很清楚，也很明顯的暴露了另外一個問題，合着我這140平的大三房，只能當70平米的小兩房來使？代價實在過高。
圖8 複製算法
優勢：內存碎片化問題獲得部分解決；缺點：內存的有效使用率過低。
2.3 標記整理(清除)算法
標記整理算法（Mark-Compact）標記過程仍然與標記 --- 清除算法同樣，但後續步驟不是直接對可回收對象進行清理，而是讓全部存活的對象都向一端移動，再清理掉端邊界之外的內存區域。
標記整理算法一方面在標記-清除算法上作了升級，解決了內存碎片的問題，也規避了複製算法只能利用一半內存區域的弊端。看起來很美好，但從上圖能夠看到，它對內存變更更頻繁，須要整理全部存活對象的引用地址，在效率上比複製算法要差不少。
圖9 標記-整理-清除算法
優勢：解決內存碎片化問題而且內存利用率大大提升；缺點：內存須要不斷地變更，效率變低。
2.4 分代收集算法分代收集算法
分代收集算法分代收集算法（Generational Collection）-【GC】嚴格來講並非一種思想或理論，而是融合上述3種基礎的算法思想，而產生的針對不一樣狀況所採用不一樣算法的一套組合拳。對象存活週期的不一樣將內存劃分爲幾塊。通常是把 Java 堆分爲新生代和老年代，這樣就能夠根據各個年代的特色採用最適當的收集算法。在新生代中，每次垃圾收集時都發現有大批對象死去，只有少許存活，那就選用複製算法，只須要付出少許存活對象的複製成本就能夠完成收集。而老年代中由於對象存活率高、沒有額外空間對它進行分配擔保，就必須使用標記-清理或者標記 --- 整理算法來進行回收。so，另外一個問題來了，那內存區域到底被分爲哪幾塊，每一塊又有什麼特別適合什麼算法呢？
3 Java內存模型與回收策略
Java 堆（Java Heap）是JVM所管理的內存中最大的一塊，堆又是垃圾收集器管理的主要區域，這裏咱們主要分析一下 Java 堆的結構。
圖10 Java堆結構
Java 堆主要分爲2個區域-年輕代與老年代，其中年輕代又分 Eden 區和 Survivor 區，其中 Survivor 區又分 From 和 To 2個區。可能這時候你們會有疑問，爲何須要 Survivor 區，爲何Survivor 還要分2個區。不着急，咱們從頭至尾，看看對象究竟是怎麼來的，而它又是怎麼沒的。
3.1 Eden 區
IBM 公司的專業研究代表，有將近98%的對象是朝生夕死，因此針對這一現狀，大多數狀況下，對象會在新生代 Eden 區中進行分配，當 Eden 區沒有足夠空間進行分配時，虛擬機會發起一次 Minor GC【小型回收】，Minor GC 相比 Major GC【大型回收】 更頻繁，回收速度也更快。
經過 Minor GC 以後，Eden 會被清空，Eden 區中絕大部分對象會被回收，而那些無需回收的存活對象，將會進到 Survivor 的 From 區（若 From 區不夠，則直接進入 Old 區）。
3.2 Survivor 區
Survivor 區至關因而 Eden 區和 Old 區的一個緩衝，相似於咱們交通燈中的黃燈。Survivor 又分爲2個區，一個是 From 區，一個是 To 區。每次執行 Minor GC，會將 Eden 區和 From 存活的對象放到 Survivor 的 To 區（若是 To 區不夠，則直接進入 Old 區）。
一、爲啥須要？
不就是新生代到老年代麼，直接 Eden 到 Old 很差了嗎，爲啥要這麼複雜。想一想若是沒有 Survivor 區，Eden 區每進行一次 Minor GC，存活的對象就會被送到老年代，老年代很快就會被填滿。而有不少對象雖然一次 Minor GC 沒有消滅，但其實也並不會蹦躂多久，或許第二次，第三次就須要被清除。這時候移入老年區，很明顯不是一個明智的決定。
因此，Survivor 的存在乎義就是減小被送到老年代的對象，進而減小 Major GC 的發生。Survivor 的預篩選保證，只有經歷16次 Minor GC 還能在新生代中存活的對象，纔會被送到老年代。
二、爲啥須要倆？
設置兩個 Survivor 區最大的好處就是解決內存碎片化。
咱們先假設一下，Survivor 若是隻有一個區域會怎樣。Minor GC 執行後，Eden 區被清空了，存活的對象放到了 Survivor 區，而以前 Survivor 區中的對象，可能也有一些是須要被清除的。問題來了，這時候咱們怎麼清除它們？在這種場景下，咱們只能標記清除，而咱們知道標記清除最大的問題就是內存碎片，在新生代這種常常會消亡的區域，採用標記清除必然會讓內存產生嚴重的碎片化。由於 Survivor 有2個區域，因此每次 Minor GC，會將以前 Eden 區和 From 區中的存活對象複製到 To 區域。第二次 Minor GC 時，From 與 To 職責兌換，這時候會將 Eden 區和 To 區中的存活對象再複製到 From 區域，以此反覆。
這種機制最大的好處就是，整個過程當中，永遠有一個 Survivor space 是空的，另外一個非空的 Survivor space 是無碎片的。那麼，Survivor 爲何不分更多塊呢？比方說分紅三個、四個、五個?顯然，若是 Survivor 區再細分下去，每一塊的空間就會比較小，容易致使 Survivor 區滿，兩塊 Survivor 區多是通過權衡以後的最佳方案。
3.3 Old 區
老年代佔據着2/3的堆內存空間，只有在 Major GC 的時候纔會進行清理，每次 GC 都會觸發「Stop-The-World」。內存越大，STW 的時間也越長，因此內存也不只僅是越大就越好。因爲複製算法在對象存活率較高的老年代會進行不少次的複製操做，效率很低，因此老年代這裏採用的是標記 --- 整理算法。
除了上述所說，在內存擔保機制下，沒法安置的對象會直接進到老年代，如下幾種狀況也會進入老年代。
一、大對象
大對象指須要大量連續內存空間的對象，這部分對象無論是否是「朝生夕死」，都會直接進到老年代。這樣作主要是爲了不在 Eden 區及2個 Survivor 區之間發生大量的內存複製。當你的系統有很是多「朝生夕死」的大對象時，得注意了。
二、長期存活對象
虛擬機給每一個對象定義了一個對象年齡（Age）計數器。正常狀況下對象會不斷的在 Survivor 的 From 區與 To 區之間移動，對象在 Survivor 區中每經歷一次 Minor GC，年齡就增長1歲。當年齡增長到15歲時，這時候就會被轉移到老年代。固然，這裏的15，JVM 也支持進行特殊設置。
三、動態對象年齡
虛擬機並不重視要求對象年齡必須到15歲，纔會放入老年區，若是 Survivor 空間中相同年齡全部對象大小的綜合大於 Survivor 空間的通常，年齡大於等於該年齡的對象就能夠直接進去老年區，無需等你「成年」。
這其實有點相似於負載均衡，輪詢是負載均衡的一種，保證每臺機器都分得一樣的請求。看似很均衡，但每臺機的硬件不通，健康情況不一樣，咱們還能夠基於每臺機接受的請求數，或每臺機的響應時間等，來調整咱們的負載均衡算法。
4 Stop-The-World
在新生代進行的GC叫作minor GC，在老年代進行的GC都叫major GC，Full GC同時做用於新生代和老年代。在垃圾回收過程當中常常涉及到對對象的挪動（好比上文提到的對象在Survivor 0和Survivor 1之間的複製），進而致使須要對對象引用進行更新。爲了保證引用更新的正確性，Java將暫停全部其餘的線程，這種狀況被稱爲「Stop-The-World」，致使系統全局停頓。Stop-The-World對系統性能存在影響，所以垃圾回收的一個原則是儘可能減小「Stop-The-World」的時間。
不一樣垃圾收集器的Stop-The-World狀況，Serial、Parallel和CMS收集器均存在不一樣程度的Stop-The-Word狀況；而即使是最新的G1收集器也不例外。
-
Java中一種全局暫停的現象,jvm掛起狀態
-
全局停頓，全部Java代碼中止，native代碼能夠執行，但不能和JVM交互
-
多半因爲jvm的GC引發，如：
1.老年代空間不足。
2.永生代（jkd7）或者元數據空間（jkd8）不足。
3.System.gc()方法調用。
4.CMS GC時出現promotion failed和concurrent mode failure
5.YoungGC時晉升老年代的內存平均值大於老年代剩餘空間
6.有連續的大對象須要分配 -
除了GC還有如下緣由：
1.Dump線程--人爲因素。
2.死鎖檢查。
3.堆Dump--人爲因素。
Full GC 是清理整個堆空間—包括年輕代和老年代。
4.1 GC時爲何會有全局停頓？
類比在聚會時打掃房間，聚會時很亂，又有新的垃圾產生，房間永遠打掃不乾淨，只有讓你們中止活動了，才能將房間打掃乾淨。當gc線程在處理垃圾的時候，其它java線程要中止才能完全清除乾淨，不然會影響gc線程的處理效率增長gc線程負擔，特別是在垃圾標記的時候。
4.2 危害
-
長時間服務中止，沒有響應
-
遇到HA系統，可能引發主備切換，嚴重危害生產環境。
-
新生代的gc時間比較短（），危害小。
-
老年代的gc有時候時間短，可是有時候比較長几秒甚至100秒--幾十分鐘都有。
-
堆越大花的時間越長。