堆

堆核心概述

• 此記憶體區域的唯一目的就是存放物件實體

• 一個JVM實體只存在一個堆記憶體,堆也是Java記憶體管理的核心區域，

• Java堆區在JVM啟動的時候即被創建,其空間大小也就確定了，是JVM管理的最大一塊記憶體空間，

  • 記憶體的大小是可以調節的，

• 《Java虛擬機規范》規定,堆可以處于物理上不連續的記憶體空間中,但在邏輯上它應該被視為連續的，

• 所有的執行緒共享Java堆,在這里還可以劃分執行緒私有的緩沖區(ThreadLocal Allocation Buffer, TLAB)

• 幾乎所有的物件實體都在堆里進行分配記憶體,一切從實際角度看

• 陣列和物件可能永遠不會存盤在堆疊上,因為堆疊幀中保存參考,這個參考指向物件或者陣列在堆中的位置，

• 在方法結束后,堆中的物件不會馬上被移除,僅僅在垃圾收集的時候才會被移除，

• 堆是GC ( Garbage Collection,垃圾收集器)執行垃圾回收的重點區域，

堆記憶體細分

現代垃圾收集器大部分都基于分代收集理論設計,堆空間細分為:

Java 7及之前堆記憶體邏輯上分為三部分:新生代+養老代+永久代

• Young Generation Space 新生代 Young/New
  • 又被劃分為Eden區和Survivor區
• Tenure Generation Space 養老代 Old/Tenure
• Permanent Space 永久代 Perm

Java 8及之后堆記憶體邏輯上分為三部分:新生代+養老代+元空間

• Young Generation Space 新生代 Young/New
  • 又被劃分為Eden區和Survivor區
• Tenure Generation Space 養老代 Old/Tenure
• Meta Space 元空間 Meta

設定堆大小與OOM

• Java堆區用于存盤Java物件實體,那么堆的大小在JVM啟動時就已經設定好了,可以通過選項"-Xmx"和"-Xms"來進行設定

  • "-Xms"用于表示堆區的起始記憶體,等價于-XX: InitialHeapsize

  • "-Xmx"則用于表示堆區的最大記憶體,等價于-XX:MaxHeapsize

• 一旦堆區中的記憶體大小超過"-Xmx"所指定的最大記憶體時,將會拋出OutOfMemoryError例外，

• 通常會將-Xms和-Xmx兩個引數配置相同的值,其目的是為了能夠在java垃圾回識訓制清理完堆區后不需要重新分隔計算堆區的大小,從而提高性能

• 默認情況下,初始記憶體大小:物理電腦記憶體大小/ 64 最大記憶體大小:物理電腦記憶體大小/4

注意:設定的堆大小不包含元空間(或永久代)

查看GC 控制臺jps 顯示正在運行程式id,然后使用 jstat -gc 程式id來查看gc情況,

 S0C    S1C    S0U    S1U      EC       EU        OC         OU     
512.0  512.0   32.0   0.0    5120.0   816.6    13824.0     3549.4  

最后帶C代表容量大小,U代表已經使用的容量

或者使用JVM啟動引數來列印GC情況

-XX:+PrintGCDetails

Heap
 PSYoungGen      total 2560K, used 1831K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
  eden space 2048K, 89% used [0x00000000ffd00000,0x00000000ffec9fb0,0x00000000fff00000)
  from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
  to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
 ParOldGen       total 7168K, used 0K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
  object space 7168K, 0% used [0x00000000ff600000,0x00000000ff600000,0x00000000ffd00000)
 Metaspace       used 3360K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 369K, capacity 388K, committed 512K, reserved 1048576K

OOM演示

JVM引數 -Xms100m -Xmx100m

public class ReturnAddressTest {

    public static void main(String[] args) throws InterruptedException {
        List<char[]> list=new ArrayList<>();

        while (true){
            Thread.sleep(1000);
            list.add(new char[1024*1024]);
        }
    }
}

錯誤

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at ReturnAddressTest.main(ReturnAddressTest.java:10)

因為不停的往list中添加資料,而且資料還不能被回收,導致堆空間滿了,出現例外

可以通過JDK自帶的可視化性能監控工具來查看,在jdk安裝目錄下,bin目錄下面jvisualvm.exe程式,打開后安裝visualGC插件即可

在上面操作欄上點擊工具,然后點擊插件就可以打開如下視窗

如果下載失敗,直接去官網下載完插件在添加到jvisualvm軟體中 https://visualvm.github.io/uc/8u131/updates.html

之后在軟體中添加該插件即可

