搞定Java垃圾回收，就這一篇！
之前上學的時候有這個一個梗，說在食堂里吃飯，吃完把餐盤端走清理的，是 C++ 程序員，吃完直接就走的，是 Java 程序員。
圖片來自 Pexels
確實，在 Java 的世界里，似乎我們不用對垃圾回收那么的專注，很多初學者不懂 GC，也依然能寫出一個能用甚至還不錯的程序或系統。
但其實這并不代表 Java 的 GC 就不重要。相反，它是那么的重要和復雜，以至于出了問題，那些初學者除了打開 GC 日志，看著一堆 0101 的天文，啥也做不了。
今天我們就從頭到尾完整地聊一聊 Java 的垃圾回收。
什么是垃圾回收
垃圾回收(Garbage Collection，GC)，顧名思義就是釋放垃圾占用的空間，防止內存泄露。
有效的使用可以使用的內存，對內存堆中已經死亡的或者長時間沒有使用的對象進行清除和回收。
Java 語言出來之前，大家都在拼命的寫 C 或者 C++ 的程序，而此時存在一個很大的矛盾。
C++ 等語言創建對象要不斷的去開辟空間，不用的時候又需要不斷的去釋放控件，既要寫構造函數，又要寫析構函數，很多時候都在重復的 allocated，然后不停的析構。
于是，有人就提出，能不能寫一段程序實現這塊功能，每次創建，釋放控件的時候復用這段代碼，而無需重復的書寫呢?
1960 年，基于 MIT 的 Lisp 首先提出了垃圾回收的概念，而這時 Java 還沒有出世呢!所以實際上 GC 并不是 Java 的專利，GC 的歷史遠遠大于 Java 的歷史!
怎么定義垃圾
既然我們要做垃圾回收，首先我們得搞清楚垃圾的定義是什么，哪些內存是需要回收的。
引用計數算法
引用計數算法(Reachability Counting)是通過在對象頭中分配一個空間來保存該對象被引用的次數(Reference Count)。
如果該對象被其它對象引用，則它的引用計數加 1，如果刪除對該對象的引用，那么它的引用計數就減 1，當該對象的引用計數為 0 時，那么該對象就會被回收。
- String m = new String("jack");
先創建一個字符串，這時候"jack"有一個引用，就是 m。
然后將 m 設置為 null，這時候"jack"的引用次數就等于 0 了，在引用計數算法中，意味著這塊內容就需要被回收了。
- m = null;
引用計數算法是將垃圾回收分攤到整個應用程序的運行當中了，而不是在進行垃圾收集時，要掛起整個應用的運行，直到對堆中所有對象的處理都結束。
因此，采用引用計數的垃圾收集不屬于嚴格意義上的"Stop-The-World"的垃圾收集機制。
看似很美好，但我們知道 JVM 的垃圾回收就是"Stop-The-World"的，那是什么原因導致我們最終放棄了引用計數算法呢?
- public class ReferenceCountingGC {
- public Object instance;
- public ReferenceCountingGC(String name){}
- }
- public static void testGC(){
- ReferenceCountingGC a = new ReferenceCountingGC("objA");
- ReferenceCountingGC b = new ReferenceCountingGC("objB");
- a.instance = b;
- b.instance = a;
- a = null;
- b = null;
- }
看上面的例子：
- 定義 2 個對象
- 相互引用
- 置空各自的聲明引用
我們可以看到，最后這 2 個對象已經不可能再被訪問了，但由于他們相互引用著對方，導致它們的引用計數永遠都不會為 0，通過引用計數算法，也就永遠無法通知 GC 收集器回收它們。
可達性分析算法
可達性分析算法(Reachability Analysis)的基本思路是，通過一些被稱為引用鏈(GC Roots)的對象作為起點，從這些節點開始向下搜索。
搜索走過的路徑被稱為 Reference Chain，當一個對象到 GC Roots 沒有任何引用鏈相連時(即從 GC Roots 節點到該節點不可達)，則證明該對象是不可用的。
通過可達性算法，成功解決了引用計數所無法解決的問題-“循環依賴”，只要你無法與 GC Root 建立直接或間接的連接，系統就會判定你為可回收對象。那這樣就引申出了另一個問題，哪些屬于 GC Root。
Java 內存區域
在 Java 語言中，可作為 GC Root 的對象包括以下 4 種：
- 虛擬機棧(棧幀中的本地變量表)中引用的對象
- 方法區中類靜態屬性引用的對象
- 方法區中常量引用的對象
- 本地方法棧中 JNI(即一般說的 Native 方法)引用的對象
①虛擬機棧(棧幀中的本地變量表)中引用的對象
此時的 s，即為 GC Root，當s置空時，localParameter 對象也斷掉了與 GC Root 的引用鏈，將被回收。
- public class StackLocalParameter {
- public StackLocalParameter(String name){}
- }
- public static void testGC(){
- StackLocalParameter s = new StackLocalParameter("localParameter");
- s = null;
- }
②方法區中類靜態屬性引用的對象
s 為 GC Root，s 置為 null，經過 GC 后，s 所指向的 properties 對象由于無法與 GC Root 建立關系被回收。
而 m 作為類的靜態屬性，也屬于 GC Root，parameter 對象依然與 GC root 建立著連接，所以此時 parameter 對象并不會被回收。
- public class MethodAreaStaicProperties {
- public static MethodAreaStaicProperties m;
- public MethodAreaStaicProperties(String name){}
- }
- public static void testGC(){
- MethodAreaStaicProperties s = new MethodAreaStaicProperties("properties");
- s.m = new MethodAreaStaicProperties("parameter");
- s = null;
- }
③方法區中常量引用的對象
m 即為方法區中的常量引用，也為 GC Root，s 置為 null 后，final 對象也不會因沒有與 GC Root 建立聯系而被回收。
- public class MethodAreaStaicProperties {
- public static final MethodAreaStaicProperties m = MethodAreaStaicProperties("final");
- public MethodAreaStaicProperties(String name){}
- }
- public static void testGC(){
- MethodAreaStaicProperties s = new MethodAreaStaicProperties("staticProperties");
- s = null;
- }
④本地方法棧中引用的對象
任何 Native 接口都會使用某種本地方法棧，實現的本地方法接口是使用 C 連接模型的話，那么它的本地方法棧就是 C 棧。當線程調用 Java 方法時，虛擬機會創建一個新的棧幀并壓入 Java 棧。
然而當它調用的是本地方法時，虛擬機會保持 Java 棧不變，不再在線程的 Java 棧中壓入新的幀，虛擬機只是簡單地動態連接并直接調用指定的本地方法。
怎么回收垃圾
在確定了哪些垃圾可以被回收后，垃圾收集器要做的事情就是開始進行垃圾回收，但是這里面涉及到一個問題是：如何高效地進行垃圾回收。
由于 Java 虛擬機規范并沒有對如何實現垃圾收集器做出明確的規定，因此各個廠商的虛擬機可以采用不同的方式來實現垃圾收集器，這里我們討論幾種常見的垃圾收集算法的核心思想。
標記-清除算法
標記-清除算法(Mark-Sweep)是最基礎的一種垃圾回收算法，它分為 2 部分，先把內存區域中的這些對象進行標記，哪些屬于可回收標記出來，然后把這些垃圾拎出來清理掉。
就像上圖一樣，清理掉的垃圾就變成未使用的內存區域，等待被再次使用。
這邏輯再清晰不過了，并且也很好操作，但它存在一個很大的問題，那就是內存碎片。
上圖中等方塊的假設是 2M，小一些的是 1M，大一些的是 4M。等我們回收完，內存就會切成了很多段。
我們知道開辟內存空間時，需要的是連續的內存區域，這時候我們需要一個 2M的內存區域，其中有2個 1M 是沒法用的。這樣就導致，其實我們本身還有這么多的內存的，但卻用不了。
復制算法
復制算法(Copying)是在標記清除算法上演化而來，解決標記清除算法的內存碎片問題。
它將可用內存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活著的對象復制到另外一塊上面，然后再把已使用過的內存空間一次清理掉。
保證了內存的連續可用，內存分配時也就不用考慮內存碎片等復雜情況，邏輯清晰，運行高效。
上面的圖很清楚，也很明顯的暴露了另一個問題，合著我這 140 平的大三房，只能當 70 平米的小兩房來使?代價實在太高。
標記-整理算法
標記-整理算法(Mark-Compact)的標記過程仍然與標記清除算法一樣，但后續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，再清理掉端邊界以外的內存區域。
標記-整理算法一方面在標記-清除算法上做了升級，解決了內存碎片的問題，也規避了復制算法只能利用一半內存區域的弊端。
看起來很美好，但從上圖可以看到，它對內存變動更頻繁，需要整理所有存活對象的引用地址，在效率上比復制算法要差很多。
分代收集算法(Generational Collection)嚴格來說并不是一種思想或理論，而是融合上述 3 種基礎的算法思想，而產生的針對不同情況所采用不同算法的一套組合拳。
對象存活周期的不同將內存劃分為幾塊。一般是把 Java 堆分為新生代和老年代，這樣就可以根據各個年代的特點采用適當的收集算法。
在新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，那就選用復制算法，只需要付出少量存活對象的復制成本就可以完成收集。
而老年代中因為對象存活率高、沒有額外空間對它進行分配擔保，就必須使用標記-清理或者標記-整理算法來進行回收。
So，另一個問題來了，那內存區域到底被分為哪幾塊，每一塊又有什么特別適合什么算法呢?
內存模型與回收策略
Java 堆(Java Heap)是 JVM 所管理的內存中最大的一塊，堆又是垃圾收集器管理的主要區域，這里我們主要分析一下 Java 堆的結構。
Java 堆主要分為 2 個區域，年輕代與老年代，其中年輕代又分 Eden 區和 Survivor 區，其中 Survivor 區又分 From 和 To 2 個區。
可能這時候大家會有疑問，為什么需要 Survivor 區，為什么Survivor 還要分 2 個區。
不著急，我們從頭到尾，看看對象到底是怎么來的，而它又是怎么沒的。
Eden 區
IBM 公司的專業研究表明，有將近 98% 的對象是朝生夕死，所以針對這一現狀，大多數情況下，對象會在新生代 Eden 區中進行分配。
當 Eden 區沒有足夠空間進行分配時，虛擬機會發起一次 Minor GC，Minor GC 相比 Major GC 更頻繁，回收速度也更快。
通過 Minor GC 之后，Eden 會被清空，Eden 區中絕大部分對象會被回收，而那些無需回收的存活對象，將會進到 Survivor 的 From 區(若 From 區不夠，則直接進入 Old 區)。
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 區可能是經過權衡之后的最佳方案。
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 空間的一半，年齡大于等于該年齡的對象就可以直接進去老年區，無需等你“成年”。
這其實有點類似于負載均衡，輪詢是負載均衡的一種，保證每臺機器都分得同樣的請求。
看似很均衡，但每臺機的硬件不同，健康狀況不同，我們還可以基于每臺機接受的請求數，或每臺機的響應時間等，來調整我們的負載均衡算法。
作者：聶曉龍(花名：率鴿)
簡介：阿里巴巴高級開發工程師，本文部分內容參考自書籍：《深入理解 Java 虛擬機》。
