Java高級之虛擬機加載機制的示例分析

這篇文章給大家分享的是有關Java高級之虛擬機加載機制的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

Jvm要加載的是二進制流，可以是.class文件形式，也可以是其他形式，按照它加載的標準來設計就不會有太大問題。

以下主要就機制和標準兩個問題分析一番：

首先來Java類文件的加載機制 ，跟變量的加載機制類似，它先把Class文件加載入內存，再對數據進行驗證、解析和初始化，最終形成虛擬機可以直接使用的Java類型。由于Java是采用JIT機制，所以加載時會比較慢，但優點也明顯，具有高度靈活性，支持動態加載和動態連接。

接下來就講講類的加載過程：

一個類加載的基本過程是按照下面的順序 來，但也有不嚴格按照這個順序來的，也有打亂順序來的，如動態加載就得先初始化再解析。

1、加載

由虛擬機自行決定，但也有由于下面的階段要執行而執行上面階段的情況。

這時虛擬機會做三件事：

第一、通過全限定名讀取文件的二進制流；

第二、把文件里的靜態方法和變量放到方法區中；

第三、生成一個對象放入堆中，作為訪問入口。

注意第一條，僅是讀取二進制流，沒說具體從什么文件中讀，也沒說從哪里讀，所以造就Java很強的擴展性，可以從Jar、Zip中，也可以從網絡層、數據庫層等 。

主要是對象和方法區的聲明。

2、驗證

確保二進制流符合虛擬機的要求， 不符合會報VerifyError。

第一、文件格式驗證，是否有魔數，是否符合Java文件的要求；

第二、元數據驗證，是否符合Java代碼規范，如abstract類是否直接被實例化，普通類有無間接或直接父類Object等；第三、字節碼驗證，對數據流和控制流進行分析，保證不會做出危害虛擬機的行為，如 是否調用不存在的指令，是否把父類賦值給子類，是否把對象賦值給一個非此類型的對象等；

第四、符號引用驗證，主要是類、變量、方法描述是否能找的到，如全限定名是否能找到該文件，是否具有可訪問性等。

主要對內部結構的判定

3、準備

為類變量賦初值，通常為0值如靜態變量，而不會為實例變量賦值。

4、解析

將常量池中的符號引用轉化為直接引用的過程。這里說的符號引用指變量類型，直接引用指可以直接定位到對象的句柄。類、方法、字段、接口解析，根據全限定名獲得相關對象，拿到它的類型，若無對所在類訪問權會拋出IllegalAccessError，無字段NoSuchFieldError,無方法NoSuchMethodError，是類不是接口會拋出IncompatibleClassChangeError

5、初始化

根據程序要求加載類和必要的資源。有且僅有四種情況，需要主動初始化后才能執行接下來的操作 ，所以要先執行上面的四步。

第一、有new或static關鍵字的類，new生成對象，static靜態加載，這兩個很明顯要執行初始化了；

第二、使用類有父類，這沒辦法了；

第三、反射類里的方法，那肯定要初始化了對不對；

第四、執行的主類，用main方法的類。其他被動初始化的情況不需要考慮。

小例子：

public class SuperClass {
static {
System.out.println(“SuperClass!!”);
}
public static int value = 1;
}
public class SubClass extends SuperClass {
static {
System.out.println(“SubClass!!”);
}
}
public class TestClassLoad {
public static void main(String[] args) {
System.out.println(SubClass.value);
SuperClass superClass = new SubClass();
}
}
SuperClass!!
1
SubClass!!

執行結果說明一個問題： 子類調用父類變量的時候 ，子類沒有初始化，因為 此時的代碼關系跟子類無關 ；子類初始化的時候，父類也沒有再初始化，因為 父類在當前方法體中已經初始化 過了。接口與父類的唯一區別在于， 接口初始化不會要求父接口，只有用到父接口才會初始化 ，同樣的都會生成類構造器。

這個時候加載類構造器，會初始化類中所有變量，當然父類先于子類初始化

6、使用

加載完之后，該怎么樣調用怎么樣調用，繪圖啊，計算啊等等

7、卸載

類不再被調用

兩個類是否相等，主要在于第一使用同一個加載器加載，第二全限定名地址一致

為什么要提出上面的問題呢？接下來要講講虛擬機的一個加載機制。

在java虛擬機的角度來看，有兩種類加載器，一種叫系統加載器（Bootstrap ClassLoader），一種叫自定義加載器（extends ClassLoader），這種呢又分為兩個，一種叫應用加載器，一種叫擴展類加載器，一般默認為前者；而我們的應用程序加載主要由上面三個加載器相互配合完成的。三者的關系如Application–>Extension–>Bootsrap，雙親委派機制是指兩兩以組合的方式，子加載器先去調用父加載器的方法，沒找到目標對象再去用子加載器

偽代碼如下：

loadClass(String name,boolean resolve){
Class c=findLoadedClass()
if(c==null){
if(parent !=null)
c=parent.loadClass(name,false);
c=findBootstrapClassOrNull(name);
}catch(ClassNotFoundException e){ }
if(c==null)
c=findClass(name);
}

Java提倡我們去把自己調用類的邏輯寫在findClass里，這樣有助于雙親委派機制的正常使用。

破壞1、重寫loadClass

破壞2、使用線程上下文加載器去讓父加載器去調用子加載器的方法

破壞3、熱加載 現在常用的做法是 自定義類加載器并 將原bug模塊覆蓋-OSGI

但由于自定義加載器之間的規則如果混亂，出現同時互相引用的問題，那么會最終找不到類，而出現線程死鎖和內存泄露的問題。

關于熱修復，也被稱為插件，目前比較流行的有HotFix、Nuwa、DroidFix、AndFix等，這些框架均可以在github或其他地方找到，原理如上，方法多樣，有覆蓋的、有重定向的等等，通過配置、設置action等方式；而作為插件需要滿足以下條件：

1、可以獨立安裝，但不可獨立運行

2、具有向下兼容性，即可拓展性

3、只能運行在宿主程序中，而且可以被禁用、替換

感謝各位的閱讀！關于“Java高級之虛擬機加載機制的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！