醒酒菜：動畫圖解核心記憶體區--堆

阿Q說程式碼發表於2021-06-15
動畫圖解記憶體

端午佳節一下子就過完了，大家是不是還沉迷在假期的歡樂氣氛中無法自拔？今天阿Q為大家準備了上好的“醒酒菜”——JVM執行時資料區的核心記憶體區——堆。

堆的概述

一般來說：

  • 一個Java程式的執行對應一個程式；
  • 一個程式對應著一個JVM例項（JVM的啟動由引導類載入器載入啟動），同時也對應著多個執行緒；
  • 一個JVM例項擁有一個執行時資料區（Runtime類，為餓漢式單例類）；
  • 一個執行時資料區中的堆和方法區是多執行緒共享的，而本地方法棧、虛擬機器棧、程式計數器是執行緒私有的。

堆空間差不多是最大的記憶體空間，也是執行時資料區最重要的記憶體空間。堆可以處於物理上不連續的記憶體空間，但在邏輯上它應該被視為連續的。

在方法結束後，堆中的物件不會馬上被移除，僅僅在垃圾收集的時候才會被移除。堆，是GC(Garbage Collection，垃圾收集器)執行垃圾回收的重點區域。

堆記憶體大小設定

堆一旦被建立，它的大小也就確定了，初始記憶體預設為電腦實體記憶體大小的1/64，最大記憶體預設為電腦實體記憶體的1/4，但是堆空間的大小是可以調節，接下來我們來演示一下。

準備工具

JDK自帶記憶體分析的工具:在已安裝JDK的bin目錄下找到jvisualvm.exe。開啟該軟體，下載外掛Visual GC，一定要點選檢查最新版本，否則會導致安裝失敗。

安裝完重啟jvisualvm

程式碼樣例

public class HeapDemo {
    public static void main(String[] args) {
        System.out.println("start...");
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("end...");
    }
}

IDEA設定


  • -Xms10m用於表示堆區的起始記憶體為10m，等價於-XX:InitialHeapSize；
  • -Xmx10m用於表示堆區的最大記憶體為10m，等價於-XX:MaxHeapSize；
  • 其中-X是JVM的執行引數，ms是memory start

通常會將-Xms和-Xmx兩個引數配置相同的值，其目的就是為了能夠在java垃圾回收機制清理完堆區後不需要重新分隔計算堆區的大小，從而提高效能。

啟動程式

啟動程式之後去jvisualvm檢視

一旦堆區中的記憶體大小超過-Xmx所指定的最大記憶體時，將會丟擲OOM(Out Of MemoryError)異常。

堆的分代

儲存在JVM中的java物件可以被劃分為兩類：

  • 一類是生命週期較短的瞬時物件，這類物件的建立和消亡都非常迅速；
  • 另一類是生命週期非常長，在某些情況下還能與JVM的生命週期保持一致；

堆區分代

經研究表明70%-99%的物件屬於臨時物件，為了提高GC的效能，Hotspot虛擬機器又將堆區進行了進一步劃分。

如圖所示，堆區又分為年輕代（YoungGen）和老年代（OldGen）；其中年輕代又分為伊甸園區（Eden）和倖存者區（Survivor）；倖存者區分為倖存者0區（Survivor0，S0）和倖存者1區（Survivor1，S1），有時也叫from區和to區。

分代完成之後，GC時主要檢測新生代Eden區。

統一概念：

新生區<=>新生代<=>年輕代

養老區<=>老年區<=>老年代

幾乎所有的Java物件都是在Eden區被new出來的，有的大物件在該區存不下可直接進入老年代。絕大部分的Java物件都銷燬在新生代了（IBM公司的專門研究表明，新生代80%的物件都是“朝生夕死”的）。

新生代與老年代在堆結構的佔比

  • 預設引數-XX:NewRatio=2，表示新生代佔1，老年代佔2，新生代佔整個堆的1/3；
  • 可以修改-XX:NewRatio=4，表示新生代佔1，老年代佔4，新生代佔整個堆的1/5;

該引數在開發中一般不會調整，如果生命週期長的物件偏多時可以選擇調整。

Eden與Survivor在堆結構的佔比

在HotSpot中，Eden空間和另外兩個Survivor空間所佔的比例是8：1：1（測試的時候是6：1：1），開發人員可以通過選項-XX:SurvivorRatio調整空間比例，如-XX:SurvivorRatio=8

可以在cmd中通過jps 查詢程式號-> jinfo -flag NewRatio(SurvivorRatio) + 程式號 查詢配置資訊

-Xmn設定新生代最大記憶體大小（預設就好），如果既設定了該引數，又設定了NewRatio的值，則以該引數設定為準。

檢視設定的引數

以上邊的程式碼為例：設定啟動引數-XX:+PrintGCDetails；可在cmd視窗中輸入jps查詢程式號，然後通過jstat -gc 程式id指令檢視程式的記憶體使用情況。

圖解物件分配過程

物件分配過程

  1. new的物件先放伊甸園區，此區有大小限制；
  2. 當伊甸園的空間填滿時，程式繼續建立物件，JVM的垃圾回收器將對伊甸園區進行垃圾回收（Minor GC，也叫YGC)：將伊甸園區中的不再被其他物件所引用的物件進行銷燬，將未被銷燬的物件移動到倖存者0區並分配age；
  3. 然後再載入新的物件放到伊甸園區；
  4. 如果再次觸發垃圾回收，將此次未被銷燬的物件和上一次放在倖存者0區且此次也未被銷燬的物件一齊移動到倖存者一區，此時新物件的age為1，上次的物件的age加1變為2；
  5. 如果再次經歷垃圾回收，此時會重新放回倖存者0區，接著再去倖存者1區，age也隨之增加；
  6. 預設當age為15時，未被回收的物件將移動到老年區。可以通過設定引數來更改預設配置：-XX:MaxTenuringThreshold=<n>；該過程稱為晉升（promotion)；
  7. 在養老區，相對悠閒，當老年區記憶體不足時，再次觸發GC（Major GC），進行養老區的記憶體清理；
  8. 若養老區執行了Major GC之後發現依然無法進行物件的儲存，就會產生OOM異常。

