關於 JVM，都有哪些面試最常考的點須要重點掌握？

這裏僅僅記錄了一些筆者認爲須要重點掌握的 JVM 知識點，若是你想更加全面地瞭解 JVM 底層原理，能夠閱讀周志明老師《深刻理解Java虛擬機——JVM高級特性與最佳實踐(第2版)》全書。

1、JVM 內存結構

Java 虛擬機的內存空間分爲 5 個部分：

• 程序計數器
• Java 虛擬機棧
• 本地方法棧
• 堆
• 方法區

JDK 1.8 同 JDK 1.7 比，最大的差異就是：元數據區取代了永久代。元空間的本質和永久代相似，都是對 JVM 規範中方法區的實現。不過元空間與永久代之間最大的區別在於：元數據空間並不在虛擬機中，而是使用本地內存。

1. 程序計數器（PC 寄存器）

程序計數器的定義

程序計數器是一塊較小的內存空間，是當前線程正在執行的那條字節碼指令的地址。若當前線程正在執行的是一個本地方法，那麼此時程序計數器爲Undefined。

程序計數器的做用

• 字節碼解釋器經過改變程序計數器來依次讀取指令，從而實現代碼的流程控制。
• 在多線程狀況下，程序計數器記錄的是當前線程執行的位置，從而當線程切換回來時，就知道上次線程執行到哪了。

程序計數器的特色

• 是一塊較小的內存空間。
• 線程私有，每條線程都有本身的程序計數器。
• 生命週期：隨着線程的建立而建立，隨着線程的結束而銷燬。
• 是惟一一個不會出現OutOfMemoryError的內存區域。

2. Java 虛擬機棧（Java 棧）

Java 虛擬機棧的定義

Java 虛擬機棧是描述 Java 方法運行過程的內存模型。

Java 虛擬機棧會爲每個即將運行的 Java 方法建立一塊叫作「棧幀」的區域，用於存放該方法運行過程當中的一些信息，如：

• 局部變量表
• 操做數棧
• 動態連接
• 方法出口信息
• ......

壓棧出棧過程

當方法運行過程當中須要建立局部變量時，就將局部變量的值存入棧幀中的局部變量表中。

Java 虛擬機棧的棧頂的棧幀是當前正在執行的活動棧，也就是當前正在執行的方法，PC 寄存器也會指向這個地址。只有這個活動的棧幀的本地變量能夠被操做數棧使用，當在這個棧幀中調用另外一個方法，與之對應的棧幀又會被建立，新建立的棧幀壓入棧頂，變爲當前的活動棧幀。

方法結束後，當前棧幀被移出，棧幀的返回值變成新的活動棧幀中操做數棧的一個操做數。若是沒有返回值，那麼新的活動棧幀中操做數棧的操做數沒有變化。

因爲Java 虛擬機棧是與線程對應的，數據不是線程共享的，所以不用關心數據一致性問題，也不會存在同步鎖的問題。

Java 虛擬機棧的特色

• 局部變量表隨着棧幀的建立而建立，它的大小在編譯時肯定，建立時只需分配事先規定的大小便可。在方法運行過程當中，局部變量表的大小不會發生改變。
• Java 虛擬機棧會出現兩種異常：StackOverFlowError 和 OutOfMemoryError。
  • StackOverFlowError 若 Java 虛擬機棧的大小不容許動態擴展，那麼當線程請求棧的深度超過當前 Java 虛擬機棧的最大深度時，拋出 StackOverFlowError 異常。
  • OutOfMemoryError 若容許動態擴展，那麼當線程請求棧時內存用完了，沒法再動態擴展時，拋出 OutOfMemoryError 異常。
• Java 虛擬機棧也是線程私有，隨着線程建立而建立，隨着線程的結束而銷燬。

出現 StackOverFlowError 時，內存空間可能還有不少。

3. 本地方法棧（C 棧）

本地方法棧的定義

本地方法棧是爲 JVM 運行 Native 方法準備的空間，因爲不少 Native 方法都是用 C 語言實現的，因此它一般又叫 C 棧。它與 Java 虛擬機棧實現的功能相似，只不過本地方法棧是描述本地方法運行過程的內存模型。

棧幀變化過程

本地方法被執行時，在本地方法棧也會建立一塊棧幀，用於存放該方法的局部變量表、操做數棧、動態連接、方法出口信息等。

方法執行結束後，相應的棧幀也會出棧，並釋放內存空間。也會拋出 StackOverFlowError 和 OutOfMemoryError 異常。

若是 Java 虛擬機自己不支持 Native 方法，或是自己不依賴於傳統棧，那麼能夠不提供本地方法棧。若是支持本地方法棧，那麼這個棧通常會在線程建立的時候按線程分配。

4. 堆

堆的定義

堆是用來存放對象的內存空間，幾乎全部的對象都存儲在堆中。

堆的特色

• 線程共享，整個 Java 虛擬機只有一個堆，全部的線程都訪問同一個堆。而程序計數器、Java 虛擬機棧、本地方法棧都是一個線程對應一個。
• 在虛擬機啓動時建立。
• 是垃圾回收的主要場所。
• 進一步可分爲：新生代(Eden區 From Survior To Survivor)、老年代。

不一樣的區域存放不一樣生命週期的對象，這樣能夠根據不一樣的區域使用不一樣的垃圾回收算法，更具備針對性。

堆的大小既能夠固定也能夠擴展，但對於主流的虛擬機，堆的大小是可擴展的，所以當線程請求分配內存，但堆已滿，且內存已沒法再擴展時，就拋出 OutOfMemoryError 異常。

Java 堆所使用的內存不須要保證是連續的。而因爲堆是被全部線程共享的，因此對它的訪問須要注意同步問題，方法和對應的屬性都須要保證一致性。

5. 方法區

方法區的定義

Java 虛擬機規範中定義方法區是堆的一個邏輯部分。方法區存放如下信息：

• 已經被虛擬機加載的類信息
• 常量
• 靜態變量
• 即時編譯器編譯後的代碼

方法區的特色

• 線程共享。 方法區是堆的一個邏輯部分，所以和堆同樣，都是線程共享的。整個虛擬機中只有一個方法區。
• 永久代。 方法區中的信息通常須要長期存在，並且它又是堆的邏輯分區，所以用堆的劃分方法，把方法區稱爲「永久代」。
• 內存回收效率低。 方法區中的信息通常須要長期存在，回收一遍以後可能只有少許信息無效。主要回收目標是：對常量池的回收；對類型的卸載。
• Java 虛擬機規範對方法區的要求比較寬鬆。 和堆同樣，容許固定大小，也容許動態擴展，還容許不實現垃圾回收。

運行時常量池

方法區中存放：類信息、常量、靜態變量、即時編譯器編譯後的代碼。常量就存放在運行時常量池中。

當類被 Java 虛擬機加載後， .class 文件中的常量就存放在方法區的運行時常量池中。並且在運行期間，能夠向常量池中添加新的常量。如 String 類的 intern() 方法就能在運行期間向常量池中添加字符串常量。

