Java的類加載機制

時間 2019-11-09

標籤 java 加載機制欄目 Java 简体版

原文原文鏈接

jvm系列前端

序

本文主要講述Java類的加載機制，主要包括類加載器、加載過程、初始化時機。

1、類加載器

一、ClassLoader抽象類

類加載器的任務就是根據一個類的全限定名來讀取此類的二進制字節流到JVM內部，而後轉換爲一個與目標類對應的java.lang.Class對象實例。

若是須要支持類的動態加載或須要對編譯後的字節碼文件進行解密操做等，就須要與類加載器打交道了。

BootstrapClassLoader，由C++編寫嵌套在JVM內部，負責加載「JAVA_HOME/lib」目錄中的全部類型，或者由「-Xbootclasspath」指定路徑中的全部類型。
ExtClassLoader和AppClassLoader都繼承至ClassLoader抽象類，由Java編寫。
ExtClassLoader負責加載「JAVA_HOME/lib/ext」目錄下的全部類型。
AppClassLoader負責加載ClassPath目錄中的全部類型。

defineClass方法將字節碼的byte數組轉換爲一個類的Class對象實例，若是但願在類被加載到JVM內部時就被連接，那麼能夠調用resolveClass方法。

二、雙親委派模型

Parents Delegation Model，雙親委派模型，約定類加載器的加載機制。

當一個類加載器接收到一個類加載的任務時，不會當即展開加載，而是將加載任務委派給它的超類加載器去執行，每一層的類都採用相同的方式，直至委派給最頂層的啓動類加載器爲止。若是超類加載器沒法加載委派給它的類，便將類的加載任務退回給下一級類加載器去執行加載。

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

使用這種方式的好處是：可以有效確保一個類的全局惟一性，當程序中出現多個全限定名相同的類時，類加載器在執行加載時，始終只會加載其中的某一個類。

使用雙親委派模型來組織類加載器之間的關係，有一個顯而易見的好處就是Java類隨着它的類加載器一塊兒具有了一種帶有優先級的層次關係。例如類java.lang.Object，它存放在rt.jar之中，不管哪個類加載器要加載這個類，最終都是委派給處於模型最頂端的啓動類加載器進行加載，所以Object類在程序的各類類加載器環境中都是同一個類。相反，若是沒有使用雙親委派模型，由各個類加載器自行去加載的話，若是用戶本身編寫了一個稱爲java.lang.Object的類，並放在程序的Class-Path中，那系統中將會出現多個不一樣的Object類，Java類型體系中最基礎的行爲也就沒法保證，應用程序也將會變得一片混亂。若是本身去編寫一個與rt.jar類庫中已有類重名的Java類，將會發現能夠正常編譯，但永遠沒法被加載運行。

雙親委派模型對於保證Java程序的穩定運做很重要，但它的實現卻很是簡單，實現雙親委派的代碼都集中在java.lang.ClassLoader的loadClass()方法之中，邏輯清晰易懂：先檢查是否已經被加載過，若沒有加載則調用父加載器的loadClass()方法，若父加載器爲空則默認使用啓動類加載器做爲父加載器。若是父類加載失敗，拋出ClassNotFoundException異常後，再調用本身的findClass()方法進行加載。

雙親委派機制只是Java虛擬機規範建議採用的加載機制，實際在tomcat中，類加載器所採用的加載機制與傳統的雙親委派模型有必定的區別，當缺省的類加載器接收到一個類的加載任務時，首先會去由它自行加載，當它加載失敗時，纔會將類的加載任務委派給它的超類加載器去執行。

三、自定義類加載器

程序中若是沒有顯式指定類加載器的話，默認是AppClassLoader來加載，它負責加載ClassPath目錄中的全部類型，若是被加載的類型並無在ClassPath目錄中時，拋出java.lang.ClassNotFoundException異常。

通常是繼承ClassLoader，若是要符合雙親委派規範，則重寫findClass方法；要破壞的話，重寫loadClass方法。

雙親委派模型的第一次「被破壞」其實發生在雙親委派模型出現以前——即JDK 1.2發佈以前。因爲雙親委派模型在JDK 1.2以後才被引入，而類加載器和抽象類java.lang.ClassLoader則在JDK1.0時代就已經存在，面對已經存在的用戶自定義類加載器的實現代碼，Java設計者引入雙親委派模型時不得不作出一些妥協。

