深刻理解Java垃圾回收機制

1、垃圾回收機制的概念

　　垃圾回收（GC）是Java虛擬機（JVM）垃圾回收器提供的一種用於在空閒時間不定時回收無任何對象引用的對象所佔據的內存空間的一種機制。

　　引用：若是Reference類型的數據中存儲的數值表明的是另一塊內存的起始地址，就稱這塊內存表明着一個引用。

　　引用又分爲強引用、軟引用、弱引用、虛引用四種：

　　強引用（Strong Reference）：如「Object obj = new Object（）」，這類引用是java中最廣泛的，只要強引用還存在，垃圾收集器就永遠不會回收掉被引用的對象，無論內存是否夠用。

　　軟引用（Soft Reference）：它用來描述一種可能有用，但不是必須的對象，在系統內存不夠用時，這類引用會在垃圾收集器下一次回收垃圾時被回收。

　　弱引用（Weak Reference）：它是用來描述非必須的對象，但它的強度比軟引用更弱些，被弱引用關聯的對象只能生存到下一次垃圾收集器回收垃圾以前，不論系統內存是否夠用，都會回收掉只被弱引用關聯的對象。

　　虛引用（Phantom Reference）：最弱的一種引用關係，徹底不會對其生存時間構成影響，也沒法經過虛引用來取得一個對象實例。爲一個對象設置虛引用的惟一目的就是但願能在這個對象被收集器回收時收到一個系統通知。

 

2、垃圾回收機制的意義

　　垃圾回收能夠有效的防止內存泄露（memory leak）、內存溢出（out of memory），有效的使用空閒的內存。

　　內存泄漏：是指程序在申請內存後，沒法釋放已申請的內存空間，一次內存泄漏彷佛不會有大的影響，但內存泄漏堆積後的後果就是內存溢出。

　　內存溢出：指程序申請內存時，沒有足夠的內存供申請者使用，或者說，給了你一塊存儲int類型數據的存儲空間，可是你卻存儲long類型的數據，那麼結果就是內存不夠用，此時就會報錯OOM,即所謂的內存溢出。 

　　通俗的說就是停車場（堆）保安（gc）讓好久不用的廢棄車子(無用的對象)從車位上挪走，可是這個車子又沒辦法挪走。這就是內存泄漏。停車場全部的車位都有車子佔用了，再來車子沒地了，或者說給你一個小汽車的停車位（int），你非要停一輛高鐵(Long)，這就是內存溢出。

　　內存泄露量大到必定程度會致使內存溢出。可是內存溢出不必定是內存泄露引發的。

　　常見的內存泄漏：

　　一、單例形成的內存泄漏

　　因爲單例的靜態特性，使得它的生命週期和應用的生命週期同樣長，若是一個對象已經再也不須要使用了，而單例對象還持有該對象的引用，就會使該對象不能被正確的回收，從而致使內存泄漏。

　　

　　二、非靜態內部類建立靜態實例形成的內存泄漏

　　非靜態內部類默認會持有外部類的引用，而該非靜態內部類又建立了一個靜態的實例，該實例的生命週期和應用同樣長，這就致使了該靜態實例一直會持有該Activity的引用，從而致使Activity的內存資源不能被正確回收。

　　

　　　三、Handler形成的內存泄漏

　　handler發送的消息在當前handler的消息隊列中，若是此時activity finish掉了，那麼消息隊列的消息依舊會由handler進行處理，若此時handler聲明爲內部類（非靜態內部類），咱們知道內部類自然持有外部類的實例引用，那麼就會致使activity沒法回收，進而致使activity泄露。

　　四、線程形成的內存泄漏

　　若是任務在Activity銷燬以前還未完成，那麼將致使Activity的內存資源沒法被回收，從而形成內存泄漏。

　　

　　五、資源未關閉，形成內存泄漏

 　　對於使用了BraodcastReceiver, ContentObserver, File, Cursor, Stream, Bitmap 等資源，立垓在Activity銷毀肘及吋美閉或者注銷，否則込些湊源將不會被回收，從而形成內存泄漏。

　　六、使用ListView吋形成的內存泄漏

　　　構造Adapter時，沒有使用緩存的convertView，Adapter中引用了Activity如何避免內存泄漏。

　有時須要點擊ListView條目裏的某個按鈕實現界面跳轉，getView()方法inflate佈局的時候須要上下文，並且點擊按鈕後的跳轉邏輯也須要上下文。因此咱們常常會把Activity傳入到Adapter中，若是Adapter中有不少耗時操做，可能就會防止Activity finish的時候被回收。

　　 七、集合容器中的內存泄露

　　咱們一般把一些對象的引用加入到了集合容器（好比ArrayList）中，當咱們不須要該對象時，並無把它的引用從集合中清理掉，這樣這個集合就會愈來愈大。若是這個集合是static的話，那狀況就更嚴重了。

　　八、WebView 形成的泄露 

　　當咱們不要使用WebView對象時，應該調用它的destory()函數來銷燬它，並釋放其佔用的內存，不然其長期佔用的內存也不能被回收，從而形成內存泄露。

內存泄漏與解決辦法詳解：https://www.jianshu.com/p/90caf813682d

　　常見內存溢出： 

1.內存中加載的數據量過於龐大，如一次從數據庫取出過多數據； 
2.集合類中有對對象的引用，使用完後未清空，使得JVM不能回收； 
3.代碼中存在死循環或循環產生過多重複的對象實體； 
4.使用的第三方軟件中的BUG； 
5.啓動參數內存值設定的太小

內存溢出的解決方案： 

第一步，修改JVM啓動參數，直接增長內存。(-Xms，-Xmx參數必定不要忘記加。)

第二步，檢查錯誤日誌，查看「OutOfMemory」錯誤前是否有其 它異常或錯誤。

第三步，對代碼進行走查和分析，找出可能發生內存溢出的位置。

3、垃圾回收機制的算法

　　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引用計數算法沒法解決循環引用問題，例如：

1 2 3 4 5 6 7 8 9 10 11 12

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 追求高響應時間的選擇

 

5、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的各域分配策略動態變化

 

6、Java有了GC一樣會出現內存泄露問題

　　1.靜態集合類像HashMap、Vector等的使用最容易出現內存泄露，這些靜態變量的生命週期和應用程序一致，全部的對象Object也不能被釋放，由於他們也將一直被Vector等應用着。

1 2 3 4 5 6 7

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.監聽器的使用，在釋放對象的同時沒有相應刪除監聽器的時候也可能致使內存泄露。

 

 

參考：http://www.javashuo.com/article/p-mphjinep-n.html