一、執行時資料區域

Java虛擬機器管理的記憶體包括幾個執行時資料記憶體：方法區、虛擬機器棧、本地方法棧、堆、程式計數器，其中方法區和堆是由執行緒共享的資料區，其他幾個是執行緒隔離的資料區

1.1 程式計數器

程式計數器是一塊較小的記憶體，他可以看做是當前執行緒所執行的行號指示器。位元組碼直譯器工作的時候就是通過改變這個計數器的值來選取下一條需要執行的位元組碼的指令，分支、迴圈、跳轉、異常處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成。如果執行緒正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是Native方法，這個計數器則為空。此記憶體區域是唯一一個在Java虛擬機器規範中沒有規定任何OutOfMemotyError情況的區域

1.2 Java虛擬機器棧

虛擬機器棧描述的是Java方法執行的記憶體模型：每個方法在執行的同時都會建立一個棧幀用於儲存區域性變量表、運算元棧、動態連結、方法出口等資訊。每個方法從呼叫直至完成的過程，就對應著一個棧幀在虛擬機器棧中入棧到出棧的過程。

棧記憶體就是虛擬機器棧，或者說是虛擬機器棧中區域性變量表的部分

區域性變量表存放了編輯期可知的各種基本資料型別（boolean、byte、char、short、int、float、long、double）、物件引用（refrence）型別和returnAddress型別（指向了一條位元組碼指令的地址）

其中64位長度的long和double型別的資料會佔用兩個區域性變數空間，其餘的資料型別只佔用1個。

Java虛擬機器規範對這個區域規定了兩種異常狀況：如果執行緒請求的棧深度大於虛擬機器所允許的深度，將丟擲StackOverflowError異常。如果虛擬機器擴充套件時無法申請到足夠的記憶體，就會跑出OutOfMemoryError異常

1.3 本地方法棧

本地方法棧和虛擬機器棧發揮的作用是非常類似的，他們的區別是虛擬機器棧為虛擬機器執行Java方法（也就是位元組碼）服務，而本地方法棧則為虛擬機器使用到的Native方法服務

本地方法棧區域也會丟擲StackOverflowError和OutOfMemoryErroy異常

1.4 Java堆

堆是Java虛擬機器所管理的記憶體中最大的一塊。Java堆是被所有執行緒共享的一塊記憶體區域，在虛擬機器啟動的時候建立，此記憶體區域的唯一目的是存放物件例項，幾乎所有的物件例項都在這裡分配記憶體。所有的物件例項和陣列都在堆上分配

Java堆是垃圾收集器管理的主要區域。Java堆細分為新生代和老年代

不管怎樣，劃分的目的都是為了更好的回收記憶體，或者更快地分配記憶體

Java堆可以處於物理上不連續的記憶體空間中，只要邏輯上是連續的即可。如果在堆中沒有完成例項分配，並且堆也無法在擴充套件時將會丟擲OutOfMemoryError異常

1.5 方法區

方法區它用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料

除了Java堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴充套件外，還可以選擇不實現垃圾收集。這個區域的記憶體回收目標主要是針對常量池的回收和對型別的解除安裝

當方法區無法滿足記憶體分配需求時，將丟擲OutOfMemoryErroy異常

1.6 執行時常量池

它是方法區的一部分。Class檔案中除了有關的版本、欄位、方法、介面等描述資訊外、還有一項資訊是常量池，用於存放編輯期生成的各種字面量和符號引用，這部分內容將在類載入後進入方法區的執行時常量池中存放

Java語言並不要求常量一定只有編輯期才能產生，也就是可能將新的常量放入池中，這種特性被開發人員利用得比較多的便是String類的intern()方法

當常量池無法再申請到記憶體時會丟擲OutOfMemoryError異常

二、hotspot虛擬機器物件

2.1 物件的建立

1.檢查

虛擬機器遇到一條new指令時，首先將去檢查這個指令的引數是否能在常量池中定位到一個類的符號引用，並且檢查這個符號引用代表的類是否已經被載入、解析和初始化過。如果沒有，那必須先執行相應的類載入過程

2.分配記憶體

接下來將為新生物件分配記憶體，為物件分配記憶體空間的任務等同於把一塊確定的大小的記憶體從Java堆中劃分出來。

