一晚上搞懂 | JVM GC&內存分配

前言

本文已經收錄到個人 GitHub 我的博客，歡迎大佬們光臨寒舍：java

https://lovelifeeveryday.github.io/git

學習導圖

一.爲何要學習`GC`&內存分配？

時代發展到如今，現在的內存動態分配與內存回收技術已經至關成熟，一切看似進入了「自動化」時代，難免發出疑問："爲啥咱們還要了解垃圾收集和內存分配？"github

答案很簡單，當須要排查各類內存溢出/泄漏問題的時候，當垃圾收集成爲系統達到更高併發量的瓶頸的時候，咱們必須對"自動化"技術進行必要的監控和調節。web

因此，咱們要了解下GC&內存分配，爲工做中或者是面試中實際的須要打好基礎。面試

二.核心知識點概括

2.1 對象存活斷定算法

在瞭解對象存活的斷定以前，咱們先來了解下四種引用類型算法

強引用 StrongReference

具備強引用的對象不會被 GC

即使內存空間不足， JVM寧願拋出 OutOfMemoryError使程序異常終止，也不會隨意回收具備強引用的對象

軟引用 SoftReference

只具備軟引用的對象，會在 內存空間不足的時候被 GC，若是 回收以後內存仍不足，纔會拋出OOM異常

軟引用經常使用於描述 有用但並不是必需的對象，好比實現內存敏感的高速緩存

弱引用 WeakReference

只被弱引用關聯的對象， 不管當前內存是否足夠都會被GC

強度比軟引用更弱，經常使用於描述 非必需對象

虛引用 PhantomReference

僅持有虛引用的對象，在任什麼時候候均可能被GC（和弱引用同樣）數組

主要做用是爲了垃圾收集器回收時收到一個系統通知 (PhantomRefernece類實現虛引用)緩存

與弱引用的區別：不一樣之處在於弱引用的get方法，虛引用的get方法始終返回null,弱引用能夠使用ReferenceQueue,虛引用必須配合ReferenceQueue使用安全

必須和引用隊列 （ReferenceQueue）聯合使用，當垃圾回收器準備回收一個對象時，若是發現它還有虛引用，就會在回收對象的內存以前，把這個虛引用加入到與之關聯的引用隊列中微信

（想要了解虛引用詳細用法的讀者，能夠看下這篇文章：強軟弱虛引用，只有體會過了，才能記住）

2.1.1 引用計數算法

定義：給對象中添加一個引用計數器，每當有一個地方引用它時，計數器值就加 1；當引用失效時，計數器值就減 1；任什麼時候刻計數器爲 0 的對象就是不可能再被使用的

然而在主流的 Java 虛擬機裏未選用引用計數算法來管理內存，主要緣由是它難以解決對象之間相互循環引用的問題，因此出現了另外一種對象存活斷定算法

//相互循環引用的 DEMO
public class ReferenceCountingGC {
    public Object instance = null;
    
    private static final int _1MB = 1024 * 1024;
    
    /**
 * 這個成員屬性的意義是佔點內存，以便在 GC 日誌中看清楚是否有回收過
 */ 
    private byte[] bigSize =new byte[2 * _1MB];
    
    public static void testGC() {
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        objA.instance = objB;
        objB.instance = objA;
        
        objA = null;
        objB = null;
        
        System.gc();
    }
}

2.1.2 可達性分析法

定義：經過一系列被稱爲『GC Roots』的對象做爲起始點，從這些節點開始向下搜索，搜索所走過的路徑稱爲引用鏈，當一個對象到GC Roots沒有任何引用鏈相連時，則證實此對象是不可用的

可做爲 GC Roots 的對象：

虛擬機棧中引用的對象，主要是指棧幀中的 本地變量表

本地方法棧中 Native方法引用的對象

方法區中 類靜態屬性引用的對象

方法區中常量引用的對象

JVM內部的引用 (基本數據類型對應的 Class對象)

全部被同步鎖 ( synchronized關鍵字) 持有的對象

反映 JVM內部狀況的 JMXBean、 JVMTI中的註冊的回調、本地代碼緩存等

