GC 中文直譯垃圾回收,是一種回收記憶體空間避免記憶體泄漏的機制。 ...
GC
中文直譯垃圾回收,是一種回收記憶體空間避免記憶體泄漏的機制。當 JVM
記憶體緊張,通過執行 GC
有效回收記憶體,轉而分配給新對象從而實現記憶體的再利用。 JVM
GC
機制雖然無需開發主動參與,減輕不少工作量,但是某些情況下,自動 GC
將會導致系統性能下降,響應變慢,所以這就需要我們提前瞭解掌握 GC
機制。當面對這種情況時,才能從容不迫的解決問題。另外 GC
機制也是 Java
面試高頻考題,瞭解掌握 GC 是一項必備技能。
學習 GC
,首先我們解決三個問題:
- 什麼是垃圾
- 在哪裡回收垃圾
- 怎麼回收垃圾
什麼是垃圾#
我們先來看一段簡單的代碼。
上面代碼通過將字元串對象轉化成位元組數組,然後寫入本地文件。方法一旦開始執行,就將會在分配一定記憶體給新建的對象,然後將引用告訴了 str
, bytes
變數。等到方法執行完畢,方法內部局部變數緊接將就會被銷毀。但是這樣僅僅銷毀了局部變數,卻沒有帶走記憶體上這些實際的對象。這類不再起作用,沒有被引用的對象,將其歸類為垃圾。
在偌大的記憶體上存活著無數對象, GC
之前需要準確將這些對象標記出來,分為存活對象與垃圾對象。這個過程一旦少標記,那就只能等待下次 GC
標記,再回收,這樣將會影響 GC 效率。另外決不能錯標記,將正常存活對象標記為垃圾。一旦回收正常存活的對象,可能就會引起程式各種崩潰。
目前有兩種演算法可以用來標記:
- 引用計數法
- 可達性分析法
引用計數法#
引用計數法通過在對象頭分配一個欄位,用來存儲該對象引用計數。一旦該對象被其他對象引用,計數加 1。如果這個引用失效,計數減 1。當引用計數值為 0 時,代表這個對象已不再被引用,可以被回收。
引用計數法
如上圖所示,當 str
引用堆中對象時,計數值增加為 1。當 str
變為 null
時,既不再引用該對象,計數值減 1。此時該對象就可以被 GC
回收。
引用計數法只需要判斷計數值,所以實現比較簡單,這個過程也比較高效。但是存在一個很嚴重的問題,無法解決對象迴圈引用問題。
引用計數法-1
從上圖可以看到, a
, b
不再引用堆中對象,導致計數減一。此時兩個對象內部還存在互相引用,計數值不為 0,此時 GC
沒辦法回收該對象。
可達性分析法#
這個演算法首先需要按照規則查找當前活躍的引用,將其稱為 GC Roots
。接著將 GC Roots
作為根節點出發,遍歷對象引用關係圖,將可以遍歷(可達)的對象標記為存活,其餘對象當做無用對象。
可達性分析
註意這裡是是 引用 ,而不是對象。
從上圖可以看到,綠色對象雖然存在迴圈引用,但是由於這些對象不能被 GC Roots
遍歷到,所以將會被回收。
可以被當做 GC Roots
活躍引用包括但不限於以下引用:
- 方法中局部變數
- 靜態變數,常量
- JNI handles
- ....
在哪裡回收垃圾#
還記得剛開始接觸 Java
時,只知道堆棧,對象實例分配在堆中,方法中局部變數位於棧中。實際上 JVM
記憶體區域劃分更加細緻,分為:
- 堆
- 方法區
- 虛擬機棧
- 本地方法棧
- 程式計數器
JVM 運行時記憶體區域劃分
如圖所示,我們將記憶體劃分為線程私有與線程共用的區域。方法區與堆都是線程共用的區域,這兩部分占用 JVM
大部分記憶體,剩下三個小弟將會跟線程綁定,隨著線程消亡,自動將會被 JVM
回收。
堆
堆應該是大家最熟悉的一塊區域,幾乎所有對象實例都將會在此出生,通常也是虛擬機上占用記憶體最大一塊區域,簡直就是 JVM
記憶體中的大哥大。堆記憶體內部也不是簡簡單單一塊而已,目前將會根據分代演算法,將堆分代,不同對象位於不同區域。這一點我們下文再詳細瞭解。
方法區
方法區將會保存已被虛擬上載入的類信息、常量,靜態變數,位元組碼等信息,堆上的對象正式通過方法區這些信息,才能正確創建出來。
棧
虛擬機棧棧由一系列棧幀組成,每個棧幀其實代表一個方法,棧幀中將會保存一個方法的局部變數表,方法出入口信息,操作棧等。每當調用一個方法,就將會把這個棧幀壓入棧中,執行結束,出棧。
本地方法棧與虛擬機棧比較類似,最大區別在於,虛擬機棧執行的 Java
方法,而本地方法棧將會用來執行 Native
方法服務。下麵方法就會在本地方法棧中執行。
<pre class="java" style="margin: 10px 0px; padding: 0px; white-space: pre !important; overflow-wrap: break-word; position: relative !important; color: rgb(49, 70, 89); font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 300; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;">
Copy
public static native void arraycopy(Object src, int srcPos, Object dest, int destPos, int length);
</pre>
程式計數器
程式計算器可以說是這幾塊區域占用最小的一部分,但是功能卻十分重要。Java 源代碼通過編譯變成位元組碼,然後被 JVM 載入運行之後,將會變成一條條指令,而程式計數器的工作就是告訴當前線程下一條需要執行指令。這樣即使發生了線程切換,等待恢復的時候,當前線程依然知道接下去要執行的指令。
怎麼回收#
目前主流 GC 演算法主要分為三種:
- 標記-清除演算法
- 複製演算法
- 標記-整理演算法
標記-清除演算法#
這是一個最為基礎也是最容易實現的演算法,主要實現步驟分為兩步:標記,清除。
- 標記:通過上述
GC Roots
標記出可達對象。 - 清除:清理 未標記對象 。
ps:這個圖著實難畫啊。。。。
可以看到經過這個演算法回收之後,雖然堆空間被清理出來,但是也產生很多 空間碎片 。這就會導致一個新對象根據堆剩餘容量計算,看起來是可以分配,但是實際分配過程,由於沒有連續記憶體,導致虛擬機感知到記憶體不足,又不得不提前再次觸發 GC
。
可能這裡你就會有疑惑,為什麼對象需要分配一塊連續的記憶體?
這裡引用一下 R 神@RednaxelaFX 答案。
另外這個演算法還有一個不足:標記與清除效率比較低。這就竟會導致 GC
占用時間過長,影響正常程式使用。
複製演算法#
為瞭解決上述效率問題,誕生複製演算法。這個演算法將可用記憶體分為兩塊,每次只使用其中一塊,當這一塊記憶體使用完畢,觸發 GC
,將會把存活的對象依次複製到另外一塊上,然後再把已使用過的記憶體一次性清理。
這個演算法每次只需要操作一半記憶體, GC
回收之後也不存在任何空間碎片,新對象記憶體分配時只需要移動堆頂指針,按順序分配記憶體即可,實現簡單,運行高效。但是這個演算法閑置一半記憶體空間,空間利用效率不高。
PS:複製演算法以空間換時間,兩者不可兼得
另外對象存活率也會影響複製演算法效率。如果對象大部分都是朝生夕死,只需要移動少量存活對象,就能騰出大部分空間。反而如果對象存活率高,這就需要進行較多的複製操作,回收之後也並沒有多餘記憶體,這就可能導致頻繁觸發 GC
。
針對這種存活時間長的對象,就需要使用標記-整理演算法。
標記-整理演算法#
標記-整理演算法可以說是標記-清除演算法的改進版,改進了清除導致的空間碎片問題。這個演算法分為兩步:
GC Roots
雖然標記-整理演算法解決了標記-清除演算法空間碎片問題,也完整利用整個記憶體空間,但是這個演算法問題效率並不高。相較於標記-清除演算法,標記-整理演算法多增加整理這一步,所以該演算法效率還低於標記-清除演算法。
分代收集演算法#
從上面三種 GC
演算法可以看到,並沒有一種空間與時間效率都是比較完美的演算法,所以只能做的是綜合利用各種演算法特點將其作用到不用的記憶體區域。
目前商業虛擬機根據對象存活周期不同劃分記憶體區域,一般分為新生代,老年代。新對象一般情況都會優先分配在新生代,新生代對象若存活時間大於一定閾值之後,將會移到至老年代。新生代的對象都是短命鬼,老年代的對象都是長壽先生。
新生代每次 GC
之後都可以回收大批量對象,所以比較適合複製演算法,只需要付出少量複製存活對象的成本。這裡記憶體劃分並沒有按照 1:1 劃分,預設將會按照 8:1:1 劃分成 Eden
與兩塊 Survivor
空間。每次使用 Eden
與一塊 Survivor
空間,這樣我們只是閑置 10% 記憶體空間。不過我們每次回收並不能保證存活對象小於 10%,在這種情況下就需要依靠老年代的記憶體分配擔保。當 Survivor
空間並不能保存剩餘存活對象,就將這些對象通過分配擔保進位移動至老年代。
老年代中對象存活率將會特別高,且沒有額外空間進行分配擔保,所以並不適合複製演算法,所以需要使用標記-清除或標記-整理演算法。
感謝你看完我的長篇大論,如果覺得對你有幫助的話,可以動動你敲代碼的小手幫我點個贊。
或者也可以關註我的公眾號【Java技術zhai】,不定期的技術乾貨內容分享,帶你重新定義架構的魅力!