假設Java堆中記憶體是絕對規整的，所有用過的記憶體放在一遍，空閒的記憶體放在另一邊，中間放著一個指標作為分界點的指示器，那所分配記憶體就僅僅是把那個指標指向空閒空間那邊挪動一段與物件大小相等的距離，這個分配方式叫做“指標碰撞”

如果Java堆中的記憶體並不是規整的，已使用的記憶體和空閒的記憶體相互交錯，那就沒辦法簡單地進行指標碰撞了，虛擬機器就必須維護一個列表，記錄上哪些記憶體塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式成為“空閒列表”

選擇那種分配方式由Java堆是否規整決定，而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。

1. Init

執行new指令之後會接著執行Init方法，進行初始化，這樣一個物件才算產生出來

2.2 物件的記憶體佈局

在HotSpot虛擬機器中，物件在記憶體中儲存的佈局可以分為3塊區域：物件頭、例項資料和對齊填充

物件頭包括兩部分：

a) 儲存物件自身的執行時資料，如雜湊碼、GC分帶年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒ID、偏向時間戳

b) 另一部分是指型別指標，即物件指向它的類元資料的指標，虛擬機器通過這個指標來確定這個物件是那個類的例項

2.3 物件的訪問定位

使用控制代碼訪問

Java堆中將會劃分出一塊記憶體來作為控制代碼池，reference中儲存的就是物件的控制代碼地址，而控制代碼中包含了物件例項資料與型別資料各自的具體地址

優勢:reference中儲存的是穩點的控制代碼地址,在物件被移動(垃圾收集時移動物件是非常普遍的行為)時只會改變控制代碼中的例項資料指標，而reference本身不需要修改

使用直接指標訪問

Java堆物件的佈局就必須考慮如何訪問型別資料的相關資訊,而refreence中儲存的直接就是物件的地址

優勢：速度更快，節省了一次指標定位的時間開銷，由於物件的訪問在Java中非常頻繁，因此這類開銷積少成多後也是一項非常可觀的執行成本

三、OutOfMemoryError 異常

3.1 Java堆溢位

Java堆用於儲存物件例項，只要不斷的建立物件，並且保證GCRoots到物件之間有可達路徑來避免垃圾回收機制清除這些物件，那麼在數量到達最大堆的容量限制後就會產生記憶體溢位異常

如果是記憶體洩漏，可進一步通過工具檢視洩漏物件到GC Roots的引用鏈。於是就能找到洩露物件是通過怎樣的路徑與GC Roots相關聯並導致垃圾收集器無法自動回收它們的。掌握了洩漏物件的型別資訊及GC Roots引用鏈的資訊，就可以比較準確地定位出洩漏程式碼的位置

如果不存在洩露，換句話說，就是記憶體中的物件確實都還必須存活著，那就應當檢查虛擬機器的堆引數（-Xmx與-Xms），與機器實體記憶體對比看是否還可以調大，從程式碼上檢查是否存在某些物件生命週期過長、持有狀態時間過長的情況，嘗試減少程式執行期的記憶體消耗

3.2 虛擬機器棧和本地方法棧溢位

對於HotSpot來說，雖然-Xoss引數（設定本地方法棧大小）存在，但實際上是無效的，棧容量只由-Xss引數設定。關於虛擬機器棧和本地方法棧，在Java虛擬機器規範中描述了兩種異常：

如果執行緒請求的棧深度大於虛擬機器所允許的最大深度，將丟擲StackOverflowError

如果虛擬機器在擴充套件棧時無法申請到足夠的記憶體空間，則丟擲OutOfMemoryError異常

在單執行緒下，無論由於棧幀太大還是虛擬機器棧容量太小，當記憶體無法分配的時候，虛擬機器丟擲的都是StackOverflowError異常

如果是多執行緒導致的記憶體溢位，與棧空間是否足夠大並不存在任何聯絡，這個時候每個執行緒的棧分配的記憶體越大，反而越容易產生記憶體溢位異常。解決的時候是在不能減少執行緒數或更換64為的虛擬機器的情況下，就只能通過減少最大堆和減少棧容量來換取更多的執行緒

3.3 方法區和執行時常量池溢位

String.intern()是一個Native方法，它的作用是：如果字串常量池中已經包含一個等於此String物件的字串，則返回代表池中這個字串的String物件；否則，將此String物件包含的字串新增到常量池中，並且返回此String物件的引用

由於常量池分配在永久代中，可以通過-XX:PermSize和-XX:MaxPermSize限制方法區大小，從而間接限制其中常量池的容量。