6. 直接內存（堆外內存）

直接內存是除 Java 虛擬機以外的內存，但也可能被 Java 使用。

操做直接內存

在 NIO 中引入了一種基於通道和緩衝的 IO 方式。它能夠經過調用本地方法直接分配 Java 虛擬機以外的內存，而後經過一個存儲在堆中的DirectByteBuffer對象直接操做該內存，而無須先將外部內存中的數據複製到堆中再進行操做，從而提升了數據操做的效率。

直接內存的大小不受 Java 虛擬機控制，但既然是內存，當內存不足時就會拋出 OutOfMemoryError 異常。

直接內存與堆內存比較

• 直接內存申請空間耗費更高的性能
• 直接內存讀取 IO 的性能要優於普通的堆內存。
• 直接內存做用鏈： 本地 IO -> 直接內存 -> 本地 IO
• 堆內存做用鏈：本地 IO -> 直接內存 -> 非直接內存 -> 直接內存 -> 本地 IO

服務器管理員在配置虛擬機參數時，會根據實際內存設置-Xmx等參數信息，但常常忽略直接內存，使得各個內存區域總和大於物理內存限制，從而致使動態擴展時出現OutOfMemoryError異常。

2、HotSpot 虛擬機對象探祕

1. 對象的內存佈局

在 HotSpot 虛擬機中，對象的內存佈局分爲如下 3 塊區域：

• 對象頭（Header）
• 實例數據（Instance Data）
• 對齊填充（Padding）

對象頭

對象頭記錄了對象在運行過程當中所須要使用的一些數據：

• 哈希碼
• GC 分代年齡
• 鎖狀態標誌
• 線程持有的鎖
• 偏向線程 ID
• 偏向時間戳

對象頭可能包含類型指針，經過該指針能肯定對象屬於哪一個類。若是對象是一個數組，那麼對象頭還會包括數組長度。

實例數據

實例數據部分就是成員變量的值，其中包括父類成員變量和本類成員變量。

對齊填充

用於確保對象的總長度爲 8 字節的整數倍。

HotSpot VM 的自動內存管理系統要求對象的大小必須是 8 字節的整數倍。而對象頭部分正好是 8 字節的倍數（1 倍或 2 倍），所以，當對象實例數據部分沒有對齊時，就須要經過對齊填充來補全。

對齊填充並非必然存在，也沒有特別的含義，它僅僅起着佔位符的做用。

2. 對象的建立過程

類加載檢查

虛擬機在解析.class文件時，若遇到一條 new 指令，首先它會去檢查常量池中是否有這個類的符號引用，而且檢查這個符號引用所表明的類是否已被加載、解析和初始化過。若是沒有，那麼必須先執行相應的類加載過程。

爲新生對象分配內存

對象所需內存的大小在類加載完成後即可徹底肯定，接下來從堆中劃分一塊對應大小的內存空間給新的對象。分配堆中內存有兩種方式：

• 指針碰撞 若是 Java 堆中內存絕對規整（說明採用的是「複製算法」或「標記整理法」），空閒內存和已使用內存中間放着一個指針做爲分界點指示器，那麼分配內存時只須要把指針向空閒內存挪動一段與對象大小同樣的距離，這種分配方式稱爲「指針碰撞」。

• 空閒列表 若是 Java 堆中內存並不規整，已使用的內存和空閒內存交錯（說明採用的是標記-清除法，有碎片），此時無法簡單進行指針碰撞， VM 必須維護一個列表，記錄其中哪些內存塊空閒可用。分配之時從空閒列表中找到一塊足夠大的內存空間劃分給對象實例。這種方式稱爲「空閒列表」。

初始化

分配完內存後，爲對象中的成員變量賦上初始值，設置對象頭信息，調用對象的構造函數方法進行初始化。

至此，整個對象的建立過程就完成了。

3. 對象的訪問方式

全部對象的存儲空間都是在堆中分配的，可是這個對象的引用倒是在堆棧中分配的。也就是說在創建一個對象時兩個地方都分配內存，在堆中分配的內存實際創建這個對象，而在堆棧中分配的內存只是一個指向這個堆對象的指針（引用）而已。 那麼根據引用存放的地址類型的不一樣，對象有不一樣的訪問方式。

句柄訪問方式

堆中須要有一塊叫作「句柄池」的內存空間，句柄中包含了對象實例數據與類型數據各自的具體地址信息。

引用類型的變量存放的是該對象的句柄地址（reference）。訪問對象時，首先須要經過引用類型的變量找到該對象的句柄，而後根據句柄中對象的地址找到對象。

直接指針訪問方式

引用類型的變量直接存放對象的地址，從而不須要句柄池，經過引用可以直接訪問對象。但對象所在的內存空間須要額外的策略存儲對象所屬的類信息的地址。

須要說明的是，HotSpot 採用第二種方式，即直接指針方式來訪問對象，只須要一次尋址操做，因此在性能上比句柄訪問方式快一倍。但像上面所說，它須要額外的策略來存儲對象在方法區中類信息的地址。

3、垃圾收集策略與算法

程序計數器、虛擬機棧、本地方法棧隨線程而生，也隨線程而滅；棧幀隨着方法的開始而入棧，隨着方法的結束而出棧。這幾個區域的內存分配和回收都具備肯定性，在這幾個區域內不須要過多考慮回收的問題，由於方法結束或者線程結束時，內存天然就跟隨着回收了。

而對於 Java 堆和方法區，咱們只有在程序運行期間才能知道會建立哪些對象，這部份內存的分配和回收都是動態的，垃圾收集器所關注的正是這部份內存。

1. 斷定對象是否存活

若一個對象不被任何對象或變量引用，那麼它就是無效對象，須要被回收。

引用計數法

在對象頭維護着一個 counter 計數器，對象被引用一次則計數器 +1；若引用失效則計數器 -1。當計數器爲 0 時，就認爲該對象無效了。

引用計數算法的實現簡單，斷定效率也很高，在大部分狀況下它都是一個不錯的算法。可是主流的 Java 虛擬機裏沒有選用引用計數算法來管理內存，主要是由於它很難解決對象之間循環引用的問題。

舉個栗子👉對象 objA 和 objB 都有字段 instance，令 objA.instance = objB 而且 objB.instance = objA，因爲它們互相引用着對方，致使它們的引用計數都不爲 0，因而引用計數算法沒法通知 GC 收集器回收它們。

可達性分析法

全部和 GC Roots 直接或間接關聯的對象都是有效對象，和 GC Roots 沒有關聯的對象就是無效對象。

GC Roots 是指：

• Java 虛擬機棧（棧幀中的本地變量表）中引用的對象
• 本地方法棧中引用的對象
• 方法區中常量引用的對象
• 方法區中類靜態屬性引用的對象

GC Roots 並不包括堆中對象所引用的對象，這樣就不會有循環引用的問題。

2. 引用的種類

斷定對象是否存活與「引用」有關。在 JDK 1.2 之前，Java 中的引用定義很傳統，一個對象只有被引用或者沒有被引用兩種狀態，咱們但願能描述這一類對象：當內存空間還足夠時，則保留在內存中；若是內存空間在進行垃圾手收集後仍是很是緊張，則能夠拋棄這些對象。不少系統的緩存功能都符合這樣的應用場景。

