JVM的藝術(shù)-對象創(chuàng)建與內(nèi)存分配機(jī)制深度剖析

引言

本章將介紹jvm的對象創(chuàng)建與內(nèi)存分配。徹底帶你了解jvm的創(chuàng)建過程以及內(nèi)存分配的原理和區(qū)域，以及包含的內(nèi)容。

對象的創(chuàng)建

類加載的過程

固定的類加載執(zhí)行順序: 加載 驗(yàn)證 準(zhǔn)備 初始化 卸載 的執(zhí)行順序是一定的 為什么解析過程沒有在這個執(zhí)行順序中？(接下來分析)

什么時(shí)候觸發(fā)類加載不一定，但是類的初始化如下四種情況就要求一定初始化。 但是初始化之前 就一定會執(zhí)行 加載 驗(yàn)證 準(zhǔn)備 三個階段。

觸發(fā)類加載的過程(由初始化過程引起的類加載)

1):使用new 關(guān)鍵字 獲取一個靜態(tài)屬性 設(shè)置一個靜態(tài)屬性 調(diào)用一個靜態(tài)方法。

? int myValue = SuperClass.value;會導(dǎo)致父類初始化，但是不會導(dǎo)致子類初始化

? SuperClass.Value = 3 ; 會導(dǎo)致父類初始化，不會導(dǎo)致子類初始化。

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

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

2):使用反射的時(shí)候，若發(fā)現(xiàn)類還沒有初始化，就會進(jìn)行初始化

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

3):在初始化一個類的時(shí)，若發(fā)現(xiàn)其父類沒有初始化，就會先初始化父類

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

4):啟動虛擬機(jī)的時(shí)候，需要加載包含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)根據(jù)全類名獲取到對應(yīng)類的字節(jié)碼流(字節(jié)流的來源 class 文件，網(wǎng)絡(luò)文件，還有反射的Proxygeneraotor.generaotorProxyClass)

1.2)把字節(jié)流中的靜態(tài)數(shù)據(jù)結(jié)構(gòu)加載到方法區(qū)中的運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)

1.3)在內(nèi)存中生成java.lang.Class對象，可以通過該對象來操作方法區(qū)中的數(shù)據(jù)結(jié)構(gòu)(通過反射)

2:驗(yàn)證

文件格式的驗(yàn)證: 驗(yàn)證class文件開頭的0XCAFFBASE 開頭

? 驗(yàn)證主次版本號是否在當(dāng)前的虛擬機(jī)的范圍之類

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

元數(shù)據(jù)的校驗(yàn):

? 驗(yàn)證本類是否有父類

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

? 驗(yàn)證本類不是抽象類的時(shí)候，是否實(shí)現(xiàn)了所有的接口和父類的接口

字節(jié)碼驗(yàn)證:驗(yàn)證跳轉(zhuǎn)指令跳轉(zhuǎn)到 方法以外的指令.

? 驗(yàn)證類型轉(zhuǎn)換是否為有效的， 比如子類對象賦值父類的引用是可以的，但是把父類對象賦值給子類引用是危險(xiǎn)的

? 總而言之:字節(jié)碼驗(yàn)證通過，并不能說明該字節(jié)碼一定沒有問題，但是字節(jié)碼驗(yàn)證不通過。那么該字節(jié)碼文件一定是有問題：。

? 符號引用的驗(yàn)證(發(fā)生在解析的過程中)：

? 通過字符串描述的全類名是否能找到對應(yīng)的類。

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

3:準(zhǔn)備:為類變量分配內(nèi)存以及設(shè)置初始值。

? 比如public static int value = 123;

? 在準(zhǔn)備的過程中 value=0 而不是123 ，當(dāng)執(zhí)行類的初始化的方法的時(shí)候，value=123

? 若是一個靜態(tài)常量

? public static final int value = 9; 那么在準(zhǔn)備的過程中value為9.

?

4:解析 ：把符號引用替換成直接引用

? 符號引用分類:

? CONSTANT_Class_info 類或者接口的符號引用

? CONSTANT_Fieldref_info 字段的符號引用