Q：可達性分析算法中被斷定不可達的對象真的被判『死刑』了嗎？

A：在可達性分析算法中被斷定不可達的對象還未真的判『死刑』，一共至少要經歷兩次標記過程：

第一次標記：當第一次可達性分析後沒有與 GC Roots相鏈接的引用鏈，被第一次標記
第二次標記：

判斷對象是否有必要執行finalize()方法；若被斷定爲有必要執行finalize()方法，以後還會對對象再進行一次篩選，若是對象能在finalize()中從新與引用鏈上的任何一個對象創建關聯，將被移除出「即將回收」的集合。

引伸：有關方法區的GC，可分紅兩部分

廢棄常量與回收 Java堆中的對象的 GC很相似，即在任何地方都未被引用的常量會被 GC。

無用的類

需知足如下三個條件纔會被GC：

A.該類全部的實例都已被回收，即 Java 堆中不存在該類的任何實例；

B.加載該類的ClassLoader已經被回收；

C.該類對應的java.lang.Class對象沒在任何地方被引用，即沒法在任何地方經過反射訪問該類的方法。

2.2 垃圾收集算法

前文講了JVM會回收哪些對象，下文筆者將探究JVM如何回收這些對象

2.2.1 分代收集理論

Q1：三個假說是什麼？

弱分代假說：絕大多數對象都是 朝生夕滅的
強分代假說：熬過越屢次垃圾收集過程的對象就 難以消亡
跨代引用假說：跨代引用相對於同代來講 僅佔極少數（存在引用關係的對象應該傾向於同時生存或者同時消亡的，例如某個新生代被老年代所引用，該引用會使新生代對象在收集時一樣存活，進而進入老年代）

在新生代上創建一個全局的數據結構 (記憶集)，將老年代劃分紅若干小塊，標識出老年代哪一塊內存存在跨代引用，Minor GC時，在跨代引用的內存裏的對象纔會加入到GC Roots進行掃描

Q2：垃圾收集器一致的設計原則

收集器應將 Java堆劃分出不一樣的區域，而後將回收對象依據其年齡（年齡是對象熬過垃圾收集過程的次數）分配到不一樣的區域之中儲存
若是一個區域中大多數對象都是朝生夕滅，將他們集中到一塊兒，每次回收時只關注少許存活，能以較低代價回收到大量的空間
若是是難以消亡的對象，把他們集中放在一塊兒，虛擬機用較低頻率來回收這個區域，同時兼顧垃圾收集的時間開銷和內存的空間

Q3：如何根據各個年代的特色選擇算法呢？

新生代：大批對象死去，只有少許存活。使用『複製算法』，只需複製少許存活對象便可
老年代：對象存活率高。使用『標記—清理算法』或者『標記—整理算法』，只需標記較少的回收對象便可

這三種算法，筆者將在下文爲您詳細解析

2.2.2 複製算法

定義：把可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用盡後，把還存活着的對象『複製』到另一塊上面，再將這一塊內存空間一次清理掉
優勢：每次都是對整個半區進行內存回收， 無需考慮內存碎片等複雜狀況，只要移動堆頂指針，按順序分配內存便可， 實現簡單，運行高效
缺點：每次可以使用的內存縮小爲原來的一半， 內存使用率低

Appel式回收

分爲一塊較大的Eden空間和兩塊較小的Survivor空間，在HotSpot虛擬機中默認比例爲 8:1:1。每次使用Eden和一塊Survivor，回收時將這兩塊中存活着的對象一次性地複製到另一塊Survivor上，再作清理。可見只有10%的內存會被「浪費」，假若Survivor空間不足還須要依賴其餘內存（老年代）進行分配擔保

2.2.3 標記-清除算法

首先『標記』出全部須要回收的對象，而後統一『清除』全部被標記的對象
是最基礎的收集算法
缺點：

『標記』和『清除』過程的效率不高

空間碎片太多。『標記』『清除』以後會產生大量 不連續的內存碎片，可能會致使後續須要分配較大對象時，因沒法找到足夠的連續內存而提早觸發另外一次 GC，影響系統性能