在 JDK 1.2 以後，Java 對引用的概念進行了擴充，將引用分爲了如下四種。不一樣的引用類型，主要體現的是對象不一樣的可達性狀態reachable和垃圾收集的影響。

強引用（Strong Reference）

相似 "Object obj = new Object()" 這類的引用，就是強引用，只要強引用存在，垃圾收集器永遠不會回收被引用的對象。可是，若是咱們錯誤地保持了強引用，好比：賦值給了 static 變量，那麼對象在很長一段時間內不會被回收，會產生內存泄漏。

軟引用（Soft Reference）

軟引用是一種相對強引用弱化一些的引用，可讓對象豁免一些垃圾收集，只有當 JVM 認爲內存不足時，纔會去試圖回收軟引用指向的對象。JVM 會確保在拋出 OutOfMemoryError 以前，清理軟引用指向的對象。軟引用一般用來實現內存敏感的緩存，若是還有空閒內存，就能夠暫時保留緩存，當內存不足時清理掉，這樣就保證了使用緩存的同時，不會耗盡內存。

弱引用（Weak Reference）

弱引用的強度比軟引用更弱一些。當 JVM 進行垃圾回收時，不管內存是否充足，都會回收只被弱引用關聯的對象。

虛引用（Phantom Reference）

虛引用也稱幽靈引用或者幻影引用，它是最弱的一種引用關係。一個對象是否有虛引用的存在，徹底不會對其生存時間構成影響。它僅僅是提供了一種確保對象被 finalize 之後，作某些事情的機制，好比，一般用來作所謂的 Post-Mortem 清理機制。

3. 回收堆中無效對象

對於可達性分析中不可達的對象，也並非沒有存活的可能。

斷定 finalize() 是否有必要執行

JVM 會判斷此對象是否有必要執行 finalize() 方法，若是對象沒有覆蓋 finalize() 方法，或者 finalize() 方法已經被虛擬機調用過，那麼視爲「沒有必要執行」。那麼對象基本上就真的被回收了。

若是對象被斷定爲有必要執行 finalize() 方法，那麼對象會被放入一個 F-Queue 隊列中，虛擬機會以較低的優先級執行這些 finalize()方法，但不會確保全部的 finalize() 方法都會執行結束。若是 finalize() 方法出現耗時操做，虛擬機就直接中止指向該方法，將對象清除。

對象重生或死亡

若是在執行 finalize() 方法時，將 this 賦給了某一個引用，那麼該對象就重生了。若是沒有，那麼就會被垃圾收集器清除。

任何一個對象的 finalize() 方法只會被系統自動調用一次，若是對象面臨下一次回收，它的 finalize() 方法不會被再次執行，想繼續在 finalize() 中自救就失效了。

4. 回收方法區內存

方法區中存放生命週期較長的類信息、常量、靜態變量，每次垃圾收集只有少許的垃圾被清除。方法區中主要清除兩種垃圾：

• 廢棄常量
• 無用的類

斷定廢棄常量

只要常量池中的常量不被任何變量或對象引用，那麼這些常量就會被清除掉。好比，一個字符串 "bingo" 進入了常量池，可是當前系統沒有任何一個 String 對象引用常量池中的 "bingo" 常量，也沒有其它地方引用這個字面量，必要的話，"bingo"常量會被清理出常量池。

斷定無用的類

斷定一個類是不是「無用的類」，條件較爲苛刻。

• 該類的全部對象都已經被清除
• 加載該類的 ClassLoader 已經被回收
• 該類的 java.lang.Class 對象沒有在任何地方被引用，沒法在任何地方經過反射訪問該類的方法。

一個類被虛擬機加載進方法區，那麼在堆中就會有一個表明該類的對象：java.lang.Class。這個對象在類被加載進方法區時建立，在方法區該類被刪除時清除。

5. 垃圾收集算法

學會了如何斷定無效對象、無用類、廢棄常量以後，剩餘工做就是回收這些垃圾。常見的垃圾收集算法有如下幾個：

標記-清除算法

標記的過程是：遍歷全部的 GC Roots，而後將全部 GC Roots 可達的對象標記爲存活的對象。

清除的過程將遍歷堆中全部的對象，將沒有標記的對象所有清除掉。與此同時，清除那些被標記過的對象的標記，以便下次的垃圾回收。

這種方法有兩個不足：

• 效率問題：標記和清除兩個過程的效率都不高。
• 空間問題：標記清除以後會產生大量不連續的內存碎片，碎片太多可能致使之後須要分配較大對象時，沒法找到足夠的連續內存而不得不提早觸發另外一次垃圾收集動做。

複製算法（新生代）

爲了解決效率問題，「複製」收集算法出現了。它將可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊內存用完，須要進行垃圾收集時，就將存活者的對象複製到另外一塊上面，而後將第一塊內存所有清除。這種算法有優有劣：

• 優勢：不會有內存碎片的問題。
• 缺點：內存縮小爲原來的一半，浪費空間。

爲了解決空間利用率問題，能夠將內存分爲三塊： Eden、From Survivor、To Survivor，比例是 8:1:1，每次使用 Eden 和其中一塊 Survivor。回收時，將 Eden 和 Survivor 中還存活的對象一次性複製到另一塊 Survivor 空間上，最後清理掉 Eden 和剛纔使用的 Survivor 空間。這樣只有 10% 的內存被浪費。

可是咱們沒法保證每次回收都只有很少於 10% 的對象存活，當 Survivor 空間不夠，須要依賴其餘內存（指老年代）進行分配擔保。

分配擔保

爲對象分配內存空間時，若是 Eden+Survivor 中空閒區域沒法裝下該對象，會觸發 MinorGC 進行垃圾收集。但若是 Minor GC 事後依然有超過 10% 的對象存活，這樣存活的對象直接經過分配擔保機制進入老年代，而後再將新對象存入 Eden 區。

標記-整理算法（老年代）

標記：它的第一個階段與標記/清除算法是如出一轍的，均是遍歷 GC Roots，而後將存活的對象標記。

整理：移動全部存活的對象，且按照內存地址次序依次排列，而後將末端內存地址之後的內存所有回收。所以，第二階段才稱爲整理階段。

這是一種老年代的垃圾收集算法。老年代的對象通常壽命比較長，所以每次垃圾回收會有大量對象存活，若是採用複製算法，每次須要複製大量存活的對象，效率很低。

分代收集算法

根據對象存活週期的不一樣，將內存劃分爲幾塊。通常是把 Java 堆分爲新生代和老年代，針對各個年代的特色採用最適當的收集算法。

• 新生代：複製算法
• 老年代：標記-清除算法、標記-整理算法

4、HotSpot 垃圾收集器

HotSpot 虛擬機提供了多種垃圾收集器，每種收集器都有各自的特色，雖然咱們要對各個收集器進行比較，但並不是爲了挑選出一個最好的收集器。咱們選擇的只是對具體應用最合適的收集器。