啟動程式,在左邊程式欄中找到名稱對應的程式,然后點擊visual GC就可以實時查看堆情況了

年輕代與老年代

存活在JVM中的物件可以分為兩類,一類是生命周期較短的瞬時物件,這類物件的創建和消亡都非常迅速,另外一類物件的生命周期卻非常長,在某些極端的情況下還能夠與JVM的生命周期保持一致，

而在JVM堆記憶體中,又給分為年輕代(Young Generation)和老年代(Old Generation),年輕代中又分為伊甸園區(Ende)和from區(或者叫做Survivor0區)以及to區(或者叫做Survivor1區)

其中,它們的比例如下

年輕代整個占用堆空間的1/3,老年代占用整個堆空間的2/3,而Ende區占用年輕代的8/10,S1和S0分別占用年輕代的1/10

配置新生代與老年代在堆結構的占比，一般在開發中不建議更改

默認-XX: NewRatio-2,表示新生代占1,老年代占2,新生代占整個堆的1/3
修改-XX: NewRatio-4,表示新生代占1,老年代占4,新生代占整個堆的1/5

測驗,JVM引數 -Xms600m -Xmx600m,啟動后使用JDK自帶軟體VisualVM來查看

按理來說新生代和老年代為1:2,也就是說新生代為200m,老年代為400m,上面Eden區為150m加上s0區的25m和s1區25m為200m沒有問題

但是新生代中Eden區和s1,s0區比例為8:1:1,也就是說200m,Eden區為160m,s0和s1為20m,但是上面卻是150:25:25,這是因為JVM中的自適應記憶體分配策略

可以使用 -XX:SurvivorRatio=8 來手動設定Eden區和S0,S1的比例為8:1:1

幾乎所有的java物件都是在Eden區創建出來的,絕大部分的java物件的銷毀在新生代進行

物件分配程序

當程式啟動,物件開始創建會放在Eden區,當Eden區滿了會觸發一次MinorGC(或者叫做YoungGC),將沒有參考的物件清除,存在參考的物件移動到S0區,將移動過的物件年齡標識加1

這時Eden區為空,當第二次Eden區滿了后再次觸發MinorGC,將沒有參考的物件清除,存在參考的物件移動到S1區,同時檢查S0區中物件,如果沒有參考的物件清除,存在參考的物件也移動到S1區,將移動過的物件年齡標識加1

當物件年齡標志大于15將放入老年代

垃圾收集一般都是頻繁發生在年輕代,很少發生在老年代垃圾回收,幾乎不在元空間/永久代發生,對于垃圾回收之后會寫一篇詳細的博客

JVM在進行GC時,并非每次都對上面三個記憶體(新生代,老年代,方法區)區域一起回收,大部分回收都是指的新生代

針對HotSpot VM的實作,它里面的GC按斬訓收區域又分為兩大型別:一種是部分收集(Partial GC),一種是整堆收集(Full GC)

部分收集:不是完整的收集整個java堆的垃圾收集,其中又分為

• 新生代收集(Minor GC/Young GC):只是對新生代(Eden/S0/S1)的垃圾收集
• 老年代收集(Major GC/Old GC):只是對老年代(Old)的垃圾收集
• 混合收集(Mixed GC):收集整個新生代以及部分老年代的垃圾收集
  • 只有G1垃圾收集器會有這種行為

整堆收集(Full GC):收集整個java堆和方法區的垃圾收集

GC觸發條件

年輕代GC(Minor GC)觸發機制:

• 當年輕代空間不足時,就會觸發Minor GC,這里的年輕代滿了指的是Eden區滿,Survivor區滿不會引發GC (每次Minor GC會清理年輕代的記憶體)
• 因為java物件大多都具備朝生夕死的特性,所以Minor GC非常頻繁,一般回收速度也比較快
• Minor GC會引發STW(Stop The World) 暫停其他用戶執行緒,等垃圾回收結束,用戶執行緒才恢復運行

老年代GC(Major GC/Full GC)觸發機制

• 指發生在老年代的GC,從物件從老年代消失時,我們說"Major GC"或"Full GC"發生了
• 出現了Major GC經常會伴隨著至少一次的Minor GC(但是并非絕對的,在ParallelScavenge收集器的收集策略里就有直接進行Major GC的策略選擇程序)
• 也就是在老年代空間不足時,會先嘗試觸發Minor GC,如果之后空間還是不足則觸發Major GC
• Major GC的速度一般會比Minor GC慢十倍以上,STW時間更長
• 如果Major GC后記憶體還是不足,就報OOM了
• Major GC的速度一般

