深入理解 Java垃圾收集器（GC）（待補充full gc，永久代 等內容）

小常識：

提起HotSpot VM，相信所有java程序員都知道，它是SUN JDK和open JDK中所帶的虛擬機，也是目前使用範圍最廣的java虛擬機。其餘比較出名的還有JRockit和J9。

儲備知識點：

線程在進行時往往會出現多次停頓來進行gc，線程停頓的這段時間被稱爲回收週期，而停頓開始的那個時間點叫做安全點，但是每個線程的安全點分佈是不同的，所以需要考慮的問題是如何在GC發生時讓所有線程都“跑”到最近的安全點上再停頓下來？jvm用的是主動式中斷的思想，當GC需要中斷線程的時候，不直接對線程操作，僅僅簡單地設置一個標誌，各個線程執行時主動去輪詢這個標誌，發現中斷標誌爲真時就自己中斷掛起。

但是上面說的全都是正常進行的線程，萬一有線程正處於睡眠狀態，睡眠狀態也算暫停，但是隨時可能甦醒，萬一在gc的時候甦醒容易出現意外情況，但如果我們把這個線程強制喚醒，再讓它運行到下一個安全點又有點不太現實，針對這種情況，就出現了安全區域這個機制。

安全區域是指在我們寫的代碼中，有某些代碼片段的引用關係不會發生變化，那麼在該片段的任何地方發生gc都是安全的，我們就稱這個片段爲安全區域，當線程運行到這個片段會標識出自己在安全區域。

那麼我們再來看剛纔那個問題，如果線程一直處於睡眠狀態，那jvm就會忽略這個線程，反正這個線程也不會影響gc；如果判斷這個線程會在gc中甦醒，那就分兩種情況：①如果線程處於安全區域，jvm同樣會忽略它，因爲線程甦醒後會自動檢測jvm是否在進行gc，從而決定是否要執行到安全區域外②如果線程沒有處於安全區域，那麼jvm會等它甦醒並執行到下一個安全點之後再開始gc。       

  藍字內容都是本人猜想，不一定對，以後會慢慢修改

注意：回收和收集一個意思！！

一、JVM爲什麼要進行垃圾回收？

如果不進行垃圾回收，內存遲早都會被消耗空，因爲我們在不斷的分配內存空間而不進行回收。除非內存無限大，我們可以任性的分配而不回收，但是事實並非如此。所以，垃圾回收是必須的。

二、垃圾收集的定義

(1) GC是垃圾收集的意思（Gabage Collection），Java提供的GC功能可以自動也只能自動地回收堆內存中不再使用的對象，釋放資源（目的），Java語言沒有提供釋放已分配內存的顯式操作方法（gc方法只是通知，不是立即執行）。

 

(2) 對於GC來說，當程序員創建對象時，GC就開始監控這個對象的地址、大小以及使用情況。

 

(3) 垃圾回收是一種動態存儲管理技術，它自動地釋放不再被程序引用的對象，當一個對象不再被引用的時候,按照特定的垃圾收集算法來實現資源自動回收的功能。

    (4)   那什麼時候進行垃圾回收呢？

（1）當jvm空閒時，即沒有線程在運行時，GC會被調用。

（2）Java堆內存不足時，GC會被調用。（3）當然，也由垃圾收集器的算法所決定。

三、我們可以主動垃圾回收嗎？

(1) 每個 Java 應用程序都有一個 Runtime 類實例，使應用程序能夠與其運行的環境相連接。可以通過 getRuntime 方法獲取當前運行。java.lang.System.gc()只是java.lang.Runtime.getRuntime().gc()的簡寫，兩者的行爲沒有任何不同。

 

(2) 唯一的區別就是System.gc()寫起來比Runtime.getRuntime().gc()簡單點. 其實基本沒什麼機會用得到這個命令, 因爲這個命令只是建議JVM安排GC運行, 還有可能完全被拒絕。 GC本身是會週期性的自動運行的,由JVM決定運行的時機,而且現在的版本有多種更智能的模式可以選擇,還會根據運行的機器自動去做選擇,就算真的有性能上的需求,也應該去對GC的運行機制進行微調,而不是通過使用這個命令來實現性能的優化。

四、哪些垃圾需要回收？

哪些垃圾需要回收是垃圾回收機制第一個要考慮的問題，所謂“要回收的垃圾”無非就是那些不可能再被任何途徑使用的對象。那麼如何找到這些對象？

     可達性分析算法（JVM就用這個）

