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兩個收集器下
有效。
最后在贈送一張圖：