Full GC觸發機制

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

1. 呼叫System.gc()時.系統建議執行Full GC 但是不是必然執行
2. 老年代空間不足
3. 方法區空間不足
4. 通過Minor GC后進入老年代的平均大小大于老年代的可用記憶體
5. 由Eden區,S0區向S1區進行復制時,物件大小大于S1可用記憶體,則把該物件轉存到老年代,且老年代的可用記憶體小于該物件大小

堆空間分代思想

為什么需要把堆空間進行分代?

絕大多數的物件都是朝生夕死的,如果把一些生命周期比較短的物件和一些生命周期比較長的物件放在一起,那么每次GC都必須將全部物件掃描一遍來確定哪些物件需要回收,如果生命周期比較長的物件比較多,那么每次GC都需要做很多無用的掃描,所以將堆分為兩個部分,一部分單獨來存盤生命周期比較短的物件,GC也可以明確掃描的物件,能夠更加高效的進行垃圾回收

記憶體分配策略(物件提升(Promotion)原則)

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

• 優先分配到Eden
• 大物件直接分配到老年代
• 長期存活物件分配到老年代
• 動態物件年齡判斷:如果Survivor區中相同年齡的所有物件大小的總和大于Survivor空間的一半,年齡大于或等于該年齡物件可以直接進入老年代,無須等到閾值年齡

TLAB

為什么有TLAB(Thread Loacl Allocation Buffer)?

先來看物件的創建程序,為物件分配空間的任務等同于在java堆中劃分一塊大小確定的記憶體出來,假設java堆空間記憶體是絕對規整的,所有使用過的記憶體都放在一邊,沒有使用過的記憶體放在另一半,中間放著一個指標作為分界點的指示器,當分配記憶體就僅僅是把指標想空閑的空間移動一段與物件大小相等的距離,這種分配方法稱為指標碰撞(Bump The Pointer)

物件創建在虛擬機中是非常頻繁的行為,即使僅僅修改一個指標所指向的位置,在并發情況下也并不是執行緒安全的,可能出現正在給物件A分配記憶體,指標還沒來得及修改,物件B又使用了原來的指標來分配記憶體的情況

解決方案其一就是使用本地執行緒分配緩沖(TLAB),從記憶體模型而不是垃圾收集角度來看,對Eden區繼續進行劃分,JVM為每個執行緒分配了一個私有快取區域,它包含在Eden區內,即每個執行緒在java堆中預先分配一小塊記憶體,哪個執行緒需要分配記憶體,就在哪個執行緒的本地緩沖區中分配,當本地緩沖使用完了,分配新的快取區時才需要同步鎖定

盡管不是所有物件實體都能在TLAB中成功分配記憶體,但是JVM確定是將TLAB作為記憶體分配的首選,可以通過選項 -XX:UseTLAB 設定是否開啟TLAB空間,默認的情況下TLAB占用的記憶體非常小,僅占用Eden空間的1%,當然也可以通過選項

-XX:TLABWasteTargetPercent 來設定TLAB空間所占用Eden空間的百分比大小,一旦物件在TLAB空間分配失敗時,JVM會嘗試通過加鎖機制確保資料操作的原子性,從而直接在Eden區分配記憶體

堆常用引數

-XX:+PrintFlagsInitial 查看所有引數的默認初始值

-XX:+PrintFlagsFinal 查看所有引數的最終值

-Xms 初始堆空間記憶體(默認為物理記憶體的1/64)

-Xmx 最大堆空間記憶體(默認為物理記憶體1/4)

-XX:NewRatio 配置新生代與老年代在堆結構占比

-XX:SurvivorRatio 設定新生代中Eden區和S0,S1區空間比例

-XX:MaxTenuringThreshold 設定新生代垃圾的最大年齡

-XX:+PrintGCDetails 輸出詳細的GC處理日志

-XX:HandlePromotionFailure 是否設定空間分配擔保

關于-XX:HandlePromotionFailure引數再來詳細介紹一下

在發生Minor GC之前,虛擬機會檢查老年代最大可用的連續記憶體空間是否大于新生代所有物件的總空間

如果大于,則此次Minor GC是安全的

如果小于,則虛擬機檢查-XX:HandlePromotionFailure設定的值是否允許擔保失敗

? 如果HandlePromotionFailure=true,那么繼續檢查老年代最大可用的連續記憶體空間是否大于歷次晉升到老年代的物件平均大小

? 如果大于,則嘗試進行一次Minor GC,但這次Minor GC依然是有風險的

? 如果小于,則改為進行一次Full GC

