JVM的藝術-物件創建與記憶體分配機制深度剖析

引言

本章將介紹jvm的物件創建與記憶體分配，徹底帶你了解jvm的創建程序以及記憶體分配的原理和區域，以及包含的內容，

物件的創建

類加載的程序

固定的類加載執行順序: 加載驗證準備初始化卸載的執行順序是一定的為什么決議程序沒有在這個執行順序中？(接下來分析)

什么時候觸發類加載不一定，但是類的初始化如下四種情況就要求一定初始化，但是初始化之前就一定會執行 加載驗證準備三個階段，

觸發類加載的程序(由初始化程序引起的類加載)

1):使用new 關鍵字獲取一個靜態屬性設定一個靜態屬性呼叫一個靜態方法，

? int myValue = https://www.cnblogs.com/tomakemyself/p/SuperClass.value;會導致父類初始化，但是不會導致子類初始化

? SuperClass.Value = https://www.cnblogs.com/tomakemyself/p/3 ; 會導致父類初始化，不會導致子類初始化，

? SubClass.staticMethod(); 先初始化父類再初始化子類

? SubClass sc = new SubClass(); 先初始化父類子類初始化子類

2):使用反射的時候，若發現類還沒有初始化，就會進行初始化

? Class clazz = Class.forName("com.hnnd.classloader.SubClass");

3):在初始化一個類的時，若發現其父類沒有初始化，就會先初始化父類

? SubClass.staticMethod(); 先初始化父類在初始化子類

4):啟動虛擬機的時候，需要加載包含main方法的類.

class SuperClass{
    public static int value = 5;

    static {
        System.out.println("Superclass ...... init........");
    }
}
    
class SubClass extends SuperClass {

    static {
        System.out.println("subClass********************init");
    }

    public static void staticMethod(){
        System.out.println("superclass value"+SubClass.value);
    }
}

1:加載

1.1)根據全類名獲取到對應類的位元組碼流(位元組流的來源 class 檔案，網路檔案，還有反射的Proxygeneraotor.generaotorProxyClass)

1.2)把位元組流中的靜態資料結構加載到方法區中的運行時資料結構

1.3)在記憶體中生成java.lang.Class物件，可以通過該物件來操作方法區中的資料結構(通過反射)

2:驗證

檔案格式的驗證: 驗證class檔案開頭的0XCAFFBASE 開頭

? 驗證主次版本號是否在當前的虛擬機的范圍之類

? 檢測jvm不支持的常量型別

元資料的校驗:

? 驗證本類是否有父類

? 驗證是否繼承了不允許繼承的類(final)修飾的類

? 驗證本類不是抽象類的時候，是否實作了所有的介面和父類的介面

位元組碼驗證:驗證跳轉指令跳轉到方法以外的指令.

? 驗證型別轉換是否為有效的，比如子類物件賦值父類的參考是可以的，但是把父類物件賦值給子類參考是危險的

? 總而言之:位元組碼驗證通過，并不能說明該位元組碼一定沒有問題，但是位元組碼驗證不通過，那么該位元組碼檔案一定是有問題：，

? 符號參考的驗證(發生在決議的程序中)：

? 通過字串描述的全類名是否能找到對應的類，

? 指定類中是否包含欄位描述符，以及簡單的欄位和方法名稱，

3:準備:為類變數分配記憶體以及設定初始值，

? 比如public static int value = https://www.cnblogs.com/tomakemyself/p/123;

? 在準備的程序中 value=https://www.cnblogs.com/tomakemyself/p/0 而不是123 ，當執行類的初始化的方法的時候，value=123

? 若是一個靜態常量

? public static final int value = https://www.cnblogs.com/tomakemyself/p/9; 那么在準備的程序中value為9.

4:決議：把符號參考替換成直接參考

? 符號參考分類:

? CONSTANT_Class_info 類或者介面的符號參考

? CONSTANT_Fieldref_info 欄位的符號參考

? CONSTANT_Methodref_info 方法的符號參考

? CONSTANT_intfaceMethodref_info- 介面中方法的符號參考

? CONSTANT_NameAndType_info 子類或者方法的符號參考.

? CONSTANT_MethodHandle_Info 方法句柄

? CONSTANT_InvokeDynamic_Info 動態呼叫