? CONSTANT_Methodref_info 方法的符號引用

? CONSTANT_intfaceMethodref_info- 接口中方法的符號引用

? CONSTANT_NameAndType_info 子類或者方法的符號引用.

? CONSTANT_MethodHandle_Info 方法句柄

? CONSTANT_InvokeDynamic_Info 動態(tài)調(diào)用

直接引用:

? 指向?qū)ο蟮闹羔?/p>

? 相對偏移量

? 操作句柄

5:初始化：類的初始化時(shí)類加載的最后一步:執(zhí)行類的構(gòu)造器，為所有的類變量進(jìn)行賦值(編譯器生成CLInit<>)

? 類構(gòu)造器是什么？： 類構(gòu)造器是編譯器按照J(rèn)ava源文件總類變量和靜態(tài)代碼塊出現(xiàn)的順序來決定

? 靜態(tài)語句只能訪問定義在靜態(tài)語句之前的類變量，在其后的靜態(tài)變量能賦值 但是不能訪問。

? 父類中的靜態(tài)代碼塊優(yōu)先于子類靜態(tài)代碼塊執(zhí)行。

? 若類中沒有靜態(tài)代碼塊也沒有靜態(tài)類變量的話，那么編譯器就不會生成 Clint<>類構(gòu)造器的方法。

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.****類加載檢查

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

符號引用代表的類是否已被加載、解析和初始化過。如果沒有，那必須先執(zhí)行相應(yīng)的類加載過程。

new指令對應(yīng)到語言層面上講是，new關(guān)鍵詞、對象克隆、對象序列化等。

2.****分配內(nèi)存

在類加載檢查通過后，接下來虛擬機(jī)將為新生對象分配內(nèi)存。對象所需內(nèi)存的大小在類 加載完成后便可完全確定，為

對象分配空間的任務(wù)等同于把 一塊確定大小的內(nèi)存從Java堆中劃分出來。

這個步驟有兩個問題：

1.如何劃分內(nèi)存。

2.在并發(fā)情況下， 可能出現(xiàn)正在給對象A分配內(nèi)存，指針還沒來得及修改，對象B又同時(shí)使用了原來的指針來分配內(nèi)存的

情況。

劃分內(nèi)存的方法：

內(nèi)存的方法：

“指針碰撞”（Bump the Pointer）(默認(rèn)用指針碰撞)

假設(shè)Java堆中內(nèi)存時(shí)完整的，已分配的內(nèi)存和空閑內(nèi)存分別在不同的一側(cè)，通過一個指針作為分界點(diǎn)，需要分配內(nèi)存時(shí)，

僅僅需要把指針往空閑的一端移動與對象大小相等的距離。使用的GC收集器：Serial、ParNew，適用堆內(nèi)存規(guī)整（即沒有內(nèi)存碎片）的情況下。

“空閑列表”（Free List）

事實(shí)上，Java堆的內(nèi)存并不是完整的，已分配的內(nèi)存和空閑內(nèi)存相互交錯，JVM通過維護(hù)一個列表，記錄可用的內(nèi)存塊信息，當(dāng)分配操作發(fā)生時(shí)，從列表中找到一個足夠大的內(nèi)存塊分配給對象實(shí)例，并更新列表上的記錄。使用的GC收集器：CMS，適用堆內(nèi)存不規(guī)整的情況下。

解決并發(fā)問題的方法：

CAS（compare and swap）

虛擬機(jī)采用CAS配上失敗重試的方式保證更新操作的原子性來對分配內(nèi)存空間的動作進(jìn)行同步處理。

本地線程分配緩沖（Thread Local Allocation Buffer,TLAB）

把內(nèi)存分配的動作按照線程劃分在不同的空間之中進(jìn)行，即每個線程在Java堆中預(yù)先分配一小塊內(nèi)存。通過-XX:+/-

UseTLAB參數(shù)來設(shè)定虛擬機(jī)是否使用TLAB(JVM會默認(rèn)開啟-XX:+****UseTLAB)，-XX:TLABSize 指定TLAB大小。