S0，S1滿時不會觸發YGC，但是YGC會回收S0，S1的物件。

總結

  • 針對倖存者s0，s1區：複製之後有交換，誰空誰是to；
  • 關於垃圾回收：頻繁在新生區收集，很少在養老區收集，幾乎不再永久區/元空間收集。

物件特殊情況分配過程

  1. 新物件申請記憶體，如果Eden放的下，則直接存入Eden；如果存不下則進行YGC；
  2. YGC之後如果能存下則放入Eden，如果還存不下（為超大物件），則嘗試存入Old區；
  3. 如果Old區可以存放，則存入；如果不能存入，則進行Full GC；
  4. Full GC之後如果可以存入Old區，則存入；如果記憶體空間還不夠，則OOM；
  5. 圖右側為YGC的流程圖：當YGC之後未銷燬的物件放入倖存者區，此時如果倖存者區的空間可以裝下該物件，則存入倖存者區，否則，直接存入老年代；
  6. 當在倖存者區的物件超過閾值時，可以晉升為老年代，未達到閾值的依舊在倖存者區複製交換。

記憶體分配策略

針對不同年齡段的物件分配原則如下：

  1. 優先分配到Eden；
  2. 大物件直接分配到老年代：儘量避免程式中出現過多的大物件；
  3. 長期存活的物件分配到老年代；
  4. 動態物件年齡判斷：如果Survivor區中相同年齡的所有物件大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的物件可以直接進入到老年代。無需等到MaxTenuringThreshold中要求的年齡；

數值變小原理

程式碼樣例，設定引數:-Xms600m，-Xmx600m

public class HeapSpaceInitial {
    public static void main(String[] args) {

        //返回Java虛擬機器中的堆記憶體總量
        long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
        //返回Java虛擬機器試圖使用的最大堆記憶體量
        long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;

        System.out.println("-Xms : " + initialMemory + "M");
        System.out.println("-Xmx : " + maxMemory + "M");
        
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}
//執行結果
-Xms : 575M
-Xmx : 575M

明明設定的600M，怎麼變成575M了呢？這是因為在堆記憶體存取資料時，新生代裡邊只有伊甸園和倖存者1區或者是倖存者2區儲存物件，所以會少一個倖存者區的記憶體空間。

GC

JVM進行GC時，並非每次都對新生代、老年代、方法區（永久代、元空間）這三個區域一起回收，大部分回收是指新生代。

針對HotSpot VM的實現，它裡面的GC按照回收區域又分為兩大種型別：一種是部分收集（Partial GC），一種是整堆收集（Full GC）

Partial GC

部分收集：不是完整收集整個Java堆的垃圾收集。其中又分為：

  • 新生代收集（Minor GC/Young GC）：只是新生代的垃圾收集；
  • 老年代收集（Major GC/Old GC）：只是老年代的垃圾收集；
  • 混合收集（Mixed GC）：收集整個新生代以及部分老年代的垃圾收集，只有G1 GC （按照region劃分新生代和老年代的資料）會有這種行為。

目前，只有CMS GC會有單獨收集老年代的行為；很多時候Major GC會和Full GC 混淆使用，需要具體分辨是老年代回收還是整堆回收。

Full GC

整堆收集（Full GC）：整個java堆和方法區的垃圾收集。

觸發機制

年輕代GC（Minor GC）觸發機制
  1. 當年輕代空間不足時，就會觸發Minor GC，這裡的年輕代滿指的是Eden代滿，Survivor滿不會引發GC。(每次Minor GC會清理年輕代的記憶體，Survivor是被動GC，不會主動GC)
  2. 因為Java物件大多都具備“朝生夕滅”的特性，所以Minor GC非常頻繁，一般回收速度也比較快。
  3. Minor GC會引發STW（Stop The World），暫停其他使用者的執行緒，等垃圾回收結束，使用者執行緒才恢復執行。
老年代GC(Major GC/Full GC)觸發機制
  1. 指發生在老年代的GC，物件從老年代消失時，Major GC或者Full GC發生了；
  2. 出現了Major GC，經常會伴隨至少一次的Minor GC（不是絕對的，在Parallel Scavenge收集器的收集策略裡就有直接進行Major GC的策略選擇過程），也就是老年代空間不足時，會先嚐試觸發Minor GC。如果之後空間還不足，則觸發Major GC；
  3. Major GC速度一般會比Minor GC慢10倍以上，STW時間更長；
  4. 如果Major GC後，記憶體還不足，就報OOM了。
Full GC觸發機制

觸發Full GC執行的情況有以下五種：

  1. 呼叫System.gc()時，系統建議執行Full GC，但是不必然執行；
  2. 老年代空間不足；
  3. 方法區空間不足；
  4. 通過Minor GC後進入老年代的平均大小小於老年代的可用記憶體；
  5. 由Eden區，Survivor S0（from）區向S1（to）區複製時，物件大小大於To Space可用記憶體，則把該物件轉存到老年代，且老年代的可用記憶體小於該物件大小。

Full GC是開發或調優中儘量要避免的，這樣暫停時間會短一些。

以上就是今天的所有內容了，如果你有不同的意見或者更好的idea，歡迎聯絡阿Q：qingqing-4132，阿Q期待你的到來！

後臺留言領取java乾貨資料:學習筆記與大廠面試題

相關文章