本文已收錄至Github，推薦閱讀 ?? Java隨想錄
微信公眾號：Java隨想錄
CSDN： 碼農BookSea
目錄知道的越多，才知知道的越少，——蘇格拉底
- 參考計數演算法
- 可達性分析演算法
- 參考型別
- Dead Or Alive
- 永久代真的"永久"嗎？
- 垃圾收集演算法
- 標記-清除演算法
- 標記-復制演算法
- 標記-整理演算法
- 標記-清除 VS 標記-整理
在堆里面存放著Java世界中幾乎所有的物件實體，垃圾收集器在對堆進行回收前，第一件事情就是要確定這些物件之中哪些還“存活”著，哪些已經“死去”（“死去”即不可能再被任何途徑使用的物件）了，
下文圍繞這個話題，展開聊聊，
參考計數演算法
這種演算法的作業原理是這樣的：在物件中添加一個參考計數器，每當有一個地方參考它時，計數器值就加一；當參考失效時，計數器值就減一；任何時刻計數器為零的物件就是不可能再被使用的，客觀的說，參考計數演算法雖然占用了一些額外的記憶體空間來計數，但原理簡單，效率也很高，但是目前主流的Java虛擬機里面都沒有選用參考計數法來進行記憶體管理，主要原因是，參考計數演算法很難解決物件之間相互回圈參考的問題，
舉個例子：
public class MyObject {
public Object ref = null;
public static void main(String[] args) {
MyObject myObject1 = new MyObject();
MyObject myObject2 = new MyObject();
myObject1.ref = myObject2;
myObject2.ref = myObject1;
myObject1 = null;
myObject2 = null;
}
}
myObject1和myObject2這兩個物件再無任何參考，實際上這兩個物件已經不可能再被訪問，但是它們因為互相參考著對方，導致它們的參考計數都不為零，參考計數演算法也就無法回收它們，這就是回圈參考問題，
HotSpot虛擬機并不是通過參考計數演算法來判斷物件是否存活的，使用的是可達性分析演算法，
可達性分析演算法
JVM通過可達性分析（Reachability Analysis）演算法來判定物件是否存活的，這個演算法的基本思路就是通過一系列稱為GC Roots的根物件作為起始節點集，從這些節點開始，根據參考關系向下搜索，搜索程序所走過的路徑稱為參考鏈（Reference Chain），如果某個物件到GC Roots間沒有任何參考鏈相連，或者用圖論的話來說就是從GC Roots到這個物件不可達時，則證明此物件是不可能再被使用的，
如圖，物件object 5、object 6、object 7到GC Roots是不可達的，因此它們將會被判定為可回收的物件，
在Java技術體系里面，固定可以作為GC Roots的物件包括以下幾種
- 在虛擬機堆疊（堆疊中 的本地變數表）中參考的物件，例如各個執行緒被呼叫的方法堆疊中使用到的引數、區域變數、臨時變數等，
- 在方法區中常量參考的物件，例如字串常量池（String Table）里的參考，
- 在本地方法堆疊中JNI（本地方法）參考的物件，
- Java虛擬機內部的參考，如基本資料型別對應的Class物件，一些常駐的例外物件（NullPointException、OutOfMemoryError）等，以及系統類加載器，
- 所有被同步鎖（synchronized）持有的物件，
- 反映Java虛擬機內部情況的JMXBean、JVMTI中注冊的回呼、本地代碼快取等，
目前所有的垃圾收集器在根節點列舉這一步驟時都是必須暫停用戶執行緒的，這里面細講東西很多，先埋個坑，之后出篇文章來講根節點列舉，
參考型別
Java將參考分為強參考（Strongly Re-ference）、軟參考（Soft Reference）、弱參考（Weak Reference）和虛參考（Phantom Reference）4種，這4種參考強度依次逐漸減弱，
- 強參考是最傳統的“參考”的定義，是指在程式代碼之中普遍存在的參考賦值，即類似
Object obj=new Object()這種參考關系，無論任何情況下，只要強參考關系還存在，垃圾收集器就永遠不會回收掉被參考的物件， - 軟參考是用來描述一些還有用，但非必須的物件，只被軟參考關聯著的物件，在系統將要發生記憶體溢位例外前，會把這些物件列進回收范圍之中進行第二次回收，如果這次回識訓沒有足夠的記憶體，才會拋出記憶體溢位例外，在JDK 1.2版之后提供了SoftReference類來實作軟參考，
- 弱參考也是用來描述那些非必須物件，但是它的強度比軟參考更弱一些，被弱參考關聯的物件只能生存到下一次垃圾收集發生為止，當垃圾收集器開始作業，無論當前記憶體是否足夠，都會回收掉只被弱參考關聯的物件，在JDK 1.2版之后提供了WeakReference類來實作弱參考，
- 虛參考也稱為“幽靈參考”或者“幻影參考”，它是最弱的一種參考關系，一個物件是否有虛參考的存在，完全不會對其生存時間構成影響，也無法通過虛參考來取得一個物件實體，為一個物件設定虛參考關聯的唯一目的只是為了能在這個物件被收集器回收時收到一個系統通知，在JDK 1.2版之后提供了PhantomReference類來實作虛參考，
總結一句話就是：強參考記憶體不足也不會回收，軟參考記憶體不足才回收，弱參考和虛參考看見就回收，
Dead Or Alive
在可達性分析演算法中判定為不可達的物件，就"非死不可"嗎？
當一個物件被判斷為不可達的時候，這時候該物件處在“緩刑”階段，要真正宣告一個物件死亡，至少要經歷兩次標記程序：
如果物件在進行可達性分析后發現沒有與GC Roots相連接的參考鏈，那它將會被第一次標記，隨后進行一次篩選，篩選的條件是此物件是否有必要執行finalize()方法，假如物件沒有覆寫finalize()方法，或者finalize()方法已經被虛擬機呼叫過，那么虛擬機將這兩種情況都視為“沒有必要執行”，
如果這個物件被判定為確有必要執行finalize()方法，那么該物件將會被放置在一個名為F-Queue的佇列之中，并在稍后由一條由虛擬機自動建立的、低調度優先級的Finalizer執行緒去執行它們的finalize()方法，
這里所說的“執行”是指虛擬機會觸發這個方法開始運行，但并不承諾一定會等待它運行結束，這樣做的原因是，如果某個物件finalize()方法執行緩慢，或者更極端地發生了死回圈，將很可能導致F-Queue佇列中的其他物件永久處于等待，甚至導致整個記憶體回收子系統的崩潰，finalize()方法是物件逃脫死亡命運的最后一次機會，稍后收集器將對F-Queue中的物件進行第二次小規模的標記，如果物件要在finalize()中成功拯救自己——只要重新與參考鏈上的任何一個物件建立關聯即可，譬如把自己（this關鍵字）賦值給某個類變數或者物件的成員變數，那在第二次標記時它將被移出“即將回收”的集合；如果物件這時候還沒有逃脫，那基本上它就真的要被回收了，
需要注意的是：任何一個物件的finalize()方法都只會被系統自動呼叫一次，如果物件面臨下一次回收，它的finalize()方法不會被再次執行，我只能救你一次，剩下的就靠你自己了，
看起來物件能夠使用finalize()方法實作自我救贖，然而這個方法并沒有什么用，放一段書里的原話，
總結一下，就是finalize()這個方法并沒什么卵用，
永久代真的"永久"嗎？
有些人認為方法區（如HotSpot虛擬機中的元空間或者永久代）是沒有垃圾收集行為的，但其實方法區是可以被回收的，只不過回收的判定條件過于苛刻，垃圾收集的成果很差，
并不是名字叫永久代就真的"永久"了，
我們先搞清楚方法區要回收的是什么，方法區的垃圾收集主要回收兩部分內容：廢棄的常量和不再使用的型別，
判定一個常量是否“廢棄”還是相對簡單，而要判定一個型別是否屬于“不再被使用的類”的條件就比較苛刻了，需要同時滿足下面三個條件：
- 該類所有的實體都已經被回收，也就是Java堆中不存在該類及其任何派生子類的實體，
- 加載該類的類加載器已經被回收，這個條件除非是經過精心設計的可替換類加載器的場景，如OSGi、JSP的重加載等，否則通常是很難達成的，
- 該類對應的
java.lang.Class物件沒有在任何地方被參考，無法在任何地方通過反射訪問該類的方法，
Java虛擬機被允許對滿足上述三個條件的無用類進行回收，這里說的僅僅是“被允許”，而并不是和物件一樣，沒有參考了就必然會回收，關于是否要對型別進行回收，HotSpot虛擬機提供了-Xnoclassgc引數進行控制，
也就說如果沒有開啟這項引數支持型別的卸載，哪怕滿足了所有條件，也不會進行型別的卸載，
垃圾收集演算法
標記-清除演算法
最早出現也是最基礎的垃圾收集演算法是“標記-清除”（Mark-Sweep）演算法，它分為“標記”和“清除”兩個階段：首先標記出所有需要回收的物件，在標記完成后，統一回收掉所有被標記的物件，也可以反過來，標記存活的物件，統一回收所有未被標記的物件，
-
優點：不需要進行物件的移動，在存活物件比較多的情況下非常高效，
-
缺點：標記-清除演算法主要缺點有兩個，第一個是執行效率不穩定，如果Java堆中包含大量物件，而且其中大部分是需要被回收的，這時必須進行大量標記和清除的動作；第二個是記憶體空間的碎片化問題，標記、清除之后會產生大量不連續的記憶體碎片，空間碎片太多可能會導致當以后在程式運行程序中需要分配較大物件時無法找到足夠的連續記憶體而不得不提前觸發另一次垃圾收集動作，
下圖為使用“標記-清除”演算法回收前后的狀態：
后續的收集演算法大多都是以標記-清除演算法為基礎，對其缺點進行改進而得到的，
標記-復制演算法
為了解決標記-清除演算法面對大量可回收物件時執行效率低的問題，1969年Fenichel提出了一種稱為“半區復制”（Semispace Copying）的垃圾收集演算法，它將可用記憶體按容量劃分為大小相等的兩塊，每次只使用其中的一塊，當這一塊的記憶體用完了，就將還存活著的物件復制到另外一塊上面，然后再把已使用過的記憶體空間一次清理掉，
如果記憶體中多數物件都是存活的，這種演算法將會產生大量的記憶體間復制的開銷，但對于多數物件都是可回收的情況，演算法需要復制的就是占少數的存活物件，而且每次都是針對整個半區進行記憶體回收，分配記憶體時也就不用考慮有空間碎片的復雜情況，
-
優點：實作簡單；記憶體回收時不用考慮記憶體碎片的出現，
-
缺點：代價是將可用記憶體縮小為了原來的一半，
下圖為使用復制演算法回收前后的狀態：
標記-整理演算法
標記-復制演算法在物件存活率較高時就要進行較多的復制操作，效率將會降低，更關鍵的是，如果不想浪費50%的空間，就需要有額外的空間進行分配擔保，以應對被使用的記憶體中所有物件都100%存活的極端情況，所以在老年代一般不能直接選用這種演算法，針對老年代物件的存亡特征，1974年Edward Lueders提出了另外一種有針對性的“標記-整理”（Mark-Compact）演算法，其中的標記程序仍然與“標記-清除”演算法一樣，但后續步驟不是直接對可回收物件進行清理，而是讓所有存活的物件都向記憶體空間一端移動，然后直接清理掉邊界以外的記憶體，
- 優點：經過整理之后，新物件的分配只需要通過指標碰撞便能完成，也解決了記憶體碎片的問題，
- 缺點：GC 暫停的時間會增長，物件移動的時間成本是十分可觀的，
下圖為使用“標記-整理”演算法回收前后的狀態：
標記-清除 VS 標記-整理
標記-清除演算法與標記-整理演算法的本質差異在于前者是一種非移動式的回收演算法，而后者是移動式的，是否移動回收后的存活物件是一項優缺點并存的風險決策，
如果移動存活物件，尤其是在老年代這種每次回收都有大量物件存活區域，移動存活物件會是一種極為負重的操作，而且這種物件移動操作必須全程暫停用戶應用程式才能進行，
但如果跟標記-清除演算法那樣完全不考慮移動和整理存活物件的話，彌散于堆中的存活物件導致的記憶體碎片問題就只能依賴更為復雜的記憶體分配器和記憶體訪問器來解決，譬如通過“磁區空閑分配鏈表”來解決記憶體分配問題，記憶體的訪問是用戶程式最頻繁的操作，甚至都沒有之一，假如在這個環節上增加了額外的負擔，勢必會直接影回應用程式的吞吐量，
基于以上兩點，是否移動物件都存在弊端，移動則記憶體回收時會更復雜，不移動則記憶體分配時會更復雜，從垃圾收集的停頓時間來看，不移動物件停頓時間會更短，但是從整個程式的吞吐量來看，移動物件會更劃算，
HotSpot虛擬機里面關注吞吐量的Parallel Scavenge收集器是基于標記-整理演算法的，而關注延遲的CMS收集器則是基于標記-清除演算法的，這也從側面印證這點，
另外，還有一種“和稀泥式”解決方案可以不在記憶體分配和訪問上增加太大額外負擔，做法是讓虛擬機平時多數時間都采用標記-清除演算法，暫時容忍記憶體碎片的存在，直到記憶體空間的碎片化程度已經大到影響物件分配時，再采用標記-整理演算法收集一次，以獲得規整的記憶體空間，基于標記-清除演算法的CMS收集器采用的就是這種處理辦法，
當CMS出現“并發失敗”（Concurrent Mode Failure）時，這時會啟用Serial Old收集器來重新進行老年代的垃圾收集，而Serial Old正是基于標記-整理演算法，
如果本篇博客有任何錯誤和建議，歡迎給我留言指正，文章持續更新，可以關注公眾號第一時間閱讀，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/542575.html
標籤：其他
下一篇：Zookeeper集群