Java 中的垃圾回收，常常是由 JVM 幫我們做好的。雖然這節省了大家很多的學習的成本，提高了專案的執行效率，但是當專案變得越來越複雜，使用者量越來越大時，還是需要我們懂得垃圾回收機制，這樣也能進行更深一步的優化。

辨別物件存亡

垃圾回收( Garbage Collection，以下簡稱 GC )，從字面上理解，就是將已經分配出去的，但卻不再使用的記憶體回收回來，以便能夠再次分配。

在 JVM 中，垃圾就是指的死亡物件所佔據的堆空間( GC 是發生在堆空間中)，那麼我們如果辨別一個物件是否死亡呢？JVM 使用的是引用計數法和可達性分析。

引用計數法

引用計數法( Reference Counting)，是為每個物件新增一個引用計數器，用來統計引用該物件的個數。一旦某個物件的引用計數器為0，則說明該物件已經死亡，便可以被回收了。

其具體實現為：

如果有一個引用，被賦值為某一物件，那麼將該物件的引用計數器 +1。

如果一個指向某一物件的引用，被賦值為其他值，那麼將該物件的引用計數器 -1。

也就是說，我們需要截獲所有的引用更新操作，並且相應地增減目標物件的引用計數器。

看似很簡單的實現，其實裡面有不少缺陷：

1. 需要額外的空間來儲存計數器。
2. 計數器的更新操作十分繁瑣。
3. 最重要的：無法處理迴圈引用物件。

針對第3點，舉個例子特別說明一下：

假設物件 a 與 b 相互引用，除此之外沒有其他引用指向他們。在這種情況下，a 和 b 實際上已經死了。

但由於它們的引用計數器皆不為0（因為相互引用，兩者均為1），在引用計數法的計算中，這兩個物件還活著。因此，這些迴圈引用物件所佔據的空間將不可回收，從而造成了記憶體洩露

。

可達性分析

可達性分析( Reachability Analysis )，是目前 JVM 主要採取的判定物件死亡的方法。實質在於將一系列GC Roots作為初始的存活物件合集（live set），然後從該合集出發，探索所有能夠被該集合引用到的物件，並將其加入到該集合中，這個過程我們也稱之為標記（mark）。最終，未被探索到的物件便是死亡的，是可以回收的。

那麼什麼是GC Roots呢？我們可以暫時理解為由堆外指向堆內的引用，一般而言，GC Roots 包括（但不限於）如下幾種：

1. Java 方法棧楨中的區域性變數
2. 已載入類的靜態變數
3. JNI handles
4. 已啟動且未停止的 Java 執行緒

之前我們說引用計數法會有迴圈引用的問題，可達性分析就不會了。舉例來說，即便物件 a 和 b 相互引用，只要從 GC Roots 出發無法到達 a 或者 b，那麼可達性分析便會認為它們已經死亡。

那可達性分析有沒有什麼缺點呢？有的，在多執行緒環境下，其他執行緒可能會更新已經分析過的物件中的引用，從而造成誤報（將引用設定為 null）或者漏報（將引用設定為未被訪問過的物件）。

誤報並沒有什麼傷害，JVM 至多損失了部分垃圾回收的機會。漏報則比較麻煩，因為垃圾回收器可能回收事實上仍被引用的物件記憶體。一旦從原引用訪問已經被回收了的物件，則很有可能會直接導致 JVM 崩潰。

STW

既然可達性分析在多執行緒下有缺點，那 JVM 是如何解決的呢？答案便是 Stop-the-world(以下簡稱JWT)，停止了其他非垃圾回收執行緒的工作直到完成垃圾回收。這也就造成了垃圾回收所謂的暫停時間（GC pause）。

那 SWT 是如何實現的呢？當 JVM 收到 SWT 請求後，它會等待所有的執行緒都到達安全點（Safe Point），才允許請求 SWT 的執行緒進行獨佔的工作。

那什麼又叫安全點呢？安全點是 JVM 能找到一個穩定的執行狀態，在這個執行狀態下，JVM 的堆疊不會發生變化。

這麼一來，垃圾回收器便能夠“安全”地執行可達性分析，所有存活的物件也都可以成功被標記，那麼之後就可以將死亡的物件進行垃圾回收了。

總結

以上便是發現死亡物件的過程，這也為之後的垃圾回收進行鋪墊，具體的垃圾回收過程，我會在下一篇文章中講述，敬請期待。

有興趣的話可以訪問我的部落格或者關注我的公眾號、頭條號，說不定會有意外的驚喜。

https://death00.github.io/

相關推薦