JVM的藝術-物件建立與記憶體分配機制深度剖析
引言
本章將介紹jvm的物件建立與記憶體分配。徹底帶你瞭解jvm的建立過程以及記憶體分配的原理和區域，以及包含的內容。
物件的建立
類載入的過程
固定的類載入執行順序: 載入 驗證 準備 初始化 解除安裝 的執行順序是一定的 為什麼解析過程沒有在這個執行順序中？(接下來分析)
什麼時候觸發類載入不一定，但是類的初始化如下四種情況就要求一定初始化。 但是初始化之前 就一定會執行 載入 驗證 準備 三個階段。
觸發類載入的過程(由初始化過程引起的類載入)
1):使用new 關鍵字 獲取一個靜態屬性 設定一個靜態屬性 呼叫一個靜態方法。
int myValue = SuperClass.value;會導致父類初始化，但是不會導致子類初始化
SuperClass.Value = 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 = 123;
在準備的過程中 value=0 而不是123 ，當執行類的初始化的方法的時候，value=123
若是一個靜態常量
public static final int value = 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.執行
執行
零值不同，這是由程式設計師賦的值），和執行構造方法。
物件大小與指標壓縮
物件大小可以用jolcore包檢視，引入依賴
<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兩個收集器下
有效。
最後在贈送一張圖：