3.****初始化

內(nèi)存分配完成后，虛擬機(jī)需要將分配到的內(nèi)存空間都初始化為零值（不包括對象頭）， 如果使用TLAB，這一工作過程也

可以提前至TLAB分配時(shí)進(jìn)行。這一步操作保證了對象的實(shí)例字段在Java代碼中可以不賦初始值就直接使用，程序能訪問

到這些字段的數(shù)據(jù)類型所對應(yīng)的零值。

什么是 TLAB

TLAB （Thread Local Allocation Buffer，線程本地分配緩沖區(qū)）是 Java 中內(nèi)存分配的一個概念，它是在 Java 堆中劃分出來的針對每個線程的內(nèi)存區(qū)域，專門在該區(qū)域?yàn)樵摼€程創(chuàng)建的對象分配內(nèi)存。它的主要目的是在多線程并發(fā)環(huán)境下需要進(jìn)行內(nèi)存分配的時(shí)候，減少線程之間對于內(nèi)存分配區(qū)域的競爭，加速內(nèi)存分配的速度。TLAB 本質(zhì)上還是在 Java 堆中的，因此在 TLAB 區(qū)域的對象，也可以被其他線程訪問。

如果沒有啟用 TLAB，多個并發(fā)執(zhí)行的線程需要創(chuàng)建對象、申請分配內(nèi)存的時(shí)候，有可能在 Java 堆的同一個位置申請，這時(shí)就需要對擬分配的內(nèi)存區(qū)域進(jìn)行加鎖或者采用 CAS 等操作，保證這個區(qū)域只能分配給一個線程。

啟用了 TLAB 之后(-XX:+UseTLAB, 默認(rèn)是開啟的)，JVM 會針對每一個線程在 Java 堆中預(yù)留一個內(nèi)存區(qū)域，在預(yù)留這個動作發(fā)生的時(shí)候，需要進(jìn)行加鎖或者采用 CAS 等操作進(jìn)行保護(hù)，避免多個線程預(yù)留同一個區(qū)域。一旦某個區(qū)域確定劃分給某個線程，之后該線程需要分配內(nèi)存的時(shí)候，會優(yōu)先在這片區(qū)域中申請。這個區(qū)域針對分配內(nèi)存這個動作而言是該線程私有的，因此在分配的時(shí)候不用進(jìn)行加鎖等保護(hù)性的操作。

4.****設(shè)置對象頭

初始化零值之后，虛擬機(jī)要對對象進(jìn)行必要的設(shè)置，例如這個對象是哪個類的實(shí)例、如何才能找到類的元數(shù)據(jù)信息、對

象的哈希碼、對象的GC分代年齡等信息。這些信息存放在對象的對象頭Object Header之中。

在HotSpot虛擬機(jī)中，對象在內(nèi)存中存儲的布局可以分為3塊區(qū)域：對象頭（Header）、 實(shí)例數(shù)據(jù)（Instance Data）

和對齊填充（Padding）。 HotSpot虛擬機(jī)的對象頭包括兩部分信息，第一部分用于存儲對象自身的運(yùn)行時(shí)數(shù)據(jù)， 如哈

希碼（HashCode）、GC分代年齡、鎖狀態(tài)標(biāo)志、線程持有的鎖、偏向線程ID、偏向時(shí) 間戳等。對象頭的另外一部分

是類型指針，即對象指向它的類元數(shù)據(jù)的指針，虛擬機(jī)通過這個指針來確定這個對象是哪個類的實(shí)例。

對象頭在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.****執(zhí)行****<init>****方法

執(zhí)行<init>方法，即對象按照程序員的意愿進(jìn)行初始化。對應(yīng)到語言層面上講，就是為屬性賦值（注意，這與上面的賦

零值不同，這是由程序員賦的值），和執(zhí)行構(gòu)造方法。

對象大小與指針壓縮