直接參考:

? 指向物件的指標

? 相對偏移量

? 操作句柄

5:初始化：類的初始化時類加載的最后一步:執行類的構造器，為所有的類變數進行賦值(編譯器生成CLInit<>)

? 類構造器是什么？：類構造器是編譯器按照Java源檔案總類變數和靜態代碼塊出現的順序來決定

? 靜態陳述句只能訪問定義在靜態陳述句之前的類變數，在其后的靜態變數能賦值但是不能訪問，

? 父類中的靜態代碼塊優先于子類靜態代碼塊執行，

? 若類中沒有靜態代碼塊也沒有靜態類變數的話，那么編譯器就不會生成 Clint<>類構造器的方法，

public class TestClassInit {
	public static void main(String[] args) {
		System.out.println(SubClass.sub_before_v);
	}
}

class SubClass extends SuperClass{
	public static int sub_before_v = 5;
	static {
		sub_before_v = 10;
		System.out.println("subclass init.......");
		sub_after_v=0;
		//拋錯,static代碼塊中的代碼只能賦值后面的類變數 但是不能訪問，
		sub_before_v = sub_after_v;
	}
	public static int sub_after_v = 10;
}

class SuperClass {
	public static int super_before_v = 5;
	static{
		System.out.println("superclass init......");
	}
	public static int super_after_v = 10;
}

6:使用

7:卸載

1.****類加載檢查

虛擬機遇到一條new指令時，首先將去檢查這個指令的引數是否能在常量池中定位到一個類的符號參考，并且檢查這個

符號參考代表的類是否已被加載、決議和初始化過，如果沒有，那必須先執行相應的類加載程序，

new指令對應到語言層面上講是，new關鍵詞、物件克隆、物件序列化等，

2.****分配記憶體

在類加載檢查通過后，接下來虛擬機將為新生物件分配記憶體，物件所需記憶體的大小在類加載完成后便可完全確定，為

物件分配空間的任務等同于把一塊確定大小的記憶體從Java堆中劃分出來，

這個步驟有兩個問題：

1.如何劃分記憶體，

2.在并發情況下，可能出現正在給物件A分配記憶體，指標還沒來得及修改，物件B又同時使用了原來的指標來分配記憶體的

情況，

劃分記憶體的方法：

記憶體的方法：

“指標碰撞”（Bump the Pointer）(默認用指標碰撞)

假設Java堆中記憶體時完整的，已分配的記憶體和空閑記憶體分別在不同的一側，通過一個指標作為分界點，需要分配記憶體時，

僅僅需要把指標往空閑的一端移動與物件大小相等的距離，使用的GC收集器：Serial、ParNew，適用堆記憶體規整（即沒有記憶體碎片）的情況下，

“空閑串列”（Free List）

事實上，Java堆的記憶體并不是完整的，已分配的記憶體和空閑記憶體相互交錯，JVM通過維護一個串列，記錄可用的記憶體塊資訊，當分配操作發生時，從串列中找到一個足夠大的記憶體塊分配給物件實體，并更新串列上的記錄，使用的GC收集器：CMS，適用堆記憶體不規整的情況下，

解決并發問題的方法：

CAS（compare and swap）

虛擬機采用CAS配上失敗重試的方式保證更新操作的原子性來對分配記憶體空間的動作進行同步處理，

本地執行緒分配緩沖（Thread Local Allocation Buffer,TLAB）

把記憶體分配的動作按照執行緒劃分在不同的空間之中進行，即每個執行緒在Java堆中預先分配一小塊記憶體，通過-XX:+/-

UseTLAB引數來設定虛擬機是否使用TLAB(JVM會默認開啟-XX:+****UseTLAB)，-XX:TLABSize 指定TLAB大小，

3.****初始化

記憶體分配完成后，虛擬機需要將分配到的記憶體空間都初始化為零值（不包括物件頭），如果使用TLAB，這一作業程序也

可以提前至TLAB分配時進行，這一步操作保證了物件的實體欄位在Java代碼中可以不賦初始值就直接使用，程式能訪問

到這些欄位的資料型別所對應的零值，

什么是 TLAB