1. 新生代垃圾收集器

Serial 垃圾收集器（單線程）

只開啓一條 GC 線程進行垃圾回收，而且在垃圾收集過程當中中止一切用戶線程(Stop The World)。

通常客戶端應用所需內存較小，不會建立太多對象，並且堆內存不大，所以垃圾收集器回收時間短，即便在這段時間中止一切用戶線程，也不會感受明顯卡頓。所以 Serial 垃圾收集器適合客戶端使用。

因爲 Serial 收集器只使用一條 GC 線程，避免了線程切換的開銷，從而簡單高效。

ParNew 垃圾收集器（多線程）

ParNew 是 Serial 的多線程版本。由多條 GC 線程並行地進行垃圾清理。但清理過程依然須要 Stop The World。

ParNew 追求「低停頓時間」,與 Serial 惟一區別就是使用了多線程進行垃圾收集，在多 CPU 環境下性能比 Serial 會有必定程度的提高；但線程切換須要額外的開銷，所以在單 CPU 環境中表現不如 Serial。

Parallel Scavenge 垃圾收集器（多線程）

Parallel Scavenge 和 ParNew 同樣，都是多線程、新生代垃圾收集器。可是二者有巨大的不一樣點：

• Parallel Scavenge：追求 CPU 吞吐量，可以在較短期內完成指定任務，所以適合沒有交互的後臺計算。
• ParNew：追求下降用戶停頓時間，適合交互式應用。

吞吐量 = 運行用戶代碼時間 / (運行用戶代碼時間 + 垃圾收集時間)

追求高吞吐量，能夠經過減小 GC 執行實際工做的時間，然而，僅僅偶爾運行 GC 意味着每當 GC 運行時將有許多工做要作，由於在此期間積累在堆中的對象數量很高。單個 GC 須要花更多的時間來完成，從而致使更高的暫停時間。而考慮到低暫停時間，最好頻繁運行 GC 以便更快速完成，反過來又致使吞吐量降低。

• 經過參數 -XX:GCTimeRadio 設置垃圾回收時間佔總 CPU 時間的百分比。
• 經過參數 -XX:MaxGCPauseMillis 設置垃圾處理過程最久停頓時間。
• 經過命令 -XX:+UseAdaptiveSizePolicy 開啓自適應策略。咱們只要設置好堆的大小和 MaxGCPauseMillis 或 GCTimeRadio，收集器會自動調整新生代的大小、Eden 和 Survivor 的比例、對象進入老年代的年齡，以最大程度上接近咱們設置的 MaxGCPauseMillis 或 GCTimeRadio。

2. 老年代垃圾收集器

Serial Old 垃圾收集器（單線程）

Serial Old 收集器是 Serial 的老年代版本，都是單線程收集器，只啓用一條 GC 線程，都適合客戶端應用。它們惟一的區別就是：Serial Old 工做在老年代，使用「標記-整理」算法；Serial 工做在新生代，使用「複製」算法。

Parallel Old 垃圾收集器（多線程）

Parallel Old 收集器是 Parallel Scavenge 的老年代版本，追求 CPU 吞吐量。

CMS 垃圾收集器

CMS(Concurrent Mark Sweep，併發標記清除)收集器是以獲取最短回收停頓時間爲目標的收集器（追求低停頓），它在垃圾收集時使得用戶線程和 GC 線程併發執行，所以在垃圾收集過程當中用戶也不會感到明顯的卡頓。

• 初始標記：Stop The World，僅使用一條初始標記線程對全部與 GC Roots 直接關聯的對象進行標記。
• 併發標記：使用多條標記線程，與用戶線程併發執行。此過程進行可達性分析，標記出全部廢棄對象。速度很慢。
• 從新標記：Stop The World，使用多條標記線程併發執行，將剛纔併發標記過程當中新出現的廢棄對象標記出來。
• 併發清除：只使用一條 GC 線程，與用戶線程併發執行，清除剛纔標記的對象。這個過程很是耗時。

併發標記與併發清除過程耗時最長，且能夠與用戶線程一塊兒工做，所以，整體上說，CMS 收集器的內存回收過程是與用戶線程一塊兒併發執行的。

CMS 的缺點：

• 吞吐量低
• 沒法處理浮動垃圾，致使頻繁 Full GC
• 使用「標記-清除」算法產生碎片空間

對於產生碎片空間的問題，能夠經過開啓 -XX:+UseCMSCompactAtFullCollection，在每次 Full GC 完成後都會進行一次內存壓縮整理，將零散在各處的對象整理到一塊。設置參數 -XX:CMSFullGCsBeforeCompaction告訴 CMS，通過了 N 次 Full GC 以後再進行一次內存整理。

3. G1 通用垃圾收集器

G1 是一款面向服務端應用的垃圾收集器，它沒有新生代和老年代的概念，而是將堆劃分爲一塊塊獨立的 Region。當要進行垃圾收集時，首先估計每一個 Region 中垃圾的數量，每次都從垃圾回收價值最大的 Region 開始回收，所以能夠得到最大的回收效率。

從總體上看， G1 是基於「標記-整理」算法實現的收集器，從局部（兩個 Region 之間）上看是基於「複製」算法實現的，這意味着運行期間不會產生內存空間碎片。

這裏拋個問題👇：

一個對象和它內部所引用的對象可能不在同一個 Region 中，那麼當垃圾回收時，是否須要掃描整個堆內存才能完整地進行一次可達性分析？

並不！每一個 Region 都有一個 Remembered Set，用於記錄本區域中全部對象引用的對象所在的區域，進行可達性分析時，只要在 GC Roots 中再加上 Remembered Set 便可防止對整個堆內存進行遍歷。

若是不計算維護 Remembered Set 的操做，G1 收集器的工做過程分爲如下幾個步驟：

• 初始標記：Stop The World，僅使用一條初始標記線程對全部與 GC Roots 直接關聯的對象進行標記。
• 併發標記：使用一條標記線程與用戶線程併發執行。此過程進行可達性分析，速度很慢。
• 最終標記：Stop The World，使用多條標記線程併發執行。
• 篩選回收：回收廢棄對象，此時也要 Stop The World，並使用多條篩選回收線程併發執行。

5、內存分配與回收策略

對象的內存分配，就是在堆上分配（也可能通過 JIT 編譯後被拆散爲標量類型並間接在棧上分配），對象主要分配在新生代的 Eden 區上，少數狀況下可能直接分配在老年代，分配規則不固定，取決於當前使用的垃圾收集器組合以及相關的參數配置。

如下列舉幾條最廣泛的內存分配規則，供你們學習。

1. 對象優先在 Eden 分配

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

👇Minor GC vs Major GC/Full GC：

• Minor GC：回收新生代（包括 Eden 和 Survivor 區域），由於 Java 對象大多都具有朝生夕滅的特性，因此 Minor GC 很是頻繁，通常回收速度也比較快。
• Major GC / Full GC: 回收老年代，出現了 Major GC，常常會伴隨至少一次的 Minor GC，但這並不是絕對。Major GC 的速度通常會比 Minor GC 慢 10 倍 以上。

