1、前言

先來看一下JVM整體的一個運行原理。

我們首先從“.java”代碼文件，編譯成“.class”字節碼文件，然后類加載器把“.class”字節碼文件中的類給加載到JVM中，接著是JVM來執行我們寫好的那些類中的代碼，整體是這么個順序。

我們看看下圖，感受一下這個過程：

那么今天，我們就來仔細看看上圖中的“類加載”這個過程，看看JVM的類加載機制到底是怎么樣的？

搞清楚這個過程了，那么以后在面試時，對面試官常問的JVM類加載機制，就能把一些核心概念說清楚了。

2、JVM在什么情況下會加載一個類？

其實類加載過程非常的瑣碎復雜，但是對于我們平時從工作中實用的角度來說，主要是把握他的核心工作原理就可以。

一個類從加載到使用，一般會經歷下面的這個過程：

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

所以首先要搞明白的第一個問題，就是JVM在執行我們寫好的代碼的過程中，一般在什么情況下會去加載一個類呢？

也就是說，啥時候會從“.class”字節碼文件中加載這個類到JVM內存里來。

其實答案非常簡單，就是在你的代碼中用到這個類的時候

舉個簡單的例子，比如下面你有一個類（Kafka.class），里面有一個“main()”方法作為主入口。

那么一旦你的JVM進程啟動之后，它一定會先把你的這個類（Kafka.cass）加載到內存里，然后從“main()”方法的入口代碼開始執行。

我們還是堅持一步一圖，大家先看看下圖，感受一下：

接著假設上面的代碼中，出現了如下的這么一行代碼：

這時可能大家就想了，你的代碼中明顯需要使用“ReplicaManager”這個類去實例化一個對象，此時必須得把“ReplicaManager.class”字節碼文件中的這個類加載到內存里來啊！是不是？

所以這個時候就會觸發JVM通過類加載器，從“ReplicaManager.class”字節碼文件中加載對應的類到內存里來使用，這樣代碼才能跑起來。

我們來看下面的圖：

上面就是給大家舉的一個例子，相信非常的通俗易懂。

簡單概括一下：首先你的代碼中包含“main()”方法的主類一定會在JVM進程啟動之后被加載到內存，開始執行你的“main()”方法中的代碼

接著遇到你使用了別的類，比如“ReplicaManager”，此時就會從對應的“.class”字節碼文件加載對應的類到內存里來。

3、從實用角度出發，來看看驗證、準備和初始化的過程

其實上面的類加載時機的問題，對于很多有經驗的同學來說不是什么問題。但是對于很多初學者來說，是一個非常重要的需要捋清的概念。

接下來就來簡單帶著大家，從實用的角度出發，過一下另外三個概念：

驗證、準備、初始化

其實對于這三個概念，沒太大的必要去深究里面的細節，這里的細節很多很繁瑣，對于大部分同學而言，只要腦子里有下面的幾個概念就可以了：

（1）驗證階段

簡單來說，這一步就是根據Java虛擬機規范，來校驗你加載進來的“.class”文件中的內容，是否符合指定的規范。

這個相信很好理解，假如說，你的“.class”文件被人篡改了，里面的字節碼壓根兒不符合規范，那么JVM是沒法去執行這個字節碼的！

所以把“.class”加載到內存里之后，必須先驗證一下，校驗他必須完全符合JVM規范，后續才能交給JVM來運行。

下面用一張圖，展示了這個過程：

（2）準備階段

這個階段其實也很好理解，咱們都知道，我們寫好的那些類，其實都有一些類變量，比如下面的這個“ReplicaManager”類：

假設你有這么一個“ReplicaManager”類，他的“ReplicaManager.class”文件內容剛剛被加載到內存之后，會進行驗證，確認這個字節碼文件的內容是規范的。

接著，就會進行準備工作，這個準備工作，其實就是給這個“ReplicaManager”類分配一定的內存空間。

然后給他里面的類變量（也就是static修飾的變量）分配內存空間，來一個默認的初始值。

比如上面的示例里，就會給“flushInterval”這個類變量分配內容空間，給一個“0”這個初始值。

整個過程，如下圖所示：

（3）解析階段

這個階段干的事兒，實際上是把符號引用替換為直接引用的過程，其實這個部分的內容很復雜，涉及到JVM的底層

但是注意，同學們，就我本意而言，希望第一周的文章，絕對是淺顯易懂的，循序漸進，要保證每個同學都能絕對看懂。

所以針對這個階段，現在不打算做過深的解讀，因為從實用角度而言，對很多同學在工作中實踐JVM技術其實也用不到，所以這里大家就暫時知道有這么一個階段就可以了。

同樣，我還是給大家畫圖展示一下：

（4）三個階段的小結

其實這三個階段里，最核心的大家務必關注的，就是“準備階段”

因為這個階段是給加載進來的類分配好了內存空間，類變量也分配好了內存空間，并且給了默認的初始值，這個概念，大家心里一定要有。

4、核心階段：初始化

之前說過，在準備階段時，就會把我們的“ReplicaManager”類給分配好內存空間

另外他的一個類變量“flushInterval”也會給一個默認的初始值“0”，那么接下來，在初始化階段，就會正式執行我們的類初始化的代碼了。