TLAB （Thread Local Allocation Buffer，執行緒本地分配緩沖區）是 Java 中記憶體分配的一個概念，它是在 Java 堆中劃分出來的針對每個執行緒的記憶體區域，專門在該區域為該執行緒創建的物件分配記憶體，它的主要目的是在多執行緒并發環境下需要進行記憶體分配的時候，減少執行緒之間對于記憶體分配區域的競爭，加速記憶體分配的速度，TLAB 本質上還是在 Java 堆中的，因此在 TLAB 區域的物件，也可以被其他執行緒訪問，

如果沒有啟用 TLAB，多個并發執行的執行緒需要創建物件、申請分配記憶體的時候，有可能在 Java 堆的同一個位置申請，這時就需要對擬分配的記憶體區域進行加鎖或者采用 CAS 等操作，保證這個區域只能分配給一個執行緒，

啟用了 TLAB 之后(-XX:+UseTLAB, 默認是開啟的)，JVM 會針對每一個執行緒在 Java 堆中預留一個記憶體區域，在預留這個動作發生的時候，需要進行加鎖或者采用 CAS 等操作進行保護，避免多個執行緒預留同一個區域，一旦某個區域確定劃分給某個執行緒，之后該執行緒需要分配記憶體的時候，會優先在這片區域中申請，這個區域針對分配記憶體這個動作而言是該執行緒私有的，因此在分配的時候不用進行加鎖等保護性的操作，

4.****設定物件頭

初始化零值之后，虛擬機要對物件進行必要的設定，例如這個物件是哪個類的實體、如何才能找到類的元資料資訊、對

象的哈希碼、物件的GC分代年齡等資訊，這些資訊存放在物件的物件頭Object Header之中，

在HotSpot虛擬機中，物件在記憶體中存盤的布局可以分為3塊區域：物件頭（Header）、實體資料（Instance Data）

和對齊填充（Padding）， HotSpot虛擬機的物件頭包括兩部分資訊，第一部分用于存盤物件自身的運行時資料，如哈

希碼（HashCode）、GC分代年齡、鎖狀態標志、執行緒持有的鎖、偏向執行緒ID、偏向時間戳等，物件頭的另外一部分

是型別指標，即物件指向它的類元資料的指標，虛擬機通過這個指標來確定這個物件是哪個類的實體，

物件頭在hotspot的C++原始碼里的注釋如下：

1 Bit‐format of an object header (most significant first, big endian layout below): 
2 // 
3 // 32 bits: 
4 // ‐‐‐‐‐‐‐‐ 
5 // hash:25 ‐‐‐‐‐‐‐‐‐‐‐‐>| age:4 biased_lock:1 lock:2 (normal object) 
6 // JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object) 
7 // size:32 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐>| (CMS free block) 
8 // PromotedObject*:29 ‐‐‐‐‐‐‐‐‐‐>| promo_bits:3 ‐‐‐‐‐>| (CMS promoted object) 
9 // 
10 // 64 bits: 
11 // ‐‐‐‐‐‐‐‐ 
12 // unused:25 hash:31 ‐‐>| unused:1 age:4 biased_lock:1 lock:2 (normal object) 
13 // JavaThread*:54 epoch:2 unused:1 age:4 biased_lock:1 lock:2 (biased object) 
14 // PromotedObject*:61 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐>| promo_bits:3 ‐‐‐‐‐>| (CMS promoted object) 
15 // size:64 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐>| (CMS free block) 
16 // 
17 // unused:25 hash:31 ‐‐>| cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && normal object) 
18 // JavaThread*:54 epoch:2 cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && biased object) 
19 // narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ‐‐‐‐‐>| (COOPs && CMS promoted object) 
20 // unused:21 size:35 ‐‐>| cms_free:1 unused:7 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐>| (COOPs && CMS free block)

5.執行****方法

執行方法，即物件按照程式員的意愿進行初始化，對應到語言層面上講，就是為屬性賦值（注意，這與上面的賦

零值不同，這是由程式員賦的值），和執行構造方法，

物件大小與指標壓縮

物件大小可以用jol-core包查看，引入依賴

 <dependency> 
     <groupId>org.openjdk.jol</groupId> 
     <artifactId>jol‐core</artifactId>
 <version>0.9</version> 5 </dependency>