爲了向前兼容，JDK 1.2以後的java.lang.ClassLoader添加了一個新的protected方法findClass()，在此以前，用戶去繼承java.lang.ClassLoader的惟一目的就是爲了重寫loadClass()方法，由於虛擬機在進行類加載的時候會調用加載器的私有方法loadClassInternal()，而這個方法的惟一邏輯就是去調用本身的load-Class()。

上一節咱們已經看過loadClass()方法的代碼，雙親委派的具體邏輯就實如今這個方法之中，JDK1.2以後已不提倡用戶再去覆蓋loadClass()方法，而應當把本身的類加載邏輯寫到findClass()方法中，在loadClass()方法的邏輯裏若是父類加載失敗，則會調用本身的findClass()方法來完成加載，這樣就能夠保證新寫出來的類加載器是符合雙親委派規則的。

2、類加載過程

一個完整的類加載過程必須經歷加載、鏈接、初始化這三個步驟：

一、加載

簡單的說，類加載階段就是由類加載器負責根據一個類的全限定名來讀取此類的二進制字節流到JVM內部，並存儲在運行時內存區的方法區，而後將其轉換爲一個與目標類型對應的java.lang.Class對象實例（Java虛擬機規範並無明確要求必定要存儲在堆區中，只是hotspot選擇將Class對象存儲在方法區中），這個Class對象在往後就會做爲方法區中該類的各類數據的訪問入口。

二、鏈接

鏈接階段要作的是將加載到JVM中的二進制字節流的類數據信息合併到JVM的運行時狀態中，經由驗證、準備、解析三個階段。

（1）驗證階段
驗證類數據信息是否符合JVM規範，是不是一個有效的字節碼文件，驗證內容涵蓋了類數據信息的格式驗證、語義分析、操做驗證等

格式驗證：驗證是否符合class文件規範，好比以0xCAFEBABE開頭，大小版本號等

語義驗證：
a、檢查一個被標記爲final的類型是否包含派生類
b、檢查一個類中的final方法是否被派生類進行重寫
c、確保超類與派生類之間沒有不兼容的一些方法聲明（好比方法簽名相同，但方法的返回值不一樣）

操做驗證：
在操做數棧中的數據必須進行正確的操做，對常量池中的各類符號引用執行驗證（一般在解析階段執行，檢查是否能經過符號引用中描述的全限定名定位到指定類型上，以及類成員信息的訪問修飾符是否容許訪問等）。

（2）準備階段
爲類中的全部靜態變量分配內存空間，併爲其設置一個初始值（因爲尚未產生對象，實例變量將再也不此操做範圍內）

（3）解析階段
將常量池中全部的符號引用轉爲直接引用（獲得類或者字段、方法在內存中的指針或者偏移量，以便直接調用該方法）。這個階段能夠在初始化以後再執行。

三、初始化

將一個類中全部被static關鍵字標識的代碼統一執行一遍，若是執行的是靜態變量，那麼就會使用用戶指定的值覆蓋以前在準備階段設置的初始值；若是執行的是static代碼塊，那麼在初始化階段，JVM就會執行static代碼塊中定義的全部操做。

全部類變量初始化語句和靜態代碼塊都會在編譯時被前端編譯器放在收集器裏頭，存放到一個特殊的方法中，這個方法就是<clinit>方法，即類/接口初始化方法。該方法的做用就是初始化一個類中的變量，使用用戶指定的值覆蓋以前在準備階段設定的初始值。任何invoke之類的字節碼都沒法調用<clinit>方法，由於該方法只能在類加載的過程當中由JVM調用。

若是超類尚未被初始化，那麼優先對超類初始化，但在<clinit>方法內部不會顯示調用超類的<clinit>方法，由JVM負責保證一個類的<clinit>方法執行以前，它的超類<clinit>方法已經被執行。

JVM必須確保一個類在初始化的過程當中，若是是多線程須要同時初始化它，僅僅只能容許其中一個線程對其執行初始化操做，其他線程必須等待，只有在活動線程執行完對類的初始化操做以後，纔會通知正在等待的其餘線程。

只有那些須要執行java代碼來爲類變量執行賦值操做的類型在編譯以後纔會在字節碼中存在生成的<clinit>方法。若是一個類並無聲明任何的類變量，也沒有靜態代碼塊，那麼這個類在編譯爲字節碼後，字節碼文件中將不會包含<clinit>方法；一樣若是一個類聲明類變量，但沒有明確使用類變量的初始化語句以及靜態代碼塊來執行初始化操做，編譯後的字節碼中也不會有<clinit>方法；只有final的靜態變量也不會有該方法。