在 JVM 規範中，Major GC 和 Full GC 都沒有一個正式的定義，因此有人也簡單地認爲 Major GC 清理老年代，而 Full GC 清理整個內存堆。

2. 大對象直接進入老年代

大對象是指須要大量連續內存空間的 Java 對象，如很長的字符串或數據。

一個大對象可以存入 Eden 區的機率比較小，發生分配擔保的機率比較大，而分配擔保須要涉及大量的複製，就會形成效率低下。

虛擬機提供了一個 -XX:PretenureSizeThreshold 參數，令大於這個設置值的對象直接在老年代分配，這樣作的目的是避免在 Eden 區及兩個 Survivor 區之間發生大量的內存複製。（還記得嗎，新生代採用複製算法回收垃圾）

3. 長期存活的對象將進入老年代

JVM 給每一個對象定義了一個對象年齡計數器。當新生代發生一次 Minor GC 後，存活下來的對象年齡 +1，當年齡超過必定值時，就將超過該值的全部對象轉移到老年代中去。

使用 -XXMaxTenuringThreshold 設置新生代的最大年齡，只要超過該參數的新生代對象都會被轉移到老年代中去。

4. 動態對象年齡斷定

若是當前新生代的 Survivor 中，相同年齡全部對象大小的總和大於 Survivor 空間的一半，年齡 >= 該年齡的對象就能夠直接進入老年代，無須等到 MaxTenuringThreshold 中要求的年齡。

5. 空間分配擔保

JDK 6 Update 24 以前的規則是這樣的：
在發生 Minor GC 以前，虛擬機會先檢查老年代最大可用的連續空間是否大於新生代全部對象總空間， 若是這個條件成立，Minor GC 能夠確保是安全的； 若是不成立，則虛擬機會查看 HandlePromotionFailure 值是否設置爲容許擔保失敗， 若是是，那麼會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小， 若是大於，將嘗試進行一次 Minor GC,儘管此次 Minor GC 是有風險的； 若是小於，或者 HandlePromotionFailure 設置不容許冒險，那此時也要改成進行一次 Full GC。

JDK 6 Update 24 以後的規則變爲：
只要老年代的連續空間大於新生代對象總大小或者歷次晉升的平均大小，就會進行 Minor GC，不然將進行 Full GC。

經過清除老年代中廢棄數據來擴大老年代空閒空間，以便給新生代做擔保。

這個過程就是分配擔保。

👇總結一下有哪些狀況可能會觸發 JVM 進行 Full GC：

1. System.gc() 方法的調用 此方法的調用是建議 JVM 進行 Full GC，注意這只是建議而非必定，但在不少狀況下它會觸發 Full GC，從而增長 Full GC 的頻率。一般狀況下咱們只須要讓虛擬機本身去管理內存便可，咱們能夠經過 -XX:+ DisableExplicitGC 來禁止調用 System.gc()。

2. 老年代空間不足 老年代空間不足會觸發 Full GC操做，若進行該操做後空間依然不足，則會拋出錯誤： java.lang.OutOfMemoryError: Java heap space

3. 永久代空間不足 JVM 規範中運行時數據區域中的方法區，在 HotSpot 虛擬機中也稱爲永久代（Permanet Generation），存放一些類信息、常量、靜態變量等數據，當系統要加載的類、反射的類和調用的方法較多時，永久代可能會被佔滿，會觸發 Full GC。若是通過 Full GC 仍然回收不了，那麼 JVM 會拋出錯誤信息：java.lang.OutOfMemoryError: PermGen space

4. CMS GC 時出現 promotion failed 和 concurrent mode failure promotion failed，就是上文所說的擔保失敗，而 concurrent mode failure 是在執行 CMS GC 的過程當中同時有對象要放入老年代，而此時老年代空間不足形成的。

5. 統計獲得的 Minor GC 晉升到舊生代的平均大小大於老年代的剩餘空間

6、JVM 性能調優

在高性能硬件上部署程序，目前主要有兩種方式：

• 經過 64 位 JDK 來使用大內存；
• 使用若干個 32 位虛擬機創建邏輯集羣來利用硬件資源。

1. 使用 64 位 JDK 管理大內存

堆內存變大後，雖然垃圾收集的頻率減小了，但每次垃圾回收的時間變長。 若是堆內存爲14 G，那麼每次 Full GC 將長達數十秒。若是 Full GC 頻繁發生，那麼對於一個網站來講是沒法忍受的。

對於用戶交互性強、對停頓時間敏感的系統，能夠給 Java 虛擬機分配超大堆的前提是有把握把應用程序的 Full GC 頻率控制得足夠低，至少要低到不會影響用戶使用。

可能面臨的問題：

• 內存回收致使的長時間停頓；
• 現階段，64位 JDK 的性能廣泛比 32 位 JDK 低；
• 須要保證程序足夠穩定，由於這種應用要是產生堆溢出幾乎就沒法產生堆轉儲快照（由於要產生超過 10GB 的 Dump 文件），哪怕產生了快照也幾乎沒法進行分析；
• 相同程序在 64 位 JDK 消耗的內存通常比 32 位 JDK 大，這是因爲指針膨脹，以及數據類型對齊補白等因素致使的。

2. 使用 32 位 JVM 創建邏輯集羣

在一臺物理機器上啓動多個應用服務器進程，每一個服務器進程分配不一樣端口， 而後在前端搭建一個負載均衡器，以反向代理的方式來分配訪問請求。

考慮到在一臺物理機器上創建邏輯集羣的目的僅僅是爲了儘量利用硬件資源，並不須要關心狀態保留、熱轉移之類的高可用性能需求， 也不須要保證每一個虛擬機進程有絕對的均衡負載，所以使用無 Session 複製的親合式集羣是一個不錯的選擇。 咱們僅僅須要保障集羣具有親合性，也就是均衡器按必定的規則算法（通常根據 SessionID 分配） 將一個固定的用戶請求永遠分配到固定的一個集羣節點進行處理便可。

可能遇到的問題：

• 儘可能避免節點競爭全局資源，如磁盤競爭，各個節點若是同時訪問某個磁盤文件的話，極可能致使 IO 異常；
• 很難高效利用資源池，如鏈接池，通常都是在節點創建本身獨立的鏈接池，這樣有可能致使一些節點池滿了而另一些節點仍有較多空餘；
• 各個節點受到 32 位的內存限制；
• 大量使用本地緩存的應用，在邏輯集羣中會形成較大的內存浪費，由於每一個邏輯節點都有一份緩存，這時候能夠考慮把本地緩存改爲集中式緩存。

3. 調優案例分析與實戰

場景描述

一個小型系統，使用 32 位 JDK，4G 內存，測試期間發現服務端不定時拋出內存溢出異常。 加入 -XX:+HeapDumpOnOutOfMemoryError（添加這個參數後，堆內存溢出時就會輸出異常日誌）， 但再次發生內存溢出時，沒有生成相關異常日誌。

分析

