Java中的所有類，都需要由類加載器裝載到JVM中才能運行。類加載器本身也是一個類，而它的工作就是把class文件從硬盤讀取到內存中。在寫程序的時候，我們幾乎不需要關心類的加載，因為這些都是隱式裝載的，除非我們有特殊的用法，像是反射，就需要顯式的加載所需要的類。
類裝載方式，有兩種 ：
1.隱式裝載， 程序在運行過程中當碰到通過new 等方式生成對象時，隱式調用類裝載器加載對應的類到jvm中，
2.顯式裝載， 通過class.forname()等方法，顯式加載需要的類
Java類的加載是動態的，它並不會一次性將所有類全部加載后再運行，而是保證程序運行的基礎類(像是基類)完全加載到jvm中，至於其他類，則在需要的時候才加載。這當然就是為了節省內存開銷。
Java的類加載器有三個，對應Java的三種類:
Bootstrap Loader ：啟動類加載器，是虛擬機自身的一部分。負責將存放在\lib目錄中的類庫加載到虛擬機中。其無法被Java程序直接引用。 負責加載系統類 (指的是內置類，像是String，對應於C#中的System類和C/C++標准庫中的類)
ExtClassLoader ： 負責加載擴展類(就是繼承類和實現類)
AppClassLoader ：負責加載用戶類路徑（ClassPath）上所指定的類庫(程序員自定義的類)
JVM中類的加載是由類加載器（ClassLoader）和它的子類來實現的，Java中的類加載器是一個重要的Java運行時系統組件，它負責在運行時查找和裝入類文件中的類。
由於Java的跨平台性，經過編譯的Java源程序並不是一個可執行程序，而是一個或多個類文件。當Java程序需要使用某個類時，JVM會確保這個類已經被加載、連接（驗證、准備和解析）和初始化。
類的加載是指把類的.class文件中的數據讀入到內存中，通常是創建一個字節數組讀入.class文件，然后產生與所加載類對應的Class對象。加載完成后，Class對象還不完整，所以此時的類還不可用。
當類被加載后就進入連接階段，這一階段包括
驗證：為了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，並且不會危害虛擬機自身的安全。
准備：為靜態變量分配內存並設置默認的初始值。
解析：將符號引用替換為直接引用。
最后JVM對類進行初始化，包括：1)如果類存在直接的父類並且這個類還沒有被初始化，那么就先初始化父類；2)如果類中存在初始化語句，就依次執行這些初始化語句。
類的加載是由類加載器完成的，類加載器包括：啟動類加載器（BootStrap）、擴展類加載器（Extension）、應用程序類加載器（Application）。
從Java 2（JDK 1.2）開始，類加載過程采取了雙親委派模型（PDM）。PDM更好的保證了Java平台的安全性，在該機制中，JVM自帶的Bootstrap是啟動類加載器，其他的加載器都有且僅有一個父類加載器。類的加載首先請求父類加載器加載，父類加載器無能為力時才由其子類加載器自行加載。JVM不會向Java程序提供對Bootstrap的引用。
雙親委派模型：要求除了頂層的啟動類加載器外，其余加載器都應當有自己的父類加載器。類加載器之間的父子關系，一般不會以繼承的關系來實現，而是通過組合關系復用父加載器的代碼。
工作過程：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器完成。
每個層次的類加載器都是如此，因此所有的加載請求最終都應該傳送到頂層的啟動類加載器中，
只有到父加載器反饋自己無法完成這個加載請求（它的搜索范圍沒有找到所需的類）時，子加載器才會嘗試自己去加載。
為什么要使用：Java類隨着它的類加載器一起具備了一種帶優先級的層次關系。
比如java.lang.Object，它存放在rt.jar中，無論哪個類加載器要加載這個類，最終都是委派給啟動類加載器進行加載，
因此Object類在程序的各個類加載器環境中，都是同一個類。
自己編寫一個與rt.jar類庫中已有類重名的java類，可以正常編譯，但無法被加載運行。
委托機制的意義 — 防止內存中出現多份同樣的字節碼
比如兩個類A和類B都要加載System類：
如果不用委托而是自己加載自己的，那么類A就會加載一份System字節碼，然后類B又會加載一份System字節碼，這樣內存中就出現了兩份System字節碼。
如果使用委托機制，會遞歸的向父類查找，也就是首選用Bootstrap嘗試加載，如果找不到再向下。這里的System就能在Bootstrap中找到然后加載，如果此時類B也要加載System，也從Bootstrap開始，此時Bootstrap發現已經加載過了System那么直接返回內存中的System即可而不需要重新加載，這樣內存中就只有一份System的字節碼了。
能不能自己寫個類叫java.lang.System？
答案：通常不可以，但可以采取另類方法達到這個需求。
解釋：為了不讓我們寫System類，類加載采用委托機制，這樣可以保證父類加載器優先，父類加載器能找到的類，子加載器就沒有機會加載。而System類是Bootstrap加載器加載的，就算自己重寫，也總是使用Java系統提供的System，自己寫的System類根本沒有機會得到加載。
但是，我們可以自己定義一個類加載器來達到這個目的，為了避免雙親委托機制，這個類加載器也必須是特殊的。由於系統自帶的三個類加載器都加載特定目錄下的類，如果我們自己的類加載器放在一個特殊的目錄，那么系統的加載器就無法加載，也就是最終還是由我們自己的加載器加載。
1、JVM 簡介
JVM 是我們Javaer 的最基本功底了，剛開始學Java 的時候，一般都是從“Hello World ”開始的，然后會寫個復雜點class ，然后再找一些開源框架，比如Spring ，Hibernate 等等，再然后就開發企業級的應用，比如網站、企業內部應用、實時交易系統等等，直到某一天突然發現做的系統咋就這么慢呢，而且時不時還來個內存溢出什么的，今天是交易系統報了StackOverflowError ，明天是網站系統報了個OutOfMemoryError ，這種錯誤又很難重現，只有分析Javacore 和dump 文件，運氣好點還能分析出個結果，運行遭的點，就直接去廟里燒香吧！每天接客戶的電話都是戰戰兢兢的，生怕再出什么幺蛾子了。我想Java 做的久一點的都有這樣的經歷，那這些問題的最終根結是在哪呢？—— JVM 。
JVM 全稱是Java Virtual Machine ，Java 虛擬機，也就是在計算機上再虛擬一個計算機，這和我們使用 VMWare不一樣，那個虛擬的東西你是可以看到的，這個JVM 你是看不到的，它存在內存中。我們知道計算機的基本構成是：運算器、控制器、存儲器、輸入和輸出設備，那這個JVM 也是有這成套的元素，運算器是當然是交給硬件CPU 還處理了，只是為了適應“一次編譯，隨處運行”的情況，需要做一個翻譯動作，於是就用了JVM 自己的命令集，這與匯編的命令集有點類似，每一種匯編命令集針對一個系列的CPU ，比如8086 系列的匯編也是可以用在8088 上的，但是就不能跑在8051 上，而JVM 的命令集則是可以到處運行的，因為JVM 做了翻譯，根據不同的CPU ，翻譯成不同的機器語言。
JVM 中我們最需要深入理解的就是它的存儲部分，存儲？硬盤？NO ，NO ， JVM 是一個內存中的虛擬機，那它的存儲就是內存了，我們寫的所有類、常量、變量、方法都在內存中，這決定着我們程序運行的是否健壯、是否高效，接下來的部分就是重點介紹之。
2、JVM 的組成部分
我們先把JVM 這個虛擬機畫出來，如下圖所示：
從這個圖中可以看到，JVM 是運行在操作系統之上的，它與硬件沒有直接的交互。我們再來看下JVM 有哪些組成部分，如下圖所示：
該圖參考了網上廣為流傳的JVM 構成圖，大家看這個圖，整個JVM 分為四部分：
## Class Loader 類加載器
類加載器的作用是加載類文件到內存，比如編寫一個HelloWord.java 程序，然后通過javac 編譯成class 文件，那怎么才能加載到內存中被執行呢？Class Loader 承擔的就是這個責任，那不可能隨便建立一個.class 文件就能被加載的，Class Loader 加載的class 文件是有格式要求，在《JVM Specification 》中式這樣定義Class 文件的結構：
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_info methods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
需要詳細了解的話，可以仔細閱讀《JVM Specification 》的第四章“The class File Format ”，這里不再詳細說明。
友情提示：Class Loader 只管加載，只要符合文件結構就加載，至於說能不能運行，則不是它負責的，那是由Execution Engine 負責的。
## Execution Engine 執行引擎
執行引擎也叫做解釋器(Interpreter) ，負責解釋命令，提交操作系統執行。
## Native Interface 本地接口
本地接口的作用是融合不同的編程語言為Java 所用，它的初衷是融合C/C++ 程序，Java 誕生的時候是C/C++ 橫行的時候，要想立足，必須有一個聰明的、睿智的調用C/C++ 程序，於是就在內存中專門開辟了一塊區域處理標記為native 的代碼，它的具體做法是Native Method Stack 中登記native 方法，在Execution Engine 執行時加載native libraies 。目前該方法使用的是越來越少了，除非是與硬件有關的應用，比如通過Java 程序驅動打印機，或者Java 系統管理生產設備，在企業級應用中已經比較少見，因為現在的異構領域間的通信很發達，比如可以使用Socket 通信，也可以使用Web Service 等等，不多做介紹。
## Runtime data area 運行數據區
運行數據區是整個JVM 的重點。我們所有寫的程序都被加載到這里，之后才開始運行，Java 生態系統如此的繁榮，得益於該區域的優良自治。
整個JVM 框架由加載器加載文件，然后執行器在內存中處理數據，需要與異構系統交互是可以通過本地接口進行，瞧，一個完整的系統誕生了！
3、JVM加載class文件的原理機制
Java中的所有類，都需要由類加載器裝載到JVM中才能運行。類加載器本身也是一個類，而它的工作就是把class文件從硬盤讀取到內存中。在寫程序的時候，我們幾乎不需要關心類的加載，因為這些都是隱式裝載的，除非我們有特殊的用法，像是反射，就需要顯式的加載所需要的類。
類裝載方式，有兩種
1.隱式裝載， 程序在運行過程中當碰到通過new 等方式生成對象時，隱式調用類裝載器加載對應的類到jvm中，
2.顯式裝載， 通過class.forname()等方法，顯式加載需要的類
隱式加載與顯式加載的區別：兩者本質是一樣?
Java類的加載是動態的，它並不會一次性將所有類全部加載后再運行，而是保證程序運行的基礎類(像是基類)完全加載到jvm中，至於其他類，則在需要的時候才加載。這當然就是為了節省內存開銷。
Java的類加載器有三個，對應Java的三種類:（java中的類大致分為三種： 1.系統類 2.擴展類 3.由程序員自定義的類 ）
Bootstrap Loader // 負責加載系統類 (指的是內置類，像是String，對應於C#中的System類和C/C++標准庫中的類)
|
- - ExtClassLoader // 負責加載擴展類(就是繼承類和實現類)
|
- - AppClassLoader // 負責加載應用類(程序員自定義的類)
三個加載器各自完成自己的工作，但它們是如何協調工作呢？哪一個類該由哪個類加載器完成呢？為了解決這個問題，Java采用了委托模型機制。
委托模型機制的工作原理很簡單：當類加載器需要加載類的時候，先請示其Parent(即上一層加載器)在其搜索路徑載入，如果找不到，才在自己的搜索路徑搜索該類。這樣的順序其實就是加載器層次上自頂而下的搜索，因為加載器必須保證基礎類的加載。之所以是這種機制，還有一個安全上的考慮：如果某人將一個惡意的基礎類加載到jvm，委托模型機制會搜索其父類加載器，顯然是不可能找到的，自然就不會將該類加載進來。
我們可以通過這樣的代碼來獲取類加載器:
ClassLoader loader = ClassName.class.getClassLoader(); ClassLoader ParentLoader = loader.getParent();
注意一個很重要的問題，就是Java在邏輯上並不存在BootstrapKLoader的實體！因為它是用C++編寫的，所以打印其內容將會得到null。
前面是對類加載器的簡單介紹，它的原理機制非常簡單，就是下面幾個步驟:
1.裝載:查找和導入class文件;
2.連接:
(1)檢查:檢查載入的class文件數據的正確性;
(2)准備:為類的靜態變量分配存儲空間;
(3)解析:將符號引用轉換成直接引用(這一步是可選的)
3.初始化:初始化靜態變量，靜態代碼塊。
這樣的過程在程序調用類的靜態成員的時候開始執行，所以靜態方法main()才會成為一般程序的入口方法。類的構造器也會引發該動作。
附錄：
https://www.cnblogs.com/Qian123/p/5707562.html