Intern():

JDK1.6 intern方法會把首次遇到的字串例項複製到永久代，返回的也是永久代中這個字串例項的引用，而由StringBuilder建立的字串例項在Java堆上，所以必然不是一個引用

JDK1.7 intern()方法的實現不會再複製例項，只是在常量池中記錄首次出現的例項引用，因此intern()返回的引用和由StringBuilder建立的那個字串例項是同一個

四、垃圾收集

程式計數器、虛擬機器棧、本地方法棧3個區域隨執行緒而生，隨執行緒而滅，在這幾個區域內就不需要過多考慮回收的問題，因為方法結束或者執行緒結束時，記憶體自然就跟隨著回收了

1.判斷物件存活

4.1.1 引用計數器法

給物件新增一個引用計數器，每當由一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；任何時刻計數器為0的物件就是不可能再被使用的

4.1.2 可達性分析演算法

通過一系列的成為“GC Roots”的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑成為引用鏈，當一個物件到GC ROOTS沒有任何引用鏈相連時，則證明此物件時不可用的

Java語言中GC Roots的物件包括下面幾種：

1.虛擬機器棧（棧幀中的本地變量表）中引用的物件

2.方法區中類靜態屬性引用的物件

3.方法區中常量引用的物件

4.本地方法棧JNI（Native方法）引用的物件

2.引用

強引用就是在程式程式碼之中普遍存在的，類似Object obj = new Object() 這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的物件

軟引用用來描述一些還有用但並非必須的元素。對於它在系統將要發生記憶體溢位異常之前，將會把這些物件列進回收範圍之中進行第二次回收，如果這次回收還沒有足夠的記憶體才會丟擲記憶體溢位異常

弱引用用來描述非必須物件的，但是它的強度比軟引用更弱一些，被引用關聯的物件只能生存到下一次垃圾收集發生之前，當垃圾收集器工作時，無論當前記憶體是否足夠都會回收掉只被弱引用關聯的物件

虛引用的唯一目的就是能在這個物件被收集器回收時收到一個系統通知

3.Finalize方法

任何一個物件的finalize()方法都只會被系統自動呼叫一次，如果物件面臨下一次回收，它的finalize()方法不會被再次執行，因此第二段程式碼的自救行動失敗了

4.3.1 回收方法區

永久代的垃圾收集主要回收兩部分內容：廢棄常量和無用的類

廢棄常量：假如一個字串abc已經進入了常量池中，如果當前系統沒有任何一個String物件abc，也就是沒有任何Stirng物件引用常量池的abc常量，也沒有其他地方引用的這個字面量，這個時候發生記憶體回收這個常量就會被清理出常量池

無用的類：

1.該類所有的例項都已經被回收，就是Java堆中不存在該類的任何例項

2.載入該類的ClassLoader已經被回收

3.該類對用的java.lang.Class物件沒有在任何地方被引用，無法再任何地方通過反射訪問該類的方法

4.垃圾收集演算法

4.4.1 標記—清除演算法

演算法分為標記和清除兩個階段：首先標記出所有需要回收的物件，在標記完成後統一回收所有被標記的物件、

不足:一個是效率問題，標記和清除兩個過程的效率都不高；另一個是空間問題，標記清楚之後會產生大量不連續的記憶體碎片，空間碎片太多可能會導致以後再程式執行過程中需要分配較大的物件時，無法找到足夠的連續記憶體而不得不提前觸發另一次垃圾收集動作

4.4.2 複製演算法

他將可用記憶體按照容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這塊的記憶體用完了，就將還存活著的物件複製到另外一塊上面，然後再把已使用過的記憶體空間一次清理掉。這樣使得每次都是對整個半區進行記憶體回收，記憶體分配時也就不用考慮記憶體碎片等複雜情況，只要移動堆頂指標，按順序分配記憶體即可

不足：將記憶體縮小為了原來的一半

實際中我們並不需要按照1:1比例來劃分記憶體空間，而是將記憶體分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor

當另一個Survivor空間沒有足夠空間存放上一次新生代收集下來的存活物件時，這些物件將直接通過分配擔保機制進入老年代

4.4.3 標記整理演算法

讓所有存活的物件都向一端移動，然後直接清理掉端邊界以外的記憶體

4.4.4 分代收集演算法