對象大小可以用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 * 計(jì)算對象大小 
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 默認(rèn)開啟的壓縮所有指針 
22  // ‐XX:+UseCompressedClassPointers 默認(rèn)開啟的壓縮對象頭里的類型指針Klass Pointer 
23  // Oops : Ordinary Object Pointers 
24  public static class A { 
25      //8B mark word 
26      //4B Klass Pointer 如果關(guān)閉壓縮‐XX:‐UseCompressedClassPointers或‐XX:‐UseCompressedOops，則占用8B 
27      int id; //4B 
28      String name; //4B 如果關(guān)閉壓縮‐XX:‐UseCompressedOops，則占用8B 
29      byte b; //1B 
30      Object o; //4B 如果關(guān)閉壓縮‐XX:‐UseCompressedOops，則占用8B 
31  } 
32 } 
33
34
35 運(yùn)行結(jié)果： 
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操作系統(tǒng)中，JVM支持指針壓縮

2.jvm配置參數(shù):UseCompressedOops，compressed--壓縮、oop(ordinary object pointer)--對象指針

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

為什么要進(jìn)行指針壓縮？

1.在64位平臺的HotSpot中使用32位指針，內(nèi)存使用會多出1.5倍左右，使用較大指針在主內(nèi)存和緩存之間移動數(shù)據(jù)，

占用較大寬帶，同時(shí)****GC****也會承受較大壓力

2.為了減少64位平臺下內(nèi)存的消耗，啟用指針壓縮功能

3.在jvm中，32位地址最大支持4G內(nèi)存(2的32次方)，可以通過對對象指針的壓縮編碼、解碼方式進(jìn)行優(yōu)化，使得jvm

只用32位地址就可以支持更大的內(nèi)存配置(小于等于32G)

4.堆內(nèi)存小于4G時(shí)，不需要啟用指針壓縮，jvm會直接去除高32位地址，即使用低虛擬地址空間

5.堆內(nèi)存大于32G時(shí)，壓縮指針會失效，會強(qiáng)制使用64位(即8字節(jié))來對java對象尋址，這就會出現(xiàn)1的問題，所以堆內(nèi)

存不要大于32G為好 .

對象內(nèi)存分配

對象內(nèi)存分配流程圖

對象棧上分配

我們通過JVM內(nèi)存分配可以知道JAVA中的對象都是在堆上進(jìn)行分配，當(dāng)對象沒有被引用的時(shí)候，需要依靠GC進(jìn)行回收內(nèi)

存，如果對象數(shù)量較多的時(shí)候，會給GC帶來較大壓力，也間接影響了應(yīng)用的性能。為了減少臨時(shí)對象在堆內(nèi)分配的數(shù)量，JVM通過逃逸分析確定該對象不會被外部訪問。如果不會逃逸可以將該對象在棧上分配內(nèi)存，這樣該對象所占用的

內(nèi)存空間就可以隨棧幀出棧而銷毀，就減輕了垃圾回收的壓力。

對象逃逸分析：就是分析對象動態(tài)作用域，當(dāng)一個對象在方法中被定義后，它可能被外部方法所引用，例如作為調(diào)用參

數(shù)傳遞到其他地方中。

很顯然test1方法中的user對象被返回了，這個對象的作用域范圍不確定，test2方法中的user對象我們可以確定當(dāng)方法結(jié)

束這個對象就可以認(rèn)為是無效對象了，對于這樣的對象我們其實(shí)可以將其分配在棧內(nèi)存里，讓其在方法結(jié)束時(shí)跟隨棧內(nèi)

存一起被回收掉。

JVM對于這種情況可以通過開啟逃逸分析參數(shù)(-XX:+DoEscapeAnalysis)來優(yōu)化對象內(nèi)存分配位置，使其通過標(biāo)量替換優(yōu)

先分配在棧上(棧上分配)，JDK7之后默認(rèn)開啟逃逸分析，如果要關(guān)閉使用參數(shù)(-XX:-DoEscapeAnalysis)

標(biāo)量替換：通過逃逸分析確定該對象不會被外部訪問，并且對象可以被進(jìn)一步分解時(shí)，JVM不會創(chuàng)建該對象，而是將該

對象成員變量分解若干個被這個方法使用的成員變量所代替，這些代替的成員變量在棧幀或寄存器上分配空間，這樣就