那么什么是類初始化的代碼呢？我們來看看下面這段代碼：

大家可以看到，對于“flushInterval”這個類變量，我們是打算通過Configuration.getInt("replica.flush.interval")這段代碼來獲取一個值，并且賦值給他的

但是在準備階段會執行這個賦值邏輯嗎？

NO！在準備階段，僅僅是給“flushInterval”類變量開辟一個內存空間，然后給個初始值“0”罷了。

那么這段賦值的代碼什么時候執行呢？答案是在“初始化”階段來執行。

在這個階段，就會執行類的初始化代碼，比如上面的 Configuration.getInt("replica.flush.interval") 代碼就會在這里執行，完成一個配置項的讀取，然后賦值給這個類變量“flushInterval”。

另外比如下圖的static靜態代碼塊，也會在這個階段來執行。

類似下面的代碼語義，可以理解為類初始化的時候，調用“loadReplicaFromDish()”方法從磁盤中加載數據副本，并且放在靜態變量“replicas”中：

那么搞明白了類的初始化是什么，就得來看看類的初始化的規則了。

什么時候會初始化一個類？

一般來說有以下一些時機：比如“new ReplicaManager()”來實例化類的對象了，此時就會觸發類的加載到初始化的全過程，把這個類準備好，然后再實例化一個對象出來；

或者是包含“main()”方法的主類，必須是立馬初始化的。

此外，這里還有一個非常重要的規則，就是如果初始化一個類的時候，發現他的父類還沒初始化，那么必須先初始化他的父類

比如下面的代碼：

如果你要“new ReplicaManager()”初始化這個類的實例，那么會加載這個類，然后初始化這個類

但是初始化這個類之前，發現AbstractDataManager作為父類還沒加載和初始化，那么必須先加載這個父類，并且初始化這個父類。

這個規則，大家必須得牢記，再來一張圖，借助圖片來進行理解：

5、類加載器和雙親委派機制

現在相信大家都搞明白了整個類加載從觸發時機到初始化的過程了，接著給大家說一下類加載器的概念。因為實現上述過程，那必須是依靠類加載器來實現的。

那么Java里有哪些類加載器呢？簡單來說有下面幾種：

（1）啟動類加載器

Bootstrap ClassLoader，他主要是負責加載我們在機器上安裝的Java目錄下的核心類的

相信大家都知道，如果你要在一個機器上運行自己寫好的Java系統，無論是windows筆記本，還是linux服務器，是不是都得裝一下JDK？

那么在你的Java安裝目錄下，就有一個“lib”目錄，大家可以自己去找找看，這里就有Java最核心的一些類庫，支撐你的Java系統的運行。

所以一旦你的JVM啟動，那么首先就會依托啟動類加載器，去加載你的Java安裝目錄下的“lib”目錄中的核心類庫。

（2）擴展類加載器

Extension ClassLoader，這個類加載器其實也是類似的，就是你的Java安裝目錄下，有一個“lib\ext”目錄

這里面有一些類，就是需要使用這個類加載器來加載的，支撐你的系統的運行。

那么你的JVM一旦啟動，是不是也得從Java安裝目錄下，加載這個“lib\ext”目錄中的類？

（3）應用程序類加載器

Application ClassLoader，這類加載器就負責去加載“ClassPath”環境變量所指定的路徑中的類

其實你大致就理解為去加載你寫好的Java代碼吧，這個類加載器就負責加載你寫好的那些類到內存里。

（4）自定義類加載器

除了上面那幾種之外，還可以自定義類加載器，去根據你自己的需求加載你的類。

（5）雙親委派機制

JVM的類加載器是有親子層級結構的，就是說啟動類加載器是最上層的，擴展類加載器在第二層，第三層是應用程序類加載器，最后一層是自定義類加載器。

大家看下圖：

然后，基于這個親子層級結構，就有一個雙親委派的機制

什么意思呢？

就是假設你的應用程序類加載器需要加載一個類，他首先會委派給自己的父類加載器去加載，最終傳導到頂層的類加載器去加載

但是如果父類加載器在自己負責加載的范圍內，沒找到這個類，那么就會下推加載權利給自己的子類加載器。

聽完了上面一大堆繞口令，是不是很迷茫？別著急，咱們用一個例子來說明一下。

比如你的JVM現在需要加載“ReplicaManager”類，此時應用程序類加載器會問問自己的爸爸，也就是擴展類加載器，你能加載到這個類嗎？

然后擴展類加載器直接問自己的爸爸，啟動類加載器，你能加載到這個類嗎？

啟動類加載器心想，我在Java安裝目錄下，沒找到這個類啊，自己找去！

然后，就下推加載權利給擴展類加載器這個兒子，結果擴展類加載器找了半天，也沒找到自己負責的目錄中有這個類。

這時他很生氣，說：明明就是你應用程序加載器自己負責的，你自己找去。

然后應用程序類加載器在自己負責的范圍內，比如就是你寫好的那個系統打包成的jar包吧，一下子發現，就在這里！然后就自己把這個類加載到內存里去了。

這就是所謂的雙親委派模型：先找父親去加載，不行的話再由兒子來加載。

這樣的話，可以避免多層級的加載器結構重復加載某些類。

最后，給大家來一張圖，感受一下類加載器的雙親委派模型。