? 如果HandlePromotionFailure=false,則改為進行一次Full GC

老年代最大可用的連續記憶體空間是否大于歷次晉升到老年代的物件平均大小意思是,例如已經經歷過兩次Minor GC,晉升到老年代的物件平均占用記憶體為15m,而現在最大可用的連續記憶體空間大于15m,則進行一次Minor GC,否則改為進行Full GC

在JDK6 Update24之后,HandlePromotionFailure引數不會再影響到虛擬機的空間分配擔保策略,JDK6 Update24之后的規則改為

只要老年代的連續空間大于新生代物件總大小或者歷次晉升的平均大小就會進行Minor GC否則進行Full GC

堆是分配物件存盤的唯一選擇嗎

隨著JIT編譯器的發展與逃逸分析技術逐漸成熟,堆疊上分配,標量替換優化技術將會導致一些微妙的變化,所有的物件都分配到堆上也漸漸變的不那么"絕對"了,在java虛擬機中,物件是在java堆中分配記憶體的,這是一個普遍的常識,但是有些特殊情況,那就是如果經過逃逸分析后發現,一個物件并沒有逃逸出方法的話,那么就可能被優化為堆疊上分配了,這樣也就無需再堆上分配記憶體,也無需進行垃圾回收了,這也是常見的堆外存盤的技術

逃逸分析概述

如果將堆上物件分配到堆疊,需要使用逃逸分析手段,這是一種可以有效級訓java程式中同步負載和記憶體堆分配壓力的跨函式全域資料流分析演算法,通過逃逸分析,java HotSpot編譯器能夠分析出一個新的物件參考的使用范圍從而決定是否要將這個物件分配到堆上

逃逸分析的基本行為就是分析物件的動態作用域

• 當一個物件在方法中被定義后,物件只在方法內部使用,則認為沒有發生逃逸
• 當一個物件在方法中被定義后,它在外部方法所參考,則認為發生逃逸,例如作為引數傳遞到其他地方中

沒有發生逃逸的物件,則可以分配到堆疊上,隨著方法執行的結束,堆疊空間就被移除

判斷是否發生了逃逸,就看new的物件物體是否有可能在方法外被呼叫

逃逸分析:代碼優化

使用逃逸分析,編譯器可以對代碼進行如下優化

1. 堆疊上分配,將堆分配轉化為堆疊分配,如果一個物件在子程式中被分配,要使指向該物件的指標永遠不會逃逸,物件可能是堆疊分配的候選,而不是堆分配
2. 同步消除,如果一個物件被發現只能從一個執行緒被訪問到,那么對于這個物件的操作可以不考慮同步
3. 分離物件或標量替換,有的物件可能不需要作為一個連續的記憶體結構存在也可以被訪問到,那么物件的部分,(或全部)可以不存盤在記憶體,而是存盤在CPU暫存器中

堆疊上分配

JIT編譯器在編譯期間根據逃逸分析結果,發現如果一個物件并沒有逃逸出方法的話,就可能被優化為堆疊上分配,分配完成后,繼續在呼叫堆疊內執行,最后執行緒結束,堆疊空間被回收,區域變數物件也被回收,這樣就無需進行垃圾回收了

常見堆疊上分配的場景:給成員變數賦值,方法回傳值,實體參考傳遞

-DoEscapeAnalysis 關閉逃逸分析 +就是開啟逃逸分析

測驗 引數 -Xms256m -Xmx256m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails

public class StackAllocation {
    public static void main(String[] args)   {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println("花費時間"+(end-start)+"ms");

    }
    private static void alloc(){
        User user = new User();
    }
    static class User{

    }
}

結果

[GC (Allocation Failure) [PSYoungGen: 65536K->840K(76288K)] 65536K->848K(251392K), 0.0008785 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 66376K->808K(76288K)] 66384K->816K(251392K), 0.0006700 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
花費時間42ms
Heap
 PSYoungGen      total 76288K, used 32077K [0x00000000fab00000, 0x0000000100000000, 0x0000000100000000)
  eden space 65536K, 47% used [0x00000000fab00000,0x00000000fc9895d0,0x00000000feb00000)
  from space 10752K, 7% used [0x00000000ff580000,0x00000000ff64a020,0x0000000100000000)
  to   space 10752K, 0% used [0x00000000feb00000,0x00000000feb00000,0x00000000ff580000)
 ParOldGen       total 175104K, used 8K [0x00000000f0000000, 0x00000000fab00000, 0x00000000fab00000)
  object space 175104K, 0% used [0x00000000f0000000,0x00000000f0002000,0x00000000fab00000)
 Metaspace       used 3452K, capacity 4500K, committed 4864K, reserved 1056768K
  class space    used 376K, capacity 388K, committed 512K, reserved 1048576K