不會因?yàn)闆]有一大塊連續(xù)空間導(dǎo)致對象內(nèi)存不夠分配。開啟標(biāo)量替換參數(shù)(-XX:+EliminateAllocations)，JDK7之后默認(rèn)

開啟。

標(biāo)量與聚合量：標(biāo)量即不可被進(jìn)一步分解的量，而JAVA的基本數(shù)據(jù)類型就是標(biāo)量（如：int，long等基本數(shù)據(jù)類型以及

reference類型等），標(biāo)量的對立就是可以被進(jìn)一步分解的量，而這種量稱之為聚合量。而在JAVA中對象就是可以被進(jìn)一

步分解的聚合量。

棧上分配示例：

結(jié)論：****棧上分配依賴于逃逸分析和標(biāo)量替換

對象在Eden區(qū)分配

大多數(shù)情況下，對象在新生代中 Eden 區(qū)分配。當(dāng) Eden 區(qū)沒有足夠空間進(jìn)行分配時(shí)，虛擬機(jī)將發(fā)起一次Minor GC。我

們來進(jìn)行實(shí)際測試一下。

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

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

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

10倍以上。

Eden與Survivor區(qū)默認(rèn)8:1:1

大量的對象被分配在eden區(qū)，eden區(qū)滿了后會觸發(fā)minor gc，可能會有99%以上的對象成為垃圾被回收掉，剩余存活

的對象會被挪到為空的那塊survivor區(qū)，下一次eden區(qū)滿了后又會觸發(fā)minor gc，把eden區(qū)和survivor區(qū)垃圾對象回

收，把剩余存活的對象一次性挪動到另外一塊為空的survivor區(qū)，因?yàn)樾律膶ο蠖际浅λ赖模婊顣r(shí)間很短，所

以JVM默認(rèn)的8:1:1的比例是很合適的，讓eden區(qū)盡量的大，survivor區(qū)夠用即可，

JVM默認(rèn)有這個參數(shù)-XX:+UseAdaptiveSizePolicy(默認(rèn)開啟)，會導(dǎo)致這個8:1:1比例自動變化，如果不想這個比例有變

化可以設(shè)置參數(shù)-XX:-UseAdaptiveSizePolicy

示例：

我們可以看出eden區(qū)內(nèi)存幾乎已經(jīng)被分配完全（即使程序什么也不做，新生代也會使用至少幾M內(nèi)存）。假如我們再為

allocation2分配內(nèi)存會出現(xiàn)什么情況呢？

1 //添加運(yùn)行JVM參數(shù)： ‐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 運(yùn)行結(jié)果：

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

簡單解釋一下為什么會出現(xiàn)這種情況： 因?yàn)榻oallocation2分配內(nèi)存的時(shí)候eden區(qū)內(nèi)存幾乎已經(jīng)被分配完了，我們剛剛講

了當(dāng)Eden區(qū)沒有足夠空間進(jìn)行分配時(shí)，虛擬機(jī)將發(fā)起一次Minor GC，GC期間虛擬機(jī)又發(fā)現(xiàn)allocation1無法存入

Survior空間，所以只好把新生代的對象提前轉(zhuǎn)移到老年代中去，老年代上的空間足夠存放allocation1，所以不會出現(xiàn)

Full GC。執(zhí)行Minor GC后，后面分配的對象如果能夠存在eden區(qū)的話，還是會在eden區(qū)分配內(nèi)存?？梢詧?zhí)行如下代碼

驗(yàn)證：

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 運(yùn)行結(jié)果：
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

大對象直接進(jìn)入老年代

大對象就是需要大量連續(xù)內(nèi)存空間的對象（比如：字符串、數(shù)組）。JVM參數(shù) -XX:PretenureSizeThreshold 可以設(shè)置大

對象的大小，如果對象超過設(shè)置大小會直接進(jìn)入老年代，不會進(jìn)入年輕代，這個參數(shù)只在 Serial 和ParNew兩個收集器下

有效。

最后在贈送一張圖：