Java 虛擬機器垃圾收集機制詳解
阿新 • • 發佈:2020-12-04
> 本文摘自深入理解 Java 虛擬機器第三版
## 垃圾收集發生的區域 之前我們介紹過 Java 記憶體執行時區域的各個部分,其中程式計數器、虛擬機器棧、本地方法棧三個區域隨執行緒共存亡。棧中的每一個棧幀分配多少記憶體基本上在類結構確定下來時就已知,因此這幾個區域的記憶體分配和回收都具有確定性,不需要考慮如何回收的問題,當方法結束或執行緒結束,記憶體自然也跟著回收了 而 Java 堆和方法區這兩個區域則有顯著的不確定性,只有在程式執行時我們才能知道程式究竟建立了哪些物件,建立了多少物件,所以這部分記憶體的分配和回收是動態的,垃圾收集器所關注的正是這部分記憶體該如何管理
## 如何判定需要被回收的物件? 如果一個物件沒有被其他物件引用,則證明這個物件可以被回收,因為它已經沒有實際用途了。那我們怎麼去判斷一個物件是否可回收呢?業界主要有兩種判斷方式: #### 1. 引用計數法 在物件中新增一個引用計數器,每當有一個地方引用它時,計數器值加一;當引用失效,計數器值減一;任何時刻計數器值都為零的物件就是不可能再被使用了。這種方法雖然會佔用額外的記憶體空間用於計數,但它的原理簡單,判定效率也高,大多數情況下它都是一個不錯的演算法。然而,這個看似簡單的演算法卻需要考慮很多額外情況,否則將無法保證其正確工作,例如單純的引用計數法就很難解決物件之間相互迴圈引用的問題 #### 2. 可達性分析演算法 該演算法的基本思路是通過一系列稱為 GC Roots 的根物件作為起始節點集,從這些節點開始,根據引用關係向下搜尋,搜尋過程走過的路徑稱為引用鏈。如果某個物件到 GC Roots 間沒有任何引用鏈相連,則證明此物件是不可能再被使用,可以回收 ![](https://img2020.cnblogs.com/blog/1759254/202012/1759254-20201203211225623-1515170408.png) 在 Java 技術體系中,可以作為 GC Roots 的物件包括: - 在虛擬機器棧(棧幀中的本地變量表)中引用的物件 - 方法區中類靜態屬性引用的物件 - 方法區中常量引用的物件 - 本地方法棧中 JNI(即通常所說的 Native 方法)引用的物件 - Java 虛擬機器內部的引用,如基本資料型別對應的 Class 物件,一些常駐的異常物件(NullPointException、OutOfMemoryError) - 所有被同步鎖持有的物件 - 反映 Java 虛擬機器內部情況的 JMXBean、JVMTI 中註冊的回撥、原生代碼快取等 除了這些固定的 GC Roots 集合外,根據使用者所選用的垃圾收集器以及當前回收的記憶體區域的不同,還可以有其他物件臨時加入,共同構成完整的 GC Roots 集合
## 分代收集理論 當前商業虛擬機器的垃圾收集器大多數都遵循了“分代收集”的設計理論,分代收集理論其實是一套符合大多數程式執行實際情況的經驗法則,主要建立在兩個分代假說之上: - 弱分代假說:絕大多數物件都是朝生夕滅的 - 強分代假說:熬過越多次垃圾收集過程的物件就越難以消亡 這兩個分代假說共同奠定了多款常用垃圾收集器的一致設計原則:收集器應該將 Java 堆劃分出不同的區域,將回收物件依據年齡(即物件熬過垃圾收集過程的次數)分配到不同的區域之中儲存,把存活時間短的物件集中在一起,每次回收只關注如何保留少量存活的物件,即新生代(Young Generation);把難以消亡的物件集中在一起,虛擬機器就可以使用較低的頻率來回收這個區域,即老年代(Old Generation) 正因為劃出了不同的區域,垃圾收集器才可以每次只回收其中一個或多個區域,因此才有了“Minor GC”、“Major GC”、“Full GC”這樣的回收型別劃分,也才能夠針對不同的區域採用不同的垃圾收集演算法,因而有了“標記-複製”演算法、“標記-清除”演算法、“標記-整理”演算法 分代收集並非只是簡單劃分一下記憶體區域,它至少存在一個明顯的困難:物件之間不是孤立的,物件之間會存在跨代引用。假如現在要進行只侷限於新生代的垃圾收集,根據前面可達性分析的知識,與 GC Roots 之間不存在引用鏈即為可回收,但新生代的物件很有可能會被老年代所引用,那麼老年代物件將臨時加入 GC Roots 集合中,我們不得不再額外遍歷整個老年代中的所有物件來確保可達性分析結果的正確性,這無疑為記憶體回收帶來很大的效能負擔。為了解決這個問題,就需要對分代收集理論新增第三條經驗法則: - 跨代引用假說:跨代引用相對於同代引用僅佔少數 存在互相引用的兩個物件,應該是傾向於同時生存或同時消亡的,舉個例子,如果某個新生代物件存在跨代引用,由於老年代物件難以消亡,會使得新生代物件同樣在收集時得以存活,進而年齡增長後晉升到老年代,那麼跨代引用也隨之消除了。既然跨帶引用只是少數,那麼就沒必要去掃描整個老年代,也不必專門記錄每一個物件是否存在哪些跨代引用,只需在新生代上建立一個全域性的資料結構,稱為記憶集(Remembered Set),這個結構把老年代劃分為若干個小塊,標識出老年代的哪一塊記憶體會存在跨代引用。此後當發生 Minor GC 時,只有包含了跨代引用的小塊記憶體裡的物件才會被加入 GC Roots 進行掃描
## 標記 - 清除演算法 如其名,演算法分為標記和清除兩個階段:首先標記出所有需要回收的物件,在標記完成之後,統一回收所有被標記的物件,也可以反過來,標記存活的物件,統一回收所有未被標記的物件。標記過程就是物件是否屬於垃圾的判定過程。標記 - 清除演算法執行過程如圖所示: ![](https://img2020.cnblogs.com/blog/1759254/202012/1759254-20201203211252685-2134849657.png) 標記 - 清除演算法是最基礎的演算法,後續的收集演算法都是以標記 - 清除演算法為基礎,對其缺點進行改進,它的主要缺點有兩個: - 執行效率不穩定 如果 Java 堆中包含大量物件且大部分需要回收,則必須進行大量標記和清除的動作‘ - 記憶體空間碎片化問題 標記、清除之後會產生大量不連續的記憶體碎片,記憶體碎片太多會導致下次分配較大物件時無法找到足夠的連續記憶體,從而不得不提前觸發一次垃圾收集動作
## 標記 - 複製演算法 為了解決標記 - 清除演算法面對大量可回收物件時執行效率低的問題,複製演算法將可用記憶體按容量劃分為大小相等的兩塊,每次只使用其中一塊,當這一塊記憶體用完了,就將還存活著的物件複製到另外一記憶體上,再把已使用過的記憶體空間一次清理掉 如果記憶體中多數物件都是存活的,這種演算法無疑會產生大量記憶體間複製的開銷,但對於多數物件都是可回收的情況,演算法需要複製的就是佔少數的存活物件,而且每次都是針對整個半區進行記憶體回收,分配記憶體時也不用考慮空間碎片的問題,只要移動堆頂指標,按順序分配即可。不過這種演算法的缺陷也顯而易見,可用記憶體被縮小為原來的一半 ![](https://img2020.cnblogs.com/blog/1759254/202012/1759254-20201203211312744-1886436925.png) 標記 - 複製演算法大多用於新生代。實際上,新生代中的物件大多數都熬不過第一輪收集,因此不需要按 1:1 的比例來劃分新生代的記憶體空間。具體做法是將新生代劃分為一塊較大的 Eden 區和兩塊較小的 Survivor 區,每次分配只使用 Eden 區和其中一塊 Survivor 區。發生垃圾收集時,將 Eden 區和 Survivor 區中仍然存活的物件一次性複製到另一個 Survivor 區,然後直接清理掉 Eden 區和已經用過的 Survivor 區。HotSpot 虛擬機器預設 Eden 和 Survivor 的大小比例是 8:1:1 當 Survivor 空間不足以容納一次 Minor GC 之後存活的物件時,就需要依賴其他記憶體區域(大多是老年代)進行分配擔保,上一次新生代存活下來的物件直接進入老年代
## 標記 - 整理演算法 標記 - 複製演算法不適合用在物件存活率高的區域,而且會浪費一半的空間,因此老年代一般不採用這種演算法,取而代之的是有針對性的標記 - 整理演算法。標記 - 整理演算法的標記過程與標記 - 清除演算法一樣,但後續步驟不是直接清理可回收物件,而是讓所有存活物件都向記憶體空間的一側移動,然後直接清理掉邊界以外的記憶體 ![](https://img2020.cnblogs.com/blog/1759254/202012/1759254-20201203211347356-1068695870.png) 是否移動回收後的存活物件是一項優缺點並存的風險決策,尤其是在老年代這種每次回收都有大量物件存活的區域,移動存活物件並更新其引用將會是一個極為繁重的操作,必須暫停使用者應用程式執行緒才能進行,像這樣的停頓行為被稱為“Stop the World”。但如果不考慮移動存活物件,又會影響記憶體分配和訪問的效率,為此使用者必須小心權衡其中的得失。一種和稀泥式的解決方案就是讓虛擬機器平時採用標記 - 清除演算法,直到記憶體空間碎片化程度大到影響物件分配時,再採用標記 - 整理演算法收集一次,已獲得規整的記憶體空