這個算法的基本思想是通過一系列稱爲“GC Roots”的對象作爲起始點，從這些節點向下搜索，搜索所走過的路徑稱爲引用鏈，當一個對象到GC Roots沒有任何引用鏈（即GC Roots到對象不可達）時，則證明此對象是不可用的。

那麼問題又來了，如何選取GCRoots對象呢？在Java語言中，可以作爲GCRoots的對象包括下面幾種：

(1). 虛擬機棧（棧幀中的局部變量區，也叫做局部變量表）中引用的對象。

(2). 方法區中的類靜態屬性引用的對象。

(3). 方法區中常量引用的對象。

(4). 本地方法棧中JNI(Native方法)引用的對象。

這些比較難理解，我也不懂，以後再詳細補充，可以忽略黃色部分

下面給出一個GCRoots的例子，如下圖，爲GCRoots的引用鏈。

由圖可知，obj8、obj9、obj10都沒有到GCRoots對象的引用鏈，即便obj9和obj10之間有引用鏈，他們還是會被當成垃圾處理，可以進行回收（不要問爲什麼，這是可達性分析算法所決定的）。

注意：不光是堆中，方法區也需要垃圾回收：1. 廢棄常量。2. 無用的類。

五、垃圾回收的步驟有哪些呢？

對於可達性分析算法而言，未到達的對象並非是“非死不可”的，若要宣判一個對象死亡（徹底釋放佔用的內存），至少需要經歷兩次標記階段。（對應問題：如果對象的引用被置爲null，垃圾收集器是否會立即釋放對象佔用的內存？）

1. 如果對象在進行可達性分析後發現沒有與GCRoots相連的引用鏈，則該對象被第一次標記並進行一次篩選，篩選條件爲是否有必要執行該對象的finalize方法，若對象沒有覆蓋finalize方法或者該finalize方法是否已經被虛擬機執行過了，則均視作不必要執行該對象的finalize方法，即該對象在下個回收週期將會被回收。反之，若對象覆蓋了finalize方法並且該finalize方法並沒有被執行過，那麼，這個對象會被放置在一個叫F-Queue的隊列中，之後會由虛擬機自動建立的，低優先級的Finalizer線程去執行。

2.對F-Queue中對象進行第二次標記，如果對象在finalize方法中拯救了自己，即關聯上了GCRoots引用鏈，如把this關鍵字賦值給其他變量，那麼在第二次標記的時候該對象將從“即將回收”的集合中移除，如果對象還是沒有拯救自己，那就會被回收。但是，一個對象只能拯救自己一次，第二次就被回收了。

簡單點來說，一旦垃圾收集器準備好釋放對象佔用的存儲空間（進入第一個回收週期），首先會去調用finalize()方法進行一些必要的清理工作，只有到下一次再進行垃圾回收動作（下一個回收週期）的時候，纔會真正釋放這個對象所佔用的內存空間。

補充：

finalize()方法也叫收尾方法。

一旦垃圾回收器準備好釋放對象佔用的存儲空間，首先會去調用finalize()方法①進行一些必要的清理工作（對垃圾回收器不能處理的特殊情況進行處理）（例子在下邊）②也有可能使該對象重新被引用，我習慣叫這種作用爲復活。注意！！每個對象的finalize()方法只能被執行一次，第二次就會直接跳過finalize()方法，這就是爲了防止出現對象無限復活，內存空間只增不減。

一般忽略第二種情況，概念就變成了：一旦垃圾收集器準備好釋放對象佔用的存儲空間（進入第一個回收週期），首先會去調用finalize()方法進行一些必要的清理工作，只有到下一次再進行垃圾回收動作（下一個回收週期）的時候，纔會真正釋放這個對象所佔用的內存空間。

例子：1）由於在分配內存的時候可能採用了類似 C語言的做法，而非JAVA的通常new做法。這種情況主要發生在native method中，比如native method調用了C/C++方法malloc()函數系列來分配存儲空間，但是除非調用free()函數，否則這些內存空間將不會得到釋放，那麼這個時候就可能造成內存泄漏。但是由於free()方法是在C/C++中的函數，所以finalize()中可以用本地方法來調用它。以釋放這些“特殊”的內存空間。2）又或者打開的文件資源，這些資源不屬於垃圾回收器的回收範圍。