可以看到發生兩次GC,將-XX:-DoEscapeAnalysis關閉逃逸分析改為-XX:+DoEscapeAnalysis開啟逃逸分析再來看看

花費時間3ms
Heap
 PSYoungGen      total 76288K, used 6559K [0x00000000fab00000, 0x0000000100000000, 0x0000000100000000)
  eden space 65536K, 10% used [0x00000000fab00000,0x00000000fb167c28,0x00000000feb00000)
  from space 10752K, 0% used [0x00000000ff580000,0x00000000ff580000,0x0000000100000000)
  to   space 10752K, 0% used [0x00000000feb00000,0x00000000feb00000,0x00000000ff580000)
 ParOldGen       total 175104K, used 0K [0x00000000f0000000, 0x00000000fab00000, 0x00000000fab00000)
  object space 175104K, 0% used [0x00000000f0000000,0x00000000f0000000,0x00000000fab00000)
 Metaspace       used 3452K, capacity 4500K, committed 4864K, reserved 1056768K
  class space    used 376K, capacity 388K, committed 512K, reserved 1048576K

沒有發生GC,且時間比上面快了很多倍

同步消除

執行緒同步本身是一個相對耗時的程序,如果逃逸分析能確定一個變數不會逃逸出執行緒,無法被其他執行緒訪問,那么這個變數的讀寫肯定不會有競爭對于這個變數實施的同步措施也就可以安全的清除掉

分離物件(標量替換)

標量(Scalar)指的是無法再分解成更小的資料的資料,java中的原始資料型別就是標量,相對的,那些可以被分解的資料就叫做聚合量(Aggregate) java中的物件就是聚合量,因為它可以分解為其他聚合量和標量,JIT階段,如果經過逃逸分析,發現一個物件不允許被外界訪問的話,那么經過JIT優化,就會把這個物件拆解成若干個其中包含的若干個成員變數來替代,這個程序就是標量替換

public class Scalar {
    public static void main(String[] args) {
        showUser();
    }
    public static void showUser(){
        User user = new User(1,"jame");
        System.out.println(user.id+"=="+user.name);
    }
    static class User{
        int id;
        String name;

        public User(int id, String name) {
            this.id = id;
            this.name = name;
        }
    }
}

上面代碼經過標量替換后,就會變成

public static void showUser(){
    int id=1;
    String name="jame";
    System.out.println(id+"=="+name);
}

可以看到,經過逃逸分析后,發現并沒有逃逸,所以被替換成兩個標量,那么這樣做有什么好處呢?可以大大減少占用堆記憶體,因為一旦不需要創建物件了,那么就不需要分配堆記憶體了

逃逸分析并不成熟

關于逃逸分析論文在1999年就已經發表,但直到JDK1.6才有實作,而且這項技術直到如今也并不是十分成熟,根本原因就是逃逸分析的計算成本非常高,甚至不能保證逃逸分析帶來的性能收益會大于它的消耗,如果要百分百確定一個物件是否發生逃逸,需要進行一系列復雜的資料的分析,如果逃逸分析完畢后發現幾乎找不到不逃逸的物件,那么這種運行期間耗用的時間就白白浪費了,在HotSpot虛擬機中,并沒有做堆疊上分配的優化,而前面演示堆疊上優化的原因是因為標量替換的優化帶來的

小結

年輕代是物件的誕生,成長的區域,物件一般都會在年輕代的Eden區來創建,老年代放置的一般都是生命周期比較長的物件,通常都是從Survivor區域篩選拷貝過來的java物件,當然也會有特殊情況,普通的物件會被分配到TLAB上,如果物件比較大,JVM會嘗試直接分配在Eden區的其他位置上,如果物件太大,完全無法在新生代找到足夠的連續空閑空間,JVM會直接分配到老年代

當GC只發生在年輕代中,回收年輕代物件的行為被稱為Minor GC 當GC發生在老年代時則被稱為Major GC,或者Full GC,但是建議不要混淆在一起,Major GC指單獨對老年代進行垃圾回收的操作,而Full GC 指對整個堆進行垃圾回收,一般情況下Minor GC發生的頻率要比Major GC 發生的頻率高跟多

標籤：Java

上一篇：Soul中使用的zookeeper監聽功能嘗試和nacos同步原始碼解讀

下一篇：最牛逼的性能監控系統，SkyWalking 集強大于一身！