只是根據物件存活週期的不同將記憶體劃分為幾塊。一般是把java堆分為新生代和老年代，這樣就可以根據各個年代的特點採用最適當的收集演算法。在新生代中，每次垃圾收集時都發現有大批物件死去，只有少量存活，那就選用複製演算法，只需要付出少量存活物件的複製成本就可以完成收集。而老年代中因為物件存活率高、沒有額外空間對它進行分配擔保，就必須使用標記清理或者標記整理演算法來進行回收

5.垃圾收集器

a)Serial收集器：

這個收集器是一個單執行緒的收集器，但它的單執行緒的意義不僅僅說明它會只使用一個COU或一條收集執行緒去完成垃圾收集工作，更重要的是它在進行垃圾收集時，必須暫停其他所有的工作執行緒，直到它手機結束

b)ParNew 收集器：

Serial收集器的多執行緒版本，除了使用了多執行緒進行收集之外，其餘行為和Serial收集器一樣

並行：指多條垃圾收集執行緒並行工作，但此時使用者執行緒仍然處於等待狀態

併發：指使用者執行緒與垃圾收集執行緒同時執行（不一定是並行的，可能會交替執行），使用者程式在繼續執行，而垃圾收集程式運行於另一個CPU上

c)Parallel Scavenge

收集器是一個新生代收集器，它是使用複製演算法的收集器，又是並行的多執行緒收集器。

吞吐量：就是CPU用於執行使用者程式碼的時間與CPU總消耗時間的比值。即吞吐量=執行使用者程式碼時間/（執行使用者程式碼時間+垃圾收集時間）

d)Serial Old 收集器：

是Serial收集器的老年代版本,是一個單執行緒收集器，使用標記整理演算法

e)Parallel Old 收集器：

Parallel Old是Paraller Seavenge收集器的老年代版本，使用多執行緒和標記整理演算法

f)CMS收集器：

CMS收集器是基於標記清除演算法實現的，整個過程分為4個步驟：

1.初始標記2.併發標記3.重新標記4.併發清除

優點：併發收集、低停頓

缺點：

1.CMS收集器對CPU資源非常敏感，CMS預設啟動的回收執行緒數是（CPU數量+3）/4，

2.CMS收集器無法處理浮動垃圾，可能出現Failure失敗而導致一次Full G場地產生

3.CMS是基於標記清除演算法實現的

g)G1收集器：

它是一款面向伺服器應用的垃圾收集器

1.並行與併發：利用多CPU縮短STOP-The-World停頓的時間

2.分代收集

3.空間整合：不會產生記憶體碎片

4.可預測的停頓

運作方式：初始標記，併發標記，最終標記，篩選回收

6.記憶體分配與回收策略

4.6.1 物件優先在Eden分配：

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

4.6.2 大物件直接進入老年代：

所謂大物件就是指需要大量連續記憶體空間的Java物件，最典型的大物件就是那種很長的字串以及陣列。這樣做的目的是避免Eden區及兩個Servivor之間發生大量的記憶體複製

4.6.3長期存活的物件將進入老年代

如果物件在Eden區出生並且盡力過一次Minor GC後仍然存活，並且能夠被Servivor容納，將被移動到Servivor空間中，並且把物件年齡設定成為1.物件在Servivor區中每熬過一次Minor GC，年齡就增加1歲，當它的年齡增加到一定程度（預設15歲），就將會被晉級到老年代中

4.6.4動態物件年齡判定

為了更好地適應不同程式的記憶體狀況，虛擬機器並不是永遠地要求物件的年齡必須達到了MaxTenuringThreshold才能晉級到老年代，如果在Servivor空間中相同年齡所有物件的大小總和大於Survivor空間的一半，年齡大於或等於該年齡的物件就可以直接進入到老年代，無須登到MaxTenuringThreshold中要求的年齡

4.6.4 空間分配擔保：

在發生Minor GC 之前，虛擬機器會檢查老年代最大可 用的連續空間是否大於新生代所有物件總空間，如果這個條件成立，那麼Minor DC可以確保是安全的。如果不成立，則虛擬機器會檢視HandlePromotionFailure設定值是否允許擔保失敗。如果允許那麼會繼續檢查老年代最大可用的連續空間是否大於晉級到老年代物件的平均大小，如果大於，將嘗試進行一次Minor GC，儘管這次MinorGC 是有風險的：如果小於，或者HandlePromotionFailure設定不允許冒險，那這時也要改為進行一次Full GC

五、虛擬機器類載入機制