2.2.4 標記-整理算法

首先『標記』出全部須要回收的對象，而後進行『整理』，使得存活的對象都向一端移動，最後直接清理掉端邊界之外的內存
優勢：即沒有浪費 50%的空間，又不存在空間碎片問題，性價比較高
缺點：移動在老年代每次回收都存在大量對象存活區域，必須 暫停用戶應用程序才能進行（ Stop The World）
通常狀況下，老年代會選擇標記-整理算法。

2.2.5 和稀泥式

解決方法：大部分時間使用標記-清除算法，當內存空間的碎片程度影響到內存分配，再使用標記-整理算法進行收集

2.3 `HotSpot`算法實現&垃圾回收器

接下來介紹如何在HotSpot虛擬機上實現對象存活斷定算法和垃圾收集算法，並保證虛擬機高效運行

2.3.1 枚舉根節點

主流JVM使用的都是準確式GC，在執行系統停頓以後無需檢查全部執行上下文和全局的引用位置，而是經過一些辦法直接獲取到存放對象引用的地方，在HotSpot中是經過一組稱爲OopMap的數據結構來實現的，完成類加載後會計算出對象某偏移量上某類型數據、JIT編譯時會在特定的位置記錄棧和寄存器中是引用的位置。這樣GC在掃描時就可直接得知這些信息，並快速準確地完成GC Roots的枚舉

2.3.2 安全點

上述「特定的位置」被稱爲安全點，即程序執行時並不是在全部地方都停頓執行GC，只在到達安全點時才暫停，下降GC的空間成本

安全點的選定標準：可以讓程序 長時間執行的地方，如方法調用、循環跳轉、異常跳轉等具備指令序列複用的特徵
使全部線程在 最近的安全點上再停頓的方案：

搶先式中斷：無需代碼主動配合，在 GC發生時把全部線程所有中斷，若線程中斷處不在安全點上就恢復線程，讓它「跑」到安全點上。如今 幾乎沒有虛擬機實現採用搶先式中斷來暫停線程從而響應 GC事件

主動式中斷：在 GC要中斷線程時不直接對線程操做，而是設置一箇中斷標誌，讓各個線程在執行時主動輪詢它，當中斷標誌爲真時就本身中斷掛起

2.3.3 安全區域

安全點機制只能保證程序執行時，在不太長的時間內遇到可進入GC的安全點，但在程序不執行時（如線程處於Sleep或Blocked狀態）線程沒法響應JVM的中斷請求，此時就須要安全區域來解決

安全區域：引用關係不會發生變化的一段代碼片斷，在安全區域中的任意地方開始GC都是安全的（由於引用關係不變），可看作是擴展的安全點
執行過程：

當線程執行到安全區域中的代碼時就標識一下，若是這時JVM要發起GC就不用管被標識的線程；

在線程要離開安全區域時檢查系統是否已經完成了根節點枚舉，若完成則線程能夠繼續執行，不然等待直到收到能夠安全離開安全區域的信號爲止

2.3.4 `JVM`中七種回收器

序號	收集器	收集範圍	算法	執行類型
1	`Serial`	新生代	複製	單線程
2	`ParNew`	新生代	複製	多線程並行
3	`Parallel`	新生代	複製	多線程並行
4	`Serial Old`	老年代	標記整理	單線程
5	`CMS`	老年代	標記清除	多線程併發
6	`Parallel Old`	老年代	標記整理	多線程
7	`G1`	所有	複製算法，標記-整理	多線程

注意併發和並行的概念：

在GC中：

**並行：* 多條*垃圾收集線程並行工做，而用戶線程仍處於等待狀態

併發： 垃圾收集線程與用戶線程一段時間內同時工做 (交替執行)

在普通情景中：

並行：**多個程序在多個 CPU**上同時運行，任意一個時刻能夠有不少個程序同時運行，互不干擾

併發：**多個程序在一個 CPU**上運行， CPU在多個程序之間快速切換，微觀上不是同時運行，任意一個時刻只有一個程序在運行，但宏觀上看起來就像多個程序同時運行同樣，由於 CPU切換速度很是快，時間片是 64ms（每 64ms切換一次，不一樣的操做系統有不一樣的時間），人類的反應速度是 100ms，你還沒反應過來， CPU已經切換了好幾個程序了

