JVM的加載機制，一篇就夠了
前言：
前倆天已經整理好了JVM裏面的垃圾清理機制及算法，我的感受對JAVA虛擬機的理解仍是不足，接着進行學習整理，今天將JVM虛擬機的類加載機制進行整理，但願對你們有所幫助，因爲我的能力問題！若有錯誤或不足之處，望各位大佬私信或留言進行批評指正，在下定當儘早改正，以避免影響其餘人！！！！！java
1、什麼是類的加載
類的加載指的是將類的.class文件中的二進制數據讀入到內存中，將其放在運行時數據區的方法區內，而後在堆區建立一個 java.lang.Class對象，用來封裝類在方法區內的數據結構。類的加載的最終產品是位於堆區中的 Class對象， Class對象封裝了類在方法區內的數據結構，而且向Java程序員提供了訪問方法區內的數據結構的接口。
程序員
加載.class文件的方式
- 從本地系統中直接加載
- 經過網絡下載.class文件
- 從zip，jar等歸檔文件中加載.class文件
- 從專有數據庫中提取.class文件
- 將Java源文件動態編譯爲.class文件
2、類的生命週期
其中類加載的過程包括了加載、驗證、準備、解析、初始化五個階段。在這五個階段中，加載、驗證、準備和初始化這四個階段發生的順序是肯定的，而解析階段則不必定，它在某些狀況下能夠在初始化階段以後開始，這是爲了支持Java語言的運行時綁定（也成爲動態綁定或晚期綁定）。另外注意這裏的幾個階段是按順序開始，而不是按順序進行或完成，由於這些階段一般都是互相交叉地混合進行的，一般在一個階段執行的過程當中調用或激活另外一個階段。算法
加載：
查找並加載類的二進制數據加載時類加載過程的第一個階段，在加載階段，虛擬機須要完成如下三件事情：數據庫
- 經過一個類的全限定名來獲取其定義的二進制字節流。
- 將這個字節流所表明的靜態存儲結構轉化爲方法區的運行時數據結構。
- 在Java堆中生成一個表明這個類的 java.lang.Class對象，做爲對方法區
中這些數據的訪問入口。
相對於類加載的其餘階段而言，加載階段（準確地說，是加載階段獲取類的二進制字節流的動做）是可控性最強的階段，由於開發人員既可使用系統提供的類加載器來完成加載，也能夠自定義本身的類加載器來完成加載。數組
加載階段完成後，虛擬機外部的二進制字節流就按照虛擬機所需的格式存儲在方法區之中，並且在Java堆中也建立一個 java.lang.Class類的對象，這樣即可以經過該對象訪問方法區中的這些數據。緩存
鏈接
驗證：確保被加載的類的正確性
驗證是鏈接階段的第一步，這一階段的目的是爲了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，而且不會危害虛擬機自身的安全。驗證階段大體會完成4個階段的檢驗動做：安全
-
文件格式驗證：
驗證字節流是否符合Class文件格式的規範；例如：是否以 0xCAFEBABE開頭、主次版本號是否在當前虛擬機的處理範圍以內、常量池中的常量是否有不被支持的類型。網絡
-
元數據驗證：
對字節碼描述的信息進行語義分析（注意：對比javac編譯階段的語義分析），以保證其描述的信息符合Java語言規範的要求；例如：這個類是否有父類，除了 java.lang.Object以外。數據結構
-
字節碼驗證：
經過數據流和控制流分析，肯定程序語義是合法的、符合邏輯的。jvm
-
符號引用驗證：
確保解析動做能正確執行。
準備：爲類的 靜態變量分配內存，並將其初始化爲默認值
準備階段是正式爲類變量分配內存並設置類變量初始值的階段，這些內存都將在方法區中分配。對於該階段有如下幾點須要注意：
一、這時候進行內存分配的僅包括類變量（static），而不包括實例變量，實例變量會在對象實例化時隨着對象一塊分配在Java堆中。
二、這裏所設置的初始值一般狀況下是數據類型默認的零值（如0、0L、null、false等），而不是被在Java代碼中被顯式地賦予的值。假設一個類變量的定義爲： public static int value=3； 那麼變量value在準備階段事後的初始值爲0，而不是3，由於這時候還沒有開始 執行任何Java方法，而把value賦值爲3的 publicstatic指令是在程序編譯後， 存放於類構造器 <clinit>（）方法之中的，因此把value賦值爲3的動做將在初 始化階段纔會執行。
這裏還須要注意以下幾點：
-
對基本數據類型來講，對於類變量（static）和全局變量，若是不顯式地對其賦值而直接使用，則系統會爲其賦予默認的零值，而對於局部變量來講，在使用前必須顯式地爲其賦值，不然編譯時不經過。
-
對於同時被static和final修飾的常量，必須在聲明的時候就爲其顯式地賦值，不然編譯時不經過；而只被final修飾的常量則既能夠在聲明時顯式地爲其賦值，也能夠在類初始化時顯式地爲其賦值，總之，在使用前必須爲其顯式地賦值，系統不會爲其賦予默認零值。
-
對於引用數據類型reference來講，如數組引用、對象引用等，若是沒有對其進行顯式地賦值而直接使用，系統都會爲其賦予默認的零值，即null。
- 若是在數組初始化時沒有對數組中的各元素賦值，那麼其中的元素將根據對應的數據類型而被賦予默認的零值。
-
三、若是類字段的字段屬性表中存在 ConstantValue屬性，即同時被final和static修飾，那麼在準備階段變量value就會被初始化爲ConstValue屬性所指定的值。
假設上面的類變量value被定義爲： publicstaticfinalintvalue=3；
編譯時Javac將會爲value生成ConstantValue屬性，在準備階段虛擬機就會根據
ConstantValue的設置將value賦值爲3。咱們能夠理解爲static final常量在編譯期
就將其結果放入了調用它的類的常量池中
解析：把類中的符號引用轉換爲直接引用
解析階段是虛擬機將常量池內的符號引用替換爲直接引用的過程，解析動做主要針對類或接口、字段、類方法、接口方法、方法類型、方法句柄和調用點限定符7類符號引用進行。符號引用就是一組符號來描述目標，能夠是任何字面量。
直接引用就是直接指向目標的指針、相對偏移量或一個間接定位到目標的句柄。
初始化
初始化，爲類的靜態變量賦予正確的初始值，JVM負責對類進行初始化，主要對類變量進行初始化。在Java中對類變量進行初始值設定有兩種方式：
①聲明類變量是指定初始值 ②使用靜態代碼塊爲類變量指定初始值
JVM初始化步驟：
一、假如這個類尚未被加載和鏈接，則程序先加載並鏈接該類 二、假如該類的直接父類尚未被初始化，則先初始化其直接父類 三、假如類中有初始化語句，則系統依次執行這些初始化語句
類初始化時機：只有當對類的主動使用的時候纔會致使類的初始化，類的主動使用包括如下六種：
- 建立類的實例，也就是new的方式
- 訪問某個類或接口的靜態變量，或者對該靜態變量賦值
- 調用類的靜態方法
- 反射（如 Class.forName(「com.shengsiyuan.Test」)）
- 初始化某個類的子類，則其父類也會被初始化
- Java虛擬機啓動時被標明爲啓動類的類（ JavaTest），直接使用 java.exe命
令來運行某個主類結束生命週期
在以下幾種狀況下，Java虛擬機將結束生命週期
- 執行了 System.exit()方法
- 程序正常執行結束
- 程序在執行過程當中遇到了異常或錯誤而異常終止
- 因爲操做系統出現錯誤而致使Java虛擬機進程終止
3、類加載器
尋找類加載器，先來一個小例子
package com.neo.classloader;
public class ClassLoaderTest{
public static void main(String[] args) {
ClassLoader loader =Thread.currentThread().getContextClassLoader();
System.out.println(loader);
System.out.println(loader.getParent());
System.out.println(loader.getParent().getParent());
}
}
運行後，輸出結果：
sun.misc.Launcher$AppClassLoader@64fef26a sun.misc.Launcher$ExtClassLoader@1ddd40f3 null
從上面的結果能夠看出，並無獲取到 ExtClassLoader的父Loader，緣由是 BootstrapLoader（引導類加載器）是用C語言實現的，找不到一個肯定的返回父Loader的方式，因而就返回null。
這幾種類加載器的層次關係以下圖所示：
注意：這裏父類加載器並非經過繼承關係來實現的，而是採用組合實現的。
站在Java虛擬機的角度來說，只存在兩種不一樣的類加載器：啓動類加載器：它使用C++實現（這裏僅限於Hotspot，也就是JDK1.5以後默認的虛擬機，有不少其餘的虛擬機是用Java語言實現的），是虛擬機自身的一部分；全部其它的類加載器：這些類加載器都由Java語言實現，獨立於虛擬機以外，而且所有繼承自抽象類 java.lang.ClassLoader，這些類加載器須要由啓動類加載器加載到內存中以後才能去加載其餘的類。
站在Java開發人員的角度來看，類加載器能夠大體劃分爲如下三類：
啓動類加載器：
BootstrapClassLoader，負責加載存放在 JDK\jre\lib(JDK表明JDK的安裝目錄，下同)下，或被 -Xbootclasspath參數指定的路徑中的，而且能被虛擬機識別的類庫（如rt.jar，全部的java.開頭的類均被 BootstrapClassLoader加載）。啓動類加載器是沒法被Java程序直接引用的。
擴展類加載器：
ExtensionClassLoader，該加載器由 sun.misc.Launcher$ExtClassLoader實現，它負責加載 JDK\jre\lib\ext目錄中，或者由 java.ext.dirs系統變量指定的路徑中的全部類庫（如javax.開頭的類），開發者能夠直接使用擴展類加載器。
應用程序類加載器：
ApplicationClassLoader，該類加載器由 sun.misc.Launcher$AppClassLoader來實現，它負責加載用戶類路徑（ClassPath）所指定的類，開發者能夠直接使用該類加載器，若是應用程序中沒有自定義過本身的類加載器，通常狀況下這個就是程序中默認的類加載器。
應用程序都是由這三種類加載器互相配合進行加載的，若是有必要，咱們還能夠加入自定義的類加載器。由於JVM自帶的ClassLoader只是懂得從本地文件系統加載標準的java class文件，所以若是編寫了本身的ClassLoader，即可以作到以下幾點：
一、在執行非置信代碼以前，自動驗證數字簽名。
二、動態地建立符合用戶特定須要的定製化構建類。
三、從特定的場所取得java class，例如數據庫中和網絡中。
JVM類加載機制
- 全盤負責：
當一個類加載器負責加載某個Class時，該Class所依賴的和引用的其餘Class也將由該類加載器負責載入，除非顯示使用另一個類加載器來載入 - 父類委託：
先讓父類加載器試圖加載該類，只有在父類加載器沒法加載該類時才嘗試從本身的類路徑中加載該類先讓父類加載器試圖加載該類，只有在父類加載器沒法加載該類時才嘗試從本身的類路徑中加載該類 - 緩存機制：
緩存機制將會保證全部加載過的Class都會被緩存，當程序中須要使用某個Class時，類加載器先從緩存區尋找該Class，只有緩存區不存在，系統纔會讀取該類對應的二進制數據，並將其轉換成Class對象，存入緩存區。這就是爲何修改了Class後，必須重啓JVM，程序的修改纔會生效4、類的加載
類加載有三種方式：
一、命令行啓動應用時候由JVM初始化加載
二、經過Class.forName()方法動態加載
三、經過ClassLoader.loadClass()方法動態加載
例子：
package com.neo.classloader;
public class loaderTest {
public static void main(String[] args) throws ClassNotFoundException{
ClassLoader loader =HelloWorld.class.getClassLoader();
System.out.println(loader);
//使用ClassLoader.loadClass()來加載類，不會執行初始化塊
loader.loadClass("Test2");
//使用Class.forName()來加載類，默認會執行初始化塊
//Class.forName("Test2");
//使用Class.forName()來加載類，並指定ClassLoader，初始化時不執行靜態塊
//Class.forName("Test2", false, loader);
}
}
demo類
public class Test2{
static{
System.out.println("靜態初始化塊執行了！");
}
}
分別切換加載方式，會有不一樣的輸出結果。
Class.forName()和ClassLoader.loadClass()區別
- Class.forName()：將類的.class文件加載到jvm中以外，還會對類進行解釋，執行類中的static塊；
- ClassLoader.loadClass()：只幹一件事情，就是將.class文件加載到jvm中，不會執行static中的內容,只有在newInstance纔會去執行static塊。
- Class.forName(name,initialize,loader)帶參函數也可控制是否加載static塊。而且只有調用了newInstance()方法採用調用構造函數，建立類的對象 。
5、雙親委派模型
雙親委派模型的工做流程是：若是一個類加載器收到了類加載的請求，它首先不會本身去嘗試加載這個類，而是把請求委託給父加載器去完成，依次向上，所以，全部的類加載請求最終都應該被傳遞到頂層的啓動類加載器中，只有當父加載器在它的搜索範圍中沒有找到所需的類時，即沒法完成該加載，子加載器纔會嘗試本身去加載該類。
雙親委派機制：
一、當 AppClassLoader加載一個class時，它首先不會本身去嘗試加載這個類，而是把類加載請求委派給父類加載器ExtClassLoader去完成。
二、當 ExtClassLoader加載一個class時，它首先也不會本身去嘗試加載這個類，而是把類加載請求委派給BootStrapClassLoader```去完成。
三、若是 BootStrapClassLoader加載失敗（例如在 $JAVA_HOME/jre/lib裏未查找到該class），會使用 ExtClassLoader來嘗試加載；
四、若ExtClassLoader也加載失敗，則會使用 AppClassLoader來加載，若是 AppClassLoader也加載失敗，則會報出異常 ClassNotFoundException。
ClassLoader源碼分析：
public Class<?> loadClass(String name)throws ClassNotFoundException{
return loadClass(name,false);
}
protected synchronized Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException {
// 首先判斷該類型是否已經被加載
Class c =findLoadedClass(name);
if (c == null) {
//若是沒有被加載，就委託給父類加載或者委派給啓動類加載器加載
try{
if(parent != null) {
//若是存在父類加載器，就委派給父類加載器加載
c =parent.loadClass(name, false);
}else{
//若是不存在父類加載器，就檢查是不是由啓動類加載器加載的類，經過調用本地方法native Class findBootstrapClass(String name)
c = findBootstrapClass0(name);
}
}catch (ClassNotFoundException e) {
// 若是父類加載器和啓動類加載器都不能完成加載任務，才調用自身的加載功能
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
雙親委派模型意義：
- 系統類防止內存中出現多份一樣的字節碼
- 保證Java程序安全穩定運行
6、自定義類加載器
一般狀況下，咱們都是直接使用系統類加載器。可是，有的時候，咱們也須要自定義類加載器。好比應用是經過網絡來傳輸 Java類的字節碼，爲保證安全性，這些字節碼通過了加密處理，這時系統類加載器就沒法對其進行加載，這樣則須要自定義類加載器來實現。自定義類加載器通常都是繼承自 ClassLoader類，從上面對 loadClass方法來分析來看，咱們只須要重寫 findClass 方法便可。下面咱們經過一個示例來演示自定義類加載器的流程：
package com.neo.classloader;
import java.io.*;
public classMyClassLoader extends ClassLoader{
privare String root;
protected Class<?> findClass(String name) throws ClassNotFoundException{
byte[] classDate = loadClassDate(name);
if(classDate == null){
throw new ClassNotFoundExcetion();
}else{
return definClass(name, classDate, 0,classDate.length);
}
}
private byte[] loadClassDate(String className){
String fileName = root + File.separatorChar
+ className.replace('.',File.separatorChar) + ".class";
try{
InputStream ins =new FileInputStream(fileName);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize =1024;
byte[] buffer =new byte[bufferSize];
int length = 0;
while ((length = ins.read(buffer))!= -1) {
baos.write(buffer, 0, length);
}
return baos.toByteArray();
}catch(IOException e){
e.printStackTrace();
}
return null;
}
public String getRoot(){
return root;
}
public void setRoot(String root){
this.root = root;
}
public static void main(String[] args）{
MyClassloader classLoader = new MyClassLoader();
classLoader.setRoot("E：\\temp")；
class<?>testClass = null;
try{
testClass = classLoader.loadClass("com.neo.classloader.Test2");
Object object= testClass.newInstance();
System.out.println(object.getClass().getClassLoader());
}catch(ClassNotFoundException e){
e.printStackTrace();
}catch(InstantiationException e){
e.printStackTrace();
}catch(IllegalAccessException e){
e.printStackTrace();
}
}
}
自定義類加載器的核心在於對字節碼文件的獲取，若是是加密的字節碼則須要在該類中對文件進行解密。因爲這裏只是演示，我並未對class文件進行加密，所以沒有解密的過程。這裏有幾點須要注意：
一、這裏傳遞的文件名須要是類的全限定性名稱，即 com.paddx.test.classloading.Test格式的，由於 defineClass 方法是按這種格式進行處理的。
二、最好不要重寫loadClass方法，由於這樣容易破壞雙親委託模式。
三、這類Test 類自己能夠被 AppClassLoader類加載，所以咱們不能把 com/paddx/test/classloading/Test.class放在類路徑下。不然，因爲雙親委託機制的存在，會直接致使該類由 AppClassLoader加載，而不會經過咱們自定義類加載器來加載。
結尾：
本篇針對JVM的加載機制進行了具體分析，因爲我的能力問題，有些地方可能會有手誤，如若發現，煩請告知，JVM的學習還在持續中，敬請期待。
- 1. 關於Jvm類加載機制，這一篇就夠了
- 2. jvm類加載器，類加載機制詳解，看這一篇就夠了
- 3. JAVA類加載機制，看會這一篇就夠了
- 4. 關於JVM，看這一篇就夠了
- 5. JVM 看這一篇就夠了
- 6. 類加載器看這篇就夠了
- 7. 掌握JVM一篇就夠
- 8. InnoDB MVCC 機制，看這篇就夠了
- 9. 轉載：MySQL看這一篇就夠了
- 10. JVM：（一）類加載機制
- 更多相關文章...
- • ionic 加載動作 - ionic 教程
- • ionic 加載動畫 - ionic 教程
- • 漫談MySQL的鎖機制
- • 三篇文章瞭解 TiDB 技術內幕——說存儲
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 在windows下的虛擬機中,安裝華爲電腦的deepin操作系統
- 2. 強烈推薦款下載不限速解析神器
- 3. 【區塊鏈技術】孫宇晨：區塊鏈技術帶來金融服務的信任變革
- 4. 搜索引起的鏈接分析-計算網頁的重要性
- 5. TiDB x 微衆銀行 | 耗時降低 58%，分佈式架構助力實現普惠金融
- 6. 《數字孿生體技術白皮書》重磅發佈（附完整版下載）
- 7. 雙十一「避坑」指南：區塊鏈電子合同爲電商交易保駕護航！
- 8. 區塊鏈產業，怎樣「鏈」住未來？
- 9. OpenglRipper使用教程
- 10. springcloud請求一次好用一次不好用zuul Name or service not known
- 1. 關於Jvm類加載機制，這一篇就夠了
- 2. jvm類加載器，類加載機制詳解，看這一篇就夠了
- 3. JAVA類加載機制，看會這一篇就夠了
- 4. 關於JVM，看這一篇就夠了
- 5. JVM 看這一篇就夠了
- 6. 類加載器看這篇就夠了
- 7. 掌握JVM一篇就夠
- 8. InnoDB MVCC 機制，看這篇就夠了
- 9. 轉載：MySQL看這一篇就夠了
- 10. JVM：（一）類加載機制