虛擬機器吧描述類的資料從Class檔案載入到記憶體，並對資料進行校驗、轉換解析和初始化，最終形成可以被虛擬機器直接使用的Java型別，這就是虛擬機器的類載入機制

在Java語言裡面，型別的載入。連線和初始化過程都是在程式執行期間完成的

5.1 類載入的時機

類被載入到虛擬機器記憶體中開始，到解除安裝為止，整個生命週期包括：載入、驗證、準備、解析、初始化、使用和解除安裝7個階段

載入、驗證、準備、初始化和解除安裝這5個階段的順序是確定的，類的載入過程必須按照這種順序按部就班地開始，而解析階段則不一定：它在某些情況下可以再初始化階段之後再開始，這個是為了支援Java語言執行時繫結（也成為動態繫結或晚期繫結）

虛擬機器規範規定有且只有5種情況必須立即對類進行初始化：

1.遇到new、getstatic、putstatic或invokestatic這4條位元組碼指令時，如果類沒有進行過初始化，則需要觸發其初始化。生成這4條指令的最常見的Java程式碼場景是：使用new關鍵字例項化物件的時候、讀取或設定一個類的靜態欄位（被final修飾、已在編譯期把結果放入常量池的靜態欄位除外）的時候，以及呼叫一個類的靜態方法的時候

2.使用java.lang.reflect包的方法對類進行反射呼叫的時候，如果類沒有進行過初始化，則需要先觸發其初始化

3.當初始化一個類的時候，如果發現其父類還沒有進行過初始化，則需要先觸發其父類的初始化

4.當虛擬機器啟動時候，使用者需要指定一個要執行的主類（包含main()方法的那個類），虛擬機器會先初始化這個主類

5.當使用JDK1.7的動態語言支援時，如果一個java.lang.invoke.MethodHandle例項最後的解析結果REF_getStatic、REF_putStatic、REF_invokeStatic的方法控制代碼，並且這個方法控制代碼所對應的類沒有進行過初始化，則需要先觸發其初始化

被動引用：

1.通過子類引用父類的靜態欄位，不會導致子類初始化

2.通過陣列定義來引用類，不會觸發此類的初始化

3.常量在編譯階段會存入呼叫類的常量池中，本質上並沒有直接引用到定義常量的類，因此不會觸發定義常量的類的初始化

介面的初始化：介面在初始化時，並不要求其父介面全部完成類初始化，只有在正整使用到父介面的時候（如引用介面中定義的常量）才會初始化

5.2 類載入的過程

5.2.1 載入

1)通過一個類的全限定名類獲取定義此類的二進位制位元組流

2)將這位元組流所代表的靜態儲存結構轉化為方法區執行時資料結構

3)在記憶體中生成一個代表這個類的java.lang.Class物件，作為方法區這個類的各種資料的訪問入口

怎麼獲取二進位制位元組流？

1)從ZIP包中讀取，這很常見，最終成為日後JAR、EAR、WAR格式的基礎

2)從網路中獲取，這種場景最典型的應用就是Applet

3)執行時計算生成，這種常見使用得最多的就是動態代理技術

4)由其他檔案生成，典型場景就是JSP應用

5)從資料庫中讀取，這種場景相對少一些（中介軟體伺服器）
陣列類本身不通過類載入器建立，它是由Java虛擬機器直接建立的

陣列類的建立過程遵循以下規則：

1)如果陣列的元件型別(指的是陣列去掉一個維度的型別)是引用型別，那就遞迴採用上面的載入過程去載入這個元件型別，陣列C將在載入該元件型別的類載入器的類名稱空間上被標識

2)如果陣列的元件型別不是引用型別(列如int[]組數)，Java虛擬機器將會把陣列C標識為與引導類載入器關聯

3)陣列類的可見性與它的元件型別的可見性一致，如果元件型別不是引用型別，那陣列類的可見性將預設為public

5.2.2 驗證

驗證階段會完成下面4個階段的檢驗動作：檔案格式驗證，元資料驗證，位元組碼驗證，符號引用驗證

1.檔案格式驗證

第一階段要驗證位元組流是否符合Class檔案格式的規範，並且能被當前版本的虛擬機器處理。這一階段可能包括：

1.是否以魔數oxCAFEBABE開頭

2.主、次版本號是否在當前虛擬機器處理範圍之內

3.常量池的常量中是否有不被支援的常量型別(檢查常量tag標誌)