2.4 內存分配和回收策略

對象的內存分配廣義上是指在堆上分配，主要是在新生代的Eden區上，若是啓動了TLAB，將按線程優先在TLAB上分配，少數狀況下也可能會分配在老年代中。分配細節仍是取決於所使用的GC收集器組合以及虛擬機中與內存相關的參數的設置。如下介紹幾條廣泛的內存分配規則

對象優先在Eden分配：大多數狀況下對象在新生代 Eden區中分配，當 Eden區沒有足夠空間進行分配時虛擬機將發起一次 Minor GC

新生代 GC：發生在新生代的垃圾收集動做。較頻繁、回收速度也較快

老年代 GC（ Major GC/Full GC）：發生在老年代的垃圾收集動做。出現 Major GC常常會伴隨至少一次的 Minor GC。速度通常比 Minor GC慢 10 倍以上
大對象直接進入老年代：對於須要大量連續內存空間的 Java對象（如很長的字符串以及數組），若是大於虛擬機設定的 -XX：PretenureSizeThreshold參數值將直接在老年代分配。這樣作的目的是避免在 Eden區及兩個 Survivor區之間發生大量的內存複製
長期存活的對象將進入老年代：虛擬機會給每一個對象定義一個年齡計數器，當對象在 Eden出生並通過第一次 Minor GC後仍存活且能被 Survivor容納的話，將被移動到 Survivor空間中並將對象年齡設爲 1；當對象在 Survivor區中每「熬過」一次 Minor GC年齡就+1，直至增長到必定程度（默認爲 15 歲，可經過 -XX：MaxTenuringThreshold設置）就會被晉升到老年代中
動態對象年齡斷定：爲了能更好地適應不一樣程序的內存情況，虛擬機並不要求必定要達到 -XX：MaxTenuringThreshold設置值才能晉升到老年代，當 Survivor空間中相同年齡全部對象大小的總和大於 Survivor空間的一半，那麼年齡大於或等於該年齡的對象能夠直接進入老年代
空間分配擔保：在發生 Minor GC以前虛擬機會先檢查老年代最大可用的連續空間是否大於新生代全部對象總空間，如果，說明可確保 Minor GC是安全的，反之虛擬機會查看 -XX：HandlePromotionFailure設置值是否容許擔保失敗；若容許，會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小；若大於，將嘗試進行一次 Minor GC，若小於或者不容許擔保失敗，將改成進行一次 Full GC

解釋：當大量對象在MinorGC後仍然存活的狀況時，須要藉助老年代進行分配擔保，把Survivor沒法容納的對象直接進入老年代，但前提是老年代自己還有容納這些對象的剩餘空間，因爲在完成內存回收以前沒法預知實際存活對象，只好取以前每次回收晉升到老年代對象容量的平均大小值做爲經驗值，與老年代的剩餘空間進行比較，從而決定是否進行Full GC來讓老年代騰出更多空間

三.課堂小測試

恭喜你！已經看完了前面的文章，相信你對JVM GC&內存分配已經有必定深度的瞭解，下面，進行一下課堂小測試，驗證一下本身的學習成果吧！

Q1：垃圾回收算法你瞭解幾種？請你簡要分析一下，並說明其優缺點？

Q2：Java的引用機制有幾種？請簡要分析下，並說明其在Android中的應用場景有哪些？

Q3：安全點你瞭解過嗎？安全區呢？請你介紹下安全區相對安全點的優點在哪裏？

Q4：怎麼判斷對象是否存活呢？有幾種方法？

上面問題的答案，在前文都提到過，若是還不能回答出來的話，建議回顧下前文

若是文章對您有一點幫助的話，但願您能點一下贊，您的點贊，是我前進的動力。

做者：許朋友愛玩🔥

連接：https://juejin.im/post/5e815d2451882573c66ceec8

歡迎交流

在看和轉發

也是一種承認

本文分享自微信公衆號 - 賈小昆（zywudev）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。