1 import org.openjdk.jol.info.ClassLayout; 
2
3 /** 
4 * 計算物件大小 
5 */ 
6 public class JOLSample { 
7
8 	public static void main(String[] args) { 
9 		ClassLayout layout = ClassLayout.parseInstance(new Object()); 
10 		System.out.println(layout.toPrintable()); 
11
12 		System.out.println(); 
13 		ClassLayout layout1 = ClassLayout.parseInstance(new int[]{}); 
14 		System.out.println(layout1.toPrintable()); 
15
16 		System.out.println(); 
17 		ClassLayout layout2 = ClassLayout.parseInstance(new A()); 
18 		System.out.println(layout2.toPrintable()); 
19 	} 
20
21 	// ‐XX:+UseCompressedOops 默認開啟的壓縮所有指標 
22 	// ‐XX:+UseCompressedClassPointers 默認開啟的壓縮物件頭里的型別指標Klass Pointer 
23 	// Oops : Ordinary Object Pointers 
24 	public static class A { 
25 		//8B mark word 
26 		//4B Klass Pointer 如果關閉壓縮‐XX:‐UseCompressedClassPointers或‐XX:‐UseCompressedOops，則占用8B 
27 		int id; //4B 
28 		String name; //4B 如果關閉壓縮‐XX:‐UseCompressedOops，則占用8B 
29 		byte b; //1B 
30 		Object o; //4B 如果關閉壓縮‐XX:‐UseCompressedOops，則占用8B 
31 	} 
32 } 
33
34
35 運行結果： 
36 java.lang.Object object internals: 
37 OFFSET SIZE TYPE DESCRIPTION VALUE 
38 0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1) //mark word 
39 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) //mark word 
40 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (‐134217243) //Klass Pointer 
41 12 4 (loss due to the next object alignment) 
42 Instance size: 16 bytes 
43 Space losses: 0 bytes internal + 4 bytes external = 4 bytes total 
44
45
46 [I object internals: 
                                                                                     
47 OFFSET SIZE TYPE DESCRIPTION VALUE 
48 0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1) 
49 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 
50 8 4 (object header) 6d 01 00 f8 (01101101 00000001 00000000 11111000) (‐134217363) 
51 12 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 
52 16 0 int [I.<elements> N/A 
53 Instance size: 16 bytes 
54 Space losses: 0 bytes internal + 0 bytes external = 0 bytes total 
55
56
57 com.tuling.jvm.JOLSample$A object internals: 58 OFFSET SIZE TYPE DESCRIPTION VALUE
58 OFFSET SIZE TYPE DESCRIPTION VALUE
59 0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000
60 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
61 8 4 (object header) 61 cc 00 f8 (01100001 11001100 00000000 11111000) (‐134165407)
62 12 4 int A.id 0 
63 16 1 byte A.b 0 
64 17 3 (alignment/padding gap) 
65 20 4 java.lang.String A.name null
66 24 4 java.lang.Object A.o null
67 28 4 (loss due to the next object alignment) 
68 Instance size: 32 bytes 69 Space losses: 3 bytes internal + 4 bytes external = 7 bytes total

什么是java物件的指標壓縮？

1.jdk1.6 update14開始，在64bit作業系統中，JVM支持指標壓縮

2.jvm配置引數:UseCompressedOops，compressed--壓縮、oop(ordinary object pointer)--物件指標

3.啟用指標壓縮:-XX:+UseCompressedOops(默認開啟)，禁止指標壓縮:-XX:-UseCompressedOops

為什么要進行指標壓縮？

1.在64位平臺的HotSpot中使用32位指標，記憶體使用會多出1.5倍左右，使用較大指標在主記憶體和快取之間移動資料，

占用較大寬帶，同時GC也會承受較大壓力

2.為了減少64位平臺下記憶體的消耗，啟用指標壓縮功能

3.在jvm中，32位地址最大支持4G記憶體(2的32次方)，可以通過對物件指標的壓縮編碼、解碼方式進行優化，使得jvm

只用32位地址就可以支持更大的記憶體配置(小于等于32G)

4.堆記憶體小于4G時，不需要啟用指標壓縮，jvm會直接去除高32位地址，即使用低虛擬地址空間

5.堆記憶體大于32G時，壓縮指標會失效，會強制使用64位(即8位元組)來對java物件尋址，這就會出現1的問題，所以堆內

存不要大于32G為好 .

物件記憶體分配

物件記憶體分配流程圖

物件堆疊上分配

我們通過JVM記憶體分配可以知道JAVA中的物件都是在堆上進行分配，當物件沒有被參考的時候，需要依靠GC進行回收內

存，如果物件數量較多的時候，會給GC帶來較大壓力，也間接影響了應用的性能，為了減少臨時物件在堆內分配的數量，JVM通過逃逸分析確定該物件不會被外部訪問，如果不會逃逸可以將該物件在堆疊上分配記憶體，這樣該物件所占用的

記憶體空間就可以隨堆疊幀出堆疊而銷毀，就減輕了垃圾回收的壓力，

物件逃逸分析：就是分析物件動態作用域，當一個物件在方法中被定義后，它可能被外部方法所參考，例如作為呼叫參

數傳遞到其他地方中，

很顯然test1方法中的user物件被回傳了，這個物件的作用域范圍不確定，test2方法中的user物件我們可以確定當方法結

束這個物件就可以認為是無效物件了，對于這樣的物件我們其實可以將其分配在堆疊記憶體里，讓其在方法結束時跟隨堆疊內

存一起被回收掉，

JVM對于這種情況可以通過開啟逃逸分析引數(-XX:+DoEscapeAnalysis)來優化物件記憶體分配位置，使其通過標量替換優

先分配在堆疊上(堆疊上分配)，JDK7之后默認開啟逃逸分析，如果要關閉使用引數(-XX:-DoEscapeAnalysis)

標量替換：通過逃逸分析確定該物件不會被外部訪問，并且物件可以被進一步分解時，JVM不會創建該物件，而是將該

物件成員變數分解若干個被這個方法使用的成員變數所代替，這些代替的成員變數在堆疊幀或暫存器上分配空間，這樣就

不會因為沒有一大塊連續空間導致物件記憶體不夠分配，開啟標量替換引數(-XX:+EliminateAllocations)，JDK7之后默認

開啟，

標量與聚合量：標量即不可被進一步分解的量，而JAVA的基本資料型別就是標量（如：int，long等基本資料型別以及

reference型別等），標量的對立就是可以被進一步分解的量，而這種量稱之為聚合量，而在JAVA中物件就是可以被進一

步分解的聚合量，

堆疊上分配示例：

結論：****堆疊上分配依賴于逃逸分析和標量替換

物件在Eden區分配

大多數情況下，物件在新生代中 Eden 區分配，當 Eden 區沒有足夠空間進行分配時，虛擬機將發起一次Minor GC，我

們來進行實際測驗一下，

在測驗之前我們先來看看 Minor GC和Full GC 有什么不同呢？

Minor GC/Young GC：指發生新生代的的垃圾收集動作，Minor GC非常頻繁，回收速度一般也比較快，

Major GC/Full GC：一般會回收老年代，年輕代，方法區的垃圾，Major GC的速度一般會比Minor GC的慢

10倍以上，

Eden與Survivor區默認8:1:1

大量的物件被分配在eden區，eden區滿了后會觸發minor gc，可能會有99%以上的物件成為垃圾被回收掉，剩余存活

的物件會被挪到為空的那塊survivor區，下一次eden區滿了后又會觸發minor gc，把eden區和survivor區垃圾物件回

收，把剩余存活的物件一次性挪動到另外一塊為空的survivor區，因為新生代的物件都是朝生夕死的，存活時間很短，所

以JVM默認的8:1:1的比例是很合適的，讓eden區盡量的大，survivor區夠用即可，

JVM默認有這個引數-XX:+UseAdaptiveSizePolicy(默認開啟)，會導致這個8:1:1比例自動變化，如果不想這個比例有變

化可以設定引數-XX:-UseAdaptiveSizePolicy

示例：

我們可以看出eden區記憶體幾乎已經被分配完全（即使程式什么也不做，新生代也會使用至少幾M記憶體），假如我們再為

allocation2分配記憶體會出現什么情況呢？

1 //添加運行JVM引數： ‐XX:+PrintGCDetails

2 public class GCTest {

3 public static void main(String[] args) throws InterruptedException {

4 byte[] allocation1, allocation2/*, allocation3, allocation4, allocation5, allocation6*/;

5 allocation1 = new byte[60000*1024];

6

7 allocation2 = new byte[8000*1024];

8

9 /*allocation3 = new byte[1000*1024];

10 allocation4 = new byte[1000*1024];

11 allocation5 = new byte[1000*1024];

12 allocation6 = new byte[1000*1024];*/

13 }

14 }

15

16 運行結果：

17 [GC (Allocation Failure) [PSYoungGen: 65253K‐>936K(76288K)] 65253K‐>60944K(251392K), 0.0279083 secs] [Times:

user=0.13 sys=0.02, real=0.03 secs]

18 Heap

19 PSYoungGen total 76288K, used 9591K [0x000000076b400000, 0x0000000774900000, 0x00000007c0000000)

20 eden space 65536K, 13% used [0x000000076b400000,0x000000076bc73ef8,0x000000076f400000)

21 from space 10752K, 8% used [0x000000076f400000,0x000000076f4ea020,0x000000076fe80000)

22 to space 10752K, 0% used [0x0000000773e80000,0x0000000773e80000,0x0000000774900000)

23 ParOldGen total 175104K, used 60008K [0x00000006c1c00000, 0x00000006cc700000, 0x000000076b400000)

24 object space 175104K, 34% used [0x00000006c1c00000,0x00000006c569a010,0x00000006cc700000)

25 Metaspace used 3342K, capacity 4496K, committed 4864K, reserved 1056768K

26 class space used 361K, capacity 388K, committed 512K, reserved 1048576K

簡單解釋一下為什么會出現這種情況： 因為給allocation2分配記憶體的時候eden區記憶體幾乎已經被分配完了，我們剛剛講

了當Eden區沒有足夠空間進行分配時，虛擬機將發起一次Minor GC，GC期間虛擬機又發現allocation1無法存入

Survior空間，所以只好把新生代的物件提前轉移到老年代中去，老年代上的空間足夠存放allocation1，所以不會出現

Full GC，執行Minor GC后，后面分配的物件如果能夠存在eden區的話，還是會在eden區分配記憶體，可以執行如下代碼

驗證：

1  public class GCTest {
2 public static void main(String[] args) throws InterruptedException {
3 byte[] allocation1, allocation2, allocation3, allocation4, allocation5, allocation6;
4 allocation1 = new byte[60000*1024];
5
6 allocation2 = new byte[8000*1024];
7
8 allocation3 = new byte[1000*1024];
9 allocation4 = new byte[1000*1024];
10 allocation5 = new byte[1000*1024];
11 allocation6 = new byte[1000*1024];
12 }
13 }
14
15 運行結果：
16 [GC (Allocation Failure) [PSYoungGen: 65253K‐>952K(76288K)] 65253K‐>60960K(251392K), 0.0311467 secs] [Times:
user=0.08 sys=0.02, real=0.03 secs]
17 Heap
18 PSYoungGen total 76288K, used 13878K [0x000000076b400000, 0x0000000774900000, 0x00000007c0000000)
19 eden space 65536K, 19% used [0x000000076b400000,0x000000076c09fb68,0x000000076f400000)
20 from space 10752K, 8% used [0x000000076f400000,0x000000076f4ee030,0x000000076fe80000)
21 to space 10752K, 0% used [0x0000000773e80000,0x0000000773e80000,0x0000000774900000)
22 ParOldGen total 175104K, used 60008K [0x00000006c1c00000, 0x00000006cc700000, 0x000000076b400000)
23 object space 175104K, 34% used [0x00000006c1c00000,0x00000006c569a010,0x00000006cc700000)
24 Metaspace used 3343K, capacity 4496K, committed 4864K, reserved 1056768K
25 class space used 361K, capacity 388K, committed 512K, reserved 1048576K

大物件直接進入老年代

大物件就是需要大量連續記憶體空間的物件（比如：字串、陣列），JVM引數 -XX:PretenureSizeThreshold 可以設定大

物件的大小，如果物件超過設定大小會直接進入老年代，不會進入年輕代，這個引數只在 Serial 和ParNew兩個收集器下

有效，

最后在贈送一張圖：

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/243113.html

標籤：Java

上一篇：不會資料結構？24張圖讓你徹底弄懂它，還不會你來打我！

下一篇：面試常問之重寫（Override）與多載（Overload）