4.指向常量的各種索引值中是否有指向不存在的常量或不符合型別的常量

5.CONSTANT_Itf8_info 型的常量中是否有不符合UTF8編碼的資料

6.Class檔案中各個部分及檔案本身是否有被刪除的或附加的其他資訊

這個階段的驗證時基於二進位制位元組流進行的，只有通過類這個階段的驗證後，位元組流才會進入記憶體的方法區進行儲存，所以後面的3個驗證階段全部是基於方法區的儲存結構進行的，不會再直接操作位元組流

2.元資料驗證

1.這個類是否有父類(除了java.lang.Object之外,所有的類都應當有父類)

2.這個類的父類是否繼承了不允許被繼承的類（被final修飾的類）

3.如果這個類不是抽象類，是否實現類其父類或介面之中要求實現的所有方法

4.類中的欄位、方法是否與父類產生矛盾(列如覆蓋類父類的final欄位,或者出現不符合規則的方法過載，列如方法引數都一致，但返回值型別卻不同等)

第二階段的主要目的是對類元資料資訊進行語義校驗，保證不存在不符合Java語言規範的元資料資訊

3.位元組碼驗證

第三階段是整個驗證過程中最複雜的一個階段，主要目的似乎通過資料流和控制流分析，確定程式語言是合法的、符合邏輯的。在第二階段對元資料資訊中的資料型別做完校驗後，這個階段將對類的方法體進行校驗分析，保證被校驗類的方法在執行時不會做出危害虛擬機器安全的事件。

1.保證任意時刻運算元棧的資料型別與指令程式碼序列都能配合工作，列如，列如在運算元棧放置類一個int型別的資料，使用時卻按long型別來載入入本地變量表中

2.保證跳轉指令不會跳轉到方法體以外的位元組碼指令上

3.保證方法體中的型別轉換時有效的，列如可以把一個子類物件賦值給父類資料型別，這個是安全的，但是吧父類物件賦值給子類資料型別，甚至把物件賦值給與它毫無繼承關係、完全不相干的一個數據型別，則是危險和不合法的

4.符號引用驗證

發生在虛擬機器將符號引用轉化為直接引用的時候，這個轉化動作將在連線的第三階段——解析階段中發生。

1.符號引用中通過字串描述的全限定名是否能找到相對應的類

2.在指定類中是否存在符合方法的欄位描述符以及簡單名稱所描述的方法和欄位

3.符號引用中的類、欄位、方法的訪問性是否可被當前類訪問

對於虛擬機器的類載入機制來說，驗證階段是非常重要的，但是不一定必要（因為對程式執行期沒有影響）的階段。如果全部程式碼都已經被反覆使用和驗證過，那麼在實施階段就可以考慮使用Xverify：none引數來關閉大部分的類驗證措施，以縮短虛擬機器類載入的時間

5.2.3 準備

準備階段是正式為類變數分配記憶體並設定類變數初始值的階段，這些變數都在方法區中進行分配。這個時候進行記憶體分配的僅包括類變數(被static修飾的變數)，而不包括例項變數，例項變數將會在物件例項化時隨著物件一起分配在Java堆中。其次，這裡說的初始值通常下是資料型別的零值。

假設public static int value = 123；

那變數value在準備階段過後的初始值為0而不是123，因為這時候尚未開始執行任何Java方法，而把value賦值為123的putstatic指令是程式被編譯後，存放於類構造器()方法之中，所以把value賦值為123的動作將在初始化階段才會執行，但是如果使用final修飾，則在這個階段其初始值設定為123

5.2.4解析

解析階段是虛擬機器將常量池內符號引用替換為直接引用的過

5.2.5 初始化

類的初始化階段是類載入過程的最後一步，前面的類載入過程中，除了在載入階段使用者應用程式可以通過自定義類載入器參與之外，其餘動作完全由虛擬機器主導和控制。到了初始化階段，才正真開始執行類中定義的Java程式程式碼(或者說是位元組碼)

5.3 類的載入器

5.3.1 雙親委派模型：

只存在兩種不同的類載入器：啟動類載入器（Bootstrap ClassLoader），使用C++實現，是虛擬機器自身的一部分。另一種是所有其他的類載入器，使用JAVA實現，獨立於JVM，並且全部繼承自抽象類java.lang.ClassLoader.

啟動類載入器（Bootstrap ClassLoader），負責將存放在