在 32 位 JDK 上，1.6G 分配給堆，還有一部分分配給 JVM 的其餘內存，直接內存最大也只能在剩餘的 0.4G 空間中分出一部分， 若是使用了 NIO，JVM 會在 JVM 內存以外分配內存空間，那麼就要當心「直接內存」不足時發生內存溢出異常了。

直接內存的回收過程

直接內存雖然不是 JVM 內存空間，但它的垃圾回收也由 JVM 負責。

垃圾收集進行時，虛擬機雖然會對直接內存進行回收， 可是直接內存卻不能像新生代、老年代那樣，發現空間不足了就通知收集器進行垃圾回收， 它只能等老年代滿了後 Full GC，而後「順便」幫它清理掉內存的廢棄對象。 不然只能一直等到拋出內存溢出異常時，先 catch 掉，再在 catch 塊裏大喊 「System.gc()」。 要是虛擬機仍是不聽，那就只能眼睜睜看着堆中還有許多空閒內存，本身卻不得不拋出內存溢出異常了。

7、類文件結構

1. JVM 的「無關性」

談論 JVM 的無關性，主要有如下兩個：

• 平臺無關性：任何操做系統都能運行 Java 代碼
• 語言無關性： JVM 能運行除 Java 之外的其餘代碼

Java 源代碼首先須要使用 Javac 編譯器編譯成 .class 文件，而後由 JVM 執行 .class 文件，從而程序開始運行。

JVM 只認識 .class 文件，它不關心是何種語言生成了 .class 文件，只要 .class 文件符合 JVM 的規範就能運行。 目前已經有 JRuby、Jython、Scala 等語言可以在 JVM 上運行。它們有各自的語法規則，不過它們的編譯器 都能將各自的源碼編譯成符合 JVM 規範的 .class 文件，從而可以藉助 JVM 運行它們。

Java 語言中的各類變量、關鍵字和運算符號的語義最終都是由多條字節碼命令組合而成的， 所以字節碼命令所能提供的語義描述能力確定會比 Java 語言自己更增強大。 所以，有一些 Java 語言自己沒法有效支持的語言特性，不表明字節碼自己沒法有效支持。

2. Class 文件結構

Class 文件是二進制文件，它的內容具備嚴格的規範，文件中沒有任何空格，全都是連續的 0/1。Class 文件 中的全部內容被分爲兩種類型：無符號數、表。

• 無符號數 無符號數表示 Class 文件中的值，這些值沒有任何類型，但有不一樣的長度。u一、u二、u四、u8 分別表明 1/2/4/8 字節的無符號數。
• 表 由多個無符號數或者其餘表做爲數據項構成的符合數據類型。

Class 文件具體由如下幾個構成:

• 魔數
• 版本信息
• 常量池
• 訪問標誌
• 類索引、父類索引、接口索引集合
• 字段表集合
• 方法表集合
• 屬性表集合

魔數

Class 文件的頭 4 個字節稱爲魔數，用來表示這個 Class 文件的類型。

Class 文件的魔數是用 16 進製表示的「CAFE BABE」，是否是很具備浪漫色彩？

魔數至關於文件後綴名，只不事後綴名容易被修改，不安全，所以在 Class 文件中標識文件類型比較合適。

版本信息

緊接着魔數的 4 個字節是版本信息，5-6 字節表示次版本號，7-8 字節表示主版本號，它們表示當前 Class 文件中使用的是哪一個版本的 JDK。

高版本的 JDK 能向下兼容之前版本的 Class 文件，但不能運行之後版本的 Class 文件，即便文件格式並未發生任何變化，虛擬機也必需拒絕執行超過其版本號的 Class 文件。

常量池

版本信息以後就是常量池，常量池中存放兩種類型的常量：

• 字面值常量
  字面值常量就是咱們在程序中定義的字符串、被 final 修飾的值。

• 符號引用 符號引用就是咱們定義的各類名字：類和接口的全限定名、字段的名字和描述符、方法的名字和描述符。

常量池的特色

• 常量池中常量數量不固定，所以常量池開頭放置一個 u2 類型的無符號數，用來存儲當前常量池的容量。
• 常量池的每一項常量都是一個表，表開始的第一位是一個 u1 類型的標誌位（tag），表明當前這個常量屬於哪一種常量類型。

常量池中常量類型

類型	tag	描述
CONSTANT_utf8_info	1	UTF-8編碼的字符串
CONSTANT_Integer_info	3	整型字面量
CONSTANT_Float_info	4	浮點型字面量
CONSTANT_Long_info	5	長整型字面量
CONSTANT_Double_info	6	雙精度浮點型字面量
CONSTANT_Class_info	7	類或接口的符號引用
CONSTANT_String_info	8	字符串類型字面量
CONSTANT_Fieldref_info	9	字段的符號引用
CONSTANT_Methodref_info	10	類中方法的符號引用
CONSTANT_InterfaceMethodref_info	11	接口中方法的符號引用
CONSTANT_NameAndType_info	12	字段或方法的符號引用
CONSTANT_MethodHandle_info	15	表示方法句柄
CONSTANT_MethodType_info	16	標識方法類型
CONSTANT_InvokeDynamic_info	18	表示一個動態方法調用點

對於 CONSTANT_Class_info（此類型的常量表明一個類或者接口的符號引用），它的二維表結構以下：

類型	名稱	數量
u1	tag	1
u2	name_index	1

tag 是標誌位，用於區分常量類型；name_index 是一個索引值，它指向常量池中一個 CONSTANT_Utf8_info 類型常量，此常量表明這個類（或接口）的全限定名，這裏 name_index 值若爲 0x0002，也便是指向了常量池中的第二項常量。

CONSTANT_Utf8_info 型常量的結構以下：

類型	名稱	數量
u1	tag	1
u2	length	1
u1	bytes	length

tag 是當前常量的類型；length 表示這個字符串的長度；bytes 是這個字符串的內容（採用縮略的 UTF8 編碼）

訪問標誌

在常量池結束以後，緊接着的兩個字節表明訪問標誌，這個標誌用於識別一些類或者接口層次的訪問信息，包括：這個 Class 是類仍是接口；是否認義爲 public 類型；是否被 abstract/final 修飾。

類索引、父類索引、接口索引集合

類索引和父類索引都是一個 u2 類型的數據，而接口索引集合是一組 u2 類型的數據的集合，Class 文件中由這三項數據來肯定類的繼承關係。類索引用於肯定這個類的全限定名，父類索引用於肯定這個類的父類的全限定名。

因爲 Java 不容許多重繼承，因此父類索引只有一個，除了 java.lang.Object 以外，全部的 Java 類都有父類，所以除了 java.lang.Object 外，全部 Java 類的父類索引都不爲 0。一個類可能實現了多個接口，所以用接口索引集合來描述。這個集合第一項爲 u2 類型的數據，表示索引表的容量，接下來就是接口的名字索引。

類索引和父類索引用兩個 u2 類型的索引值表示，它們各自指向一個類型爲 CONSTANT_Class_info 的類描述符常量，經過該常量總的索引值能夠找到定義在 CONSTANT_Utf8_info 類型的常量中的全限定名字符串。

