JVM中Class文件的加載過(guò)程

這篇文章主要講解了“JVM中Class文件的加載過(guò)程”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“JVM中Class文件的加載過(guò)程”吧！

Class文件加載過(guò)程
JVM加載Class文件主要分3個(gè)過(guò)程：Loading 、Linking、Initialzing

1.Loading
Loading的過(guò)程就是通過(guò)類加載器將.class文件加載到j(luò)vm內(nèi)存中過(guò)程。需要理解雙親委派機(jī)制、類加載器ClassLoader，加載過(guò)程如下。

ClassLoader

不同的類加載器加載范圍不一樣，以Java8中的為例。

BootClassLoader 加載范圍sun.boot.class.pahtExtClassLoader 加載范圍java.ext.dirsAppClassLoader 加載范圍java.class.pathCustomClassLoader 可自定義加載范圍

前三個(gè)加載器來(lái)自JDK的Launcher類，三個(gè)ClassLoader作為L(zhǎng)auncher的內(nèi)部類，感興趣可以查看下源碼。

開(kāi)發(fā)者也可以自定義的ClassLoader，自定義記載范圍。

雙親委派機(jī)制

自底向上檢查該類是否已經(jīng)加載，parent方向；自頂向下進(jìn)行類的實(shí)際查找和加載，child方向。 類的加載遵循雙親委派機(jī)制，主要是出于安全的考慮。雙親委派機(jī)制是如何實(shí)現(xiàn)的，下面源碼會(huì)解釋。

注意：雙親委派中存在所謂的父加載器并不是加載器的加載器，只是翻譯的問(wèn)題，別混淆了類的繼承概念。

ClassLoader源碼

ClassLoader源碼中比較重要的一個(gè)函數(shù)是loadClass()，執(zhí)行過(guò)程是：findLoadedClass()->parrent.loadClass()->findClass(),第一步是自底向上查詢是否已經(jīng)加載，第二步是自頂向下查找加載類。這里就規(guī)定或是說(shuō)實(shí)現(xiàn)了雙親委派機(jī)制。詳細(xì)見(jiàn)ClassLoader的源碼。

自定義ClassLoader

如何自定義ClassLoader？可以繼承ClassLoader類，重新自己的findClass(),在里面調(diào)用defineClass()來(lái)實(shí)現(xiàn)自定義加載特定范圍的類。

如何打破雙親委派機(jī)制，哪種情形下打破過(guò)？

從上面的ClassLoader源碼中大概能看出是如何實(shí)現(xiàn)了雙親委派機(jī)制的，從這入手可以通過(guò)2種方式打破該機(jī)制：

super(parent)指定parent會(huì)打破該機(jī)制自定義ClassLoader重寫loadClass()也可以打破

何時(shí)打破過(guò)？雙親委派機(jī)制并不是不能打破，某些特殊場(chǎng)景下也會(huì)選擇打破該機(jī)制。

JDK 1.2之前，自定義ClassLoader必須重寫loadClass()，打破過(guò)。線程ThreadContextClassLoader可以實(shí)現(xiàn)基礎(chǔ)類調(diào)用實(shí)現(xiàn)類代碼，通過(guò)thread.setContextClassLoader指定。熱啟動(dòng)熱部署，如tomcat都有自己模塊指定的classloader，可以加載同一類庫(kù)的不同版本。

Class執(zhí)行方式

Class執(zhí)行方式分為3種：解釋執(zhí)行、編譯執(zhí)行、混合執(zhí)行，各有優(yōu)缺點(diǎn)，可通過(guò)參數(shù)指定。

1.解釋執(zhí)行：使用bytecode intepreter 解釋器解釋執(zhí)行，該模式啟動(dòng)很快，執(zhí)行稍慢，可通過(guò)-Xint參數(shù)指定該模式。
2.編譯執(zhí)行：使用 Just in time Complier JIT編譯器編譯執(zhí)行，該模式執(zhí)行很快，編譯很慢，可通過(guò)-Xcomp參數(shù)指定該模式。
3.混合執(zhí)行：默認(rèn)的模式，解釋器+熱點(diǎn)代碼編譯，開(kāi)始解釋執(zhí)行，啟動(dòng)較快，對(duì)熱點(diǎn)代碼進(jìn)行實(shí)時(shí)監(jiān)測(cè)和編譯成本地代碼執(zhí)行，可通過(guò)-Xmixed參數(shù)指定該模式。
熱點(diǎn)代碼監(jiān)測(cè)：多次被調(diào)用的方法用方法計(jì)數(shù)器，多次被調(diào)用的循環(huán)用循環(huán)計(jì)數(shù)器，可通過(guò)參數(shù)-XX:CompileThreshold = 10000指定觸發(fā)JIT編譯的閾值。

2.Linking
Linking鏈接的過(guò)程分3個(gè)階段：Vertification、Preparation、Resolution。

• Vertification： 驗(yàn)證Class文件是否符合JVM規(guī)定。

• Preparation：給靜態(tài)成員變量賦默認(rèn)值

• Resolution：將類、方法、屬性等符號(hào)引用解釋為直接引用；常量池中的各種符號(hào)引用解釋為指針、偏移量等內(nèi)存地址的直接引用

3. Initializing
調(diào)用初始化代碼clint,給靜態(tài)成員變量賦初始值。

這里可以了解下必須初始化的5種情況：

new getstatic putstatic invokestatic指令，訪問(wèn)final變量除外java.lang.reflect對(duì)類進(jìn)行反射調(diào)用時(shí)初始化子類的時(shí)候，父類必須初始化虛擬機(jī)啟動(dòng)時(shí)，被執(zhí)行的主類必須初始化動(dòng)態(tài)語(yǔ)言支持java.lang.invoke.MethodHandler解釋的結(jié)果為REF_getstatic REF_putstatic REF_invokestatic的方法句柄時(shí)，該類必須初始化。

4.總結(jié)思考
設(shè)計(jì)模式中單例模式的雙重檢查的實(shí)現(xiàn)，INSTANCE是否需要加valatile？

public class Mgr06 {     // 是否需要加volatile?     private static volatile Mgr06 INSTANCE;      private Mgr06() {     }      public static Mgr06 getInstance() {         if (INSTANCE == null) {             //雙重檢查             synchronized (Mgr06.class) {                 if(INSTANCE == null) {                     try {                         Thread.sleep(1);                     } catch (InterruptedException e) {                         e.printStackTrace();                     }                     // new 了對(duì)象，不為null,但未完成變量的初始化復(fù)制，對(duì)象處于半初始化狀                    態(tài)，其它線程有可能取到半初始化的對(duì)象。                     INSTANCE = new Mgr06();                 }             }         }         return INSTANCE;     } } 復(fù)制代碼

感謝各位的閱讀，以上就是“JVM中Class文件的加載過(guò)程”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)JVM中Class文件的加載過(guò)程這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！