System.runFinalization()和System.gc()是做什麼的呢？ 我個人的理解，這兩個函數分別是應用層向JVM發出一個信號，告訴JVM,希望你能儘快的回收內存和調用對象的finaliztion方法，但是隻是一個請求，而JVM只保證會盡最大的努力執行，但是具體什麼時候執行以及會不會執行都是未知的。

六、垃圾收集算法

1、標記-清除（Mark-Sweep）算法

     這是最基礎的算法，標記-清除算法就如同它的名字樣，分爲“標記”和“清除”兩個階段：首先標記出所有需要回收的對象，標記完成後統一回收所有被標記的對象。這種算法的不足主要體現在效率和空間，從效率的角度講，標記和清除兩個過程的效率都不高；從空間的角度講，標記清除後會產生大量不連續的內存碎片， 內存碎片太多可能會導致以後程序運行過程中在需要分配較大對象時，無法找到足夠的連續內存而不得不提前觸發一次垃圾收集動作。標記-清除算法執行過程如圖：

2、複製（Copying）算法

      複製算法是爲了解決效率問題而出現的，它將可用的內存分爲兩塊，每次只用其中一塊，當這一塊內存用完了，就將還存活着的對象複製到另外一塊上面，然後再把已經使用過的內存空間一次性清理掉。這樣每次只需要對整個半區進行內存回收，內存分配時也不需要考慮內存碎片等複雜情況，只需要移動指針，按照順序分配即可。複製算法的執行過程如圖：

     不過這種算法有個缺點，內存縮小爲了原來的一半，這樣代價太高了。現在的商用虛擬機都採用這種算法來回收新生代，不過研究表明1:1的比例非常不科學，因此新生代的內存被劃分爲一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor。

3、標記-整理（Mark-Compact）算法

    複製算法在對象存活率較高的場景下要進行大量的複製操作，效率很低。萬一對象100%存活，那麼需要有額外的空間進行分配擔保。老年代都是不易被回收的對象，對象存活率高，因此一般不能直接選用複製算法。根據老年代的特點，有人提出了另外一種標記-整理算法，過程與標記-清除算法一樣，不過不是直接對可回收對象進行清理，而是讓所有存活對象都向一端移動，然後直接清理掉邊界以外的內存。標記-整理算法的工作過程如圖：

4、分代收集算法

根據上面的內容，用一張圖概括一下堆內存的佈局

現代商用虛擬機基本都採用分代收集算法來進行垃圾回收。這種算法沒什麼特別的，無非是上面內容的結合罷了，根據對象的生命週期的不同將內存劃分爲幾塊，然後根據各塊的特點採用最適當的收集算法。大批對象死去、少量對象存活的（新生代），使用複製算法，複製成本低；對象存活率高、沒有額外空間進行分配擔保的（老年代），採用標記-清理算法或者標記-整理算法。

所有新生成的對象被劃分到年輕代，在年輕代中經歷了N次垃圾回收後仍然存活的對象，就會被放到年老代中，還有一個永久代（1.7以前存在於方法區，存的是類的元數據，永久代對gc影響不大；1.8以後將永久代被移除，取而代之的是“元空間”）

如果說收集算法是內存回收的方法論，那麼垃圾收集器就是內存回收的具體實現。

Java虛擬機規範中對垃圾收集器應該如何實現並沒有任何規定，因此不同的廠商、不同版本的虛擬機所提供的垃圾收集器都可能會有很大差別，並且一般都會提供參數供用戶根據自己的應用特點和要求組合出各個代所使用的收集器。

七、垃圾收集器

jvm是一個進程，垃圾收集器就是一個線程，垃圾收集線程是一個守護線程，優先級低，其在當前系統空閒或堆中老年代佔用率較大時觸發。

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

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

Serial收集器（複製算法)

　　新生代單線程收集器，標記和清理都是單線程，優點是簡單高效。但需要stw，停頓時間長。

Java中Stop-The-World機制簡稱STW，是在執行垃圾收集算法時，Java應用程序的其他所有線程都被掛起。

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

　　老年代單線程收集器，Serial收集器的老年代版本。

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

　　新生代收集器，可以認爲是Serial收集器的多線程版本,在多核CPU環境下有着比Serial更好的表現。

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

　　並行收集器，追求高吞吐量，高效利用CPU。吞吐量一般爲99%， 吞吐量= 用戶線程時間/(用戶線程時間+GC線程時間)。適合後臺應用等對交互相應要求不高的場景。

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

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

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

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

借鑑和引用：

https://www.cnblogs.com/xiaoxi/p/6486852.html

https://blog.csdn.net/hudashi/article/details/52058355