字段表集合

字段表集合存儲本類涉及到的成員變量，包括實例變量和類變量，但不包括方法中的局部變量。

每個字段表只表示一個成員變量，本類中的全部成員變量構成了字段表集合。字段表結構以下：

類型	名稱	數量	說明
u2	access_flags	1	字段的訪問標誌，與類稍有不一樣
u2	name_index	1	字段名字的索引
u2	descriptor_index	1	描述符，用於描述字段的數據類型。 基本數據類型用大寫字母表示； 對象類型用「L 對象類型的全限定名」表示。
u2	attributes_count	1	屬性表集合的長度
u2	attributes	attributes_count	屬性表集合，用於存放屬性的額外信息，如屬性的值。

字段表集合中不會出現從父類（或接口）中繼承而來的字段，但有可能出現本來 Java 代碼中不存在的字段，譬如在內部類中爲了保持對外部類的訪問性，會自動添加指向外部類實例的字段。

方法表集合

方法表結構與屬性表相似。

volatile 關鍵字 和 transient 關鍵字不能修飾方法，因此方法表的訪問標誌中沒有 ACC_VOLATILE 和 ACC_TRANSIENT 標誌。

方法表的屬性表集合中有一張 Code 屬性表，用於存儲當前方法經編譯器編譯後的字節碼指令。

屬性表集合

每一個屬性對應一張屬性表，屬性表的結構以下：

類型	名稱	數量
u2	attribute_name_index	1
u4	attribute_length	1
u1	info	attribute_length

8、類加載的時機

1. 類的生命週期

類從被加載到虛擬機內存開始，到卸載出內存爲止，它的整個生命週期包括如下 7 個階段：

• 加載
• 驗證
• 準備
• 解析
• 初始化
• 使用
• 卸載

驗證、準備、解析 3 個階段統稱爲鏈接。

加載、驗證、準備、初始化和卸載這 5 個階段的順序是肯定的，類的加載過程必須按照這種順序循序漸進地開始（注意是「開始」，而不是「進行」或「完成」），而解析階段則不必定：它在某些狀況下能夠在初始化後再開始，這是爲了支持 Java 語言的運行時綁定。

2. 類加載過程當中「初始化」開始的時機

Java 虛擬機規範沒有強制約束類加載過程的第一階段（即：加載）何時開始，但對於「初始化」階段，有着嚴格的規定。有且僅有 5 種狀況必須當即對類進行「初始化」：

• 在遇到 new、putstatic、getstatic、invokestatic 字節碼指令時，若是類還沒有初始化，則須要先觸發其初始化。
• 對類進行反射調用時，若是類尚未初始化，則須要先觸發其初始化。
• 初始化一個類時，若是其父類尚未初始化，則須要先初始化父類。
• 虛擬機啓動時，用於須要指定一個包含 main() 方法的主類，虛擬機會先初始化這個主類。
• 當使用 JDK 1.7 的動態語言支持時，若是一個 java.lang.invoke.MethodHandle 實例最後的解析結果爲 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，而且這個方法句柄所對應的類還沒初始化，則須要先觸發其初始化。

這 5 種場景中的行爲稱爲對一個類進行主動引用，除此以外，其它全部引用類的方式都不會觸發初始化，稱爲被動引用。

3. 被動引用演示 Demo

Demo1

/** * 被動引用 Demo1: * 經過子類引用父類的靜態字段，不會致使子類初始化。 * * @author ylb * */
class SuperClass {
    static {
        System.out.println("SuperClass init!");
    }

    public static int value = 123;
}

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

public class NotInitialization {

    public static void main(String[] args) {
        System.out.println(SubClass.value);
        // SuperClass init!
    }

}
複製代碼

對於靜態字段，只有直接定義這個字段的類纔會被初始化，所以經過其子類來引用父類中定義的靜態字段，只會觸發父類的初始化而不會觸發子類的初始化。

Demo2

/** * 被動引用 Demo2: * 經過數組定義來引用類，不會觸發此類的初始化。 * * @author ylb * */

public class NotInitialization {

    public static void main(String[] args) {
        SuperClass[] superClasses = new SuperClass[10];
    }

}
複製代碼

這段代碼不會觸發父類的初始化，但會觸發「[L 全類名」這個類的初始化，它由虛擬機自動生成，直接繼承自 java.lang.Object，建立動做由字節碼指令 newarray 觸發。

Demo3

/** * 被動引用 Demo3: * 常量在編譯階段會存入調用類的常量池中，本質上並無直接引用到定義常量的類，所以不會觸發定義常量的類的初始化。 * * @author ylb * */
class ConstClass {
    static {
        System.out.println("ConstClass init!");
    }

    public static final String HELLO_BINGO = "Hello Bingo";

}

public class NotInitialization {

    public static void main(String[] args) {
        System.out.println(ConstClass.HELLO_BINGO);
    }

}
複製代碼

編譯經過以後，常量存儲到 NotInitialization 類的常量池中，NotInitialization 的 Class 文件中並無 ConstClass 類的符號引用入口，這兩個類在編譯成 Class 以後就沒有任何聯繫了。

4. 接口的加載過程

接口加載過程與類加載過程稍有不一樣。

當一個類在初始化時，要求其父類所有都已經初始化過了，可是一個接口在初始化時，並不要求其父接口所有都完成了初始化，當真正用到父接口的時候纔會初始化。

9、類加載的過程

類加載過程包括 5 個階段：加載、驗證、準備、解析和初始化。

1. 加載

加載的過程

「加載」是「類加載」過程的一個階段，不能混淆這兩個名詞。在加載階段，虛擬機須要完成 3 件事：

• 經過類的全限定名獲取該類的二進制字節流。
• 將二進制字節流所表明的靜態結構轉化爲方法區的運行時數據結構。
• 在內存中建立一個表明該類的 java.lang.Class 對象，做爲方法區這個類的各類數據的訪問入口。

獲取二進制字節流

對於 Class 文件，虛擬機沒有指明要從哪裏獲取、怎樣獲取。除了直接從編譯好的 .class 文件中讀取，還有如下幾種方式：

• 從 zip 包中讀取，如 jar、war等
• 從網絡中獲取，如 Applect
• 經過動態代理計數生成代理類的二進制字節流
• 由 JSP 文件生成對應的 Class 類
• 從數據庫中讀取，如 有些中間件服務器能夠選擇把程序安裝到數據庫中來完成程序代碼在集羣間的分發。

「非數組類」與「數組類」加載比較

• 非數組類加載階段能夠使用系統提供的引導類加載器，也能夠由用戶自定義的類加載器完成，開發人員能夠經過定義本身的類加載器控制字節流的獲取方式（如重寫一個類加載器的 loadClass() 方法）
• 數組類自己不經過類加載器建立，它是由 Java 虛擬機直接建立的，再由類加載器建立數組中的元素類。

注意事項

• 虛擬機規範未規定 Class 對象的存儲位置，對於 HotSpot 虛擬機而言，Class 對象比較特殊，它雖然是對象，但存放在方法區中。
• 加載階段與鏈接階段的部份內容交叉進行，加載階段還沒有完成，鏈接階段可能已經開始了。但這兩個階段的開始實踐仍然保持着固定的前後順序。

2. 驗證

驗證的重要性

驗證階段確保 Class 文件的字節流中包含的信息符合當前虛擬機的要求，而且不會危害虛擬機自身的安全。

驗證的過程

• 文件格式驗證 驗證字節流是否符合 Class 文件格式的規範，而且能被當前版本的虛擬機處理，驗證點以下：
  • 是否以魔數 0XCAFEBABE 開頭
  • 主次版本號是否在當前虛擬機處理範圍內
  • 常量池是否有不被支持的常量類型
  • 指向常量的索引值是否指向了不存在的常量
  • CONSTANT_Utf8_info 型的常量是否有不符合 UTF8 編碼的數據
  • ......
• 元數據驗證 對字節碼描述信息進行語義分析，確保其符合 Java 語法規範。
• 字節碼驗證 本階段是驗證過程當中最複雜的一個階段，是對方法體進行語義分析，保證方法在運行時不會出現危害虛擬機的事件。
• 符號引用驗證 本階段發生在解析階段，確保解析正常執行。

3. 準備

準備階段是正式爲類變量（或稱「靜態成員變量」）分配內存並設置初始值的階段。這些變量（不包括實例變量）所使用的內存都在方法區中進行分配。

初始值「一般狀況下」是數據類型的零值（0, null...），假設一個類變量的定義爲：

public static int value = 123;
複製代碼

那麼變量 value 在準備階段事後的初始值爲 0 而不是 123，由於這時候還沒有開始執行任何 Java 方法。

存在「特殊狀況」：若是類字段的字段屬性表中存在 ConstantValue 屬性，那麼在準備階段 value 就會被初始化爲 ConstantValue 屬性所指定的值，假設上面類變量 value 的定義變爲：

public static final int value = 123;
複製代碼

那麼在準備階段虛擬機會根據 ConstantValue 的設置將 value 賦值爲 123。

4. 解析

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

5. 初始化

類初始化階段是類加載過程的最後一步，是執行類構造器 <clinit>() 方法的過程。

<clinit>() 方法是由編譯器自動收集類中的全部類變量的賦值動做和靜態語句塊（static {} 塊）中的語句合併產生的，編譯器收集的順序是由語句在源文件中出現的順序所決定的。

靜態語句塊中只能訪問定義在靜態語句塊以前的變量，定義在它以後的變量，在前面的靜態語句塊中能夠賦值，但不能訪問。以下方代碼所示：

public class Test {
    static {
        i = 0;  // 給變量賦值能夠正常編譯經過
        System.out.println(i);  // 這句編譯器會提示「非法向前引用」
    }
    static int i = 1;
}
複製代碼

<clinit>() 方法不須要顯式調用父類構造器，虛擬機會保證在子類的 <clinit>() 方法執行以前，父類的 <clinit>() 方法已經執行完畢。

因爲父類的 <clinit>() 方法先執行，意味着父類中定義的靜態語句塊要優先於子類的變量賦值操做。以下方代碼所示：

static class Parent {
    public static int A = 1;
    static {
        A = 2;
    }
}

static class Sub extends Parent {
    public static int B = A;
}

public static void main(String[] args) {
    System.out.println(Sub.B); // 輸出 2
}
複製代碼

<clinit>() 方法不是必需的，若是一個類沒有靜態語句塊，也沒有對類變量的賦值操做，那麼編譯器能夠不爲這個類生成 <clinit>() 方法。

接口中不能使用靜態代碼塊，但接口也須要經過 <clinit>() 方法爲接口中定義的靜態成員變量顯式初始化。但接口與類不一樣，接口的 <clinit>() 方法不須要先執行父類的 <clinit>() 方法，只有當父接口中定義的變量使用時，父接口才會初始化。

虛擬機會保證一個類的 <clinit>() 方法在多線程環境中被正確加鎖、同步。若是多個線程同時去初始化一個類，那麼只會有一個線程去執行這個類的 <clinit>() 方法。

10、類加載器

1. 類與類加載器

判斷類是否「相等」

任意一個類，都由加載它的類加載器和這個類自己一同確立其在 Java 虛擬機中的惟一性，每個類加載器，都有一個獨立的類名稱空間。

所以，比較兩個類是否「相等」，只有在這兩個類是由同一個類加載器加載的前提下才有意義，不然，即便這兩個類來源於同一個 Class 文件，被同一個虛擬機加載，只要加載它們的類加載器不一樣，那麼這兩個類就一定不相等。

這裏的「相等」，包括表明類的 Class 對象的 equals() 方法、isInstance() 方法的返回結果，也包括使用 instanceof 關鍵字作對象所屬關係斷定等狀況。

加載器種類

系統提供了 3 種類加載器：

• 啓動類加載器（Bootstrap ClassLoader）： 負責將存放在 <JAVA_HOME>\lib 目錄中的，而且能被虛擬機識別的（僅按照文件名識別，如 rt.jar，名字不符合的類庫即便放在 lib 目錄中也不會被加載）類庫加載到虛擬機內存中。
• 擴展類加載器（Extension ClassLoader）： 負責加載 <JAVA_HOME>\lib\ext 目錄中的全部類庫，開發者能夠直接使用擴展類加載器。
• 應用程序類加載器（Application ClassLoader）： 因爲這個類加載器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值，因此通常也稱它爲「系統類加載器」。它負責加載用戶類路徑（classpath）上所指定的類庫，開發者能夠直接使用這個類加載器，若是應用程序中沒有自定義過本身的類加載器，通常狀況下這個就是程序中默認的類加載器。

固然，若是有必要，還能夠加入本身定義的類加載器。

2. 雙親委派模型

什麼是雙親委派模型

雙親委派模型是描述類加載器之間的層次關係。它要求除了頂層的啓動類加載器外，其他的類加載器都應當有本身的父類加載器。（父子關係通常不會以繼承的關係實現，而是以組合關係來複用父加載器的代碼）

工做過程

若是一個類加載器收到了類加載的請求，它首先不會本身去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每個層次的類加載器都是如此，所以全部的加載請求最終都應該傳送到頂層的啓動類加載器中，只有當父加載器反饋本身沒法完成這個加載請求（找不到所需的類）時，子加載器纔會嘗試本身去加載。

在 java.lang.ClassLoader 中的 loadClass() 方法中實現該過程。

爲何使用雙親委派模型

像 java.lang.Object 這些存放在 rt.jar 中的類，不管使用哪一個類加載器加載，最終都會委派給最頂端的啓動類加載器加載，從而使得不一樣加載器加載的 Object 類都是同一個。

相反，若是沒有使用雙親委派模型，由各個類加載器自行去加載的話，若是用戶本身編寫了一個稱爲 java.lang.Object 的類，並放在 classpath 下，那麼系統將會出現多個不一樣的 Object 類，Java 類型體系中最基礎的行爲也就沒法保證。