1.classsycle
類加載的生命周期：加載（Loading）–>驗證（Verification）–>預(yù)備（Preparation）–>解析（Resolution）–>初始化（Initialization）–>運用（Using）–>卸載（Unloading）。
關(guān)注點1:loading將class二進制文件加載到內(nèi)存中
經(jīng)過一個類的全限定名來獲取界說此類的二進制字節(jié)省。
將這個字節(jié)省所代表的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為辦法區(qū)的運轉(zhuǎn)時數(shù)據(jù)結(jié)構(gòu)。
在java堆中生成一個代表這個類的java.lang.Class目標，做為辦法區(qū)這些數(shù)據(jù)的訪問進口。
加載階段完結(jié)之后二進制字節(jié)省就依照虛擬機所需的格局存儲在方區(qū)去中。
關(guān)注點2:verifaction這一階段的意圖是為了確保Class文件的字節(jié)省中包括的信息契合當(dāng)時虛擬機的要求
文件格局驗證：驗證字節(jié)省是否契合Class文件格局的標準，而且能被當(dāng)時版別的虛擬機處理
元數(shù)據(jù)驗證：對字節(jié)碼描繪的信息進行語義分析，以確保其描繪的信息契合java言語標準的要求。
字節(jié)碼驗證：這個階段的首要作業(yè)是進行數(shù)據(jù)流和控制流的分析。使命是確保被驗證類的辦法在運轉(zhuǎn)時不會做出危害虛擬機安全的行為。
符號引證驗證：這一階段發(fā)生在虛擬機將符號引證轉(zhuǎn)換為直接引證的時分（解析階段），首要是對類本身以外的信息進行匹配性的校驗。意圖是確保解析動作能夠正常履行。
關(guān)注點3:preparation對靜態(tài)變量賦默許值，而不是初始值（方針指），預(yù)備階段是正式為靜態(tài)變量分配內(nèi)存并設(shè)置初始值，這些內(nèi)存都將在辦法區(qū)中進行分配，這兒的變量僅包括類變量（靜態(tài)變量）不包括實例（成員）變量。
關(guān)注點4:resolution：解析是虛擬機將常量池的符號引證替換為直接引證的進程
符號引證：符號引證以一組符號來描繪所引證的方針，符號可所以任意形式的字面量，只要運用時能無歧義地定位到方針即可。符號引證與虛擬機完結(jié)的內(nèi)存布局無關(guān)，引證的方針并不一定現(xiàn)已加載到內(nèi)存中。
直接引證：直接引證可所以直接指向方針的指針，相對偏移量或是一個能直接定位到方針的句柄。直接飲用是與內(nèi)存布局相關(guān)的。
類或接口的解析
字段的解析
類辦法解析
接口辦法解析
關(guān)注點5:initializing擔(dān)任履行類中的靜態(tài)初始化代碼、結(jié)構(gòu)器代碼以及靜態(tài)屬性的初始化(方針值)initializing擔(dān)任履行類中的靜態(tài)初始化代碼、結(jié)構(gòu)器代碼以及靜態(tài)屬性的初始化(方針值)
遇到new、getstatic、putstatic、invokestatic這4個字節(jié)碼指令時，假如類沒有進行過初始化，動身初始化操作。訪問final變量除外？？
運用java.lang.reflect包的辦法對類進行反射調(diào)用時。
當(dāng)初始化一個類的時分，假如發(fā)現(xiàn)其父類還沒有履行初始化則進行初始化。
虛擬機啟動時用戶需求指定一個需求履行的主類，虛擬機首要初始化這個主類。
動態(tài)言語支撐java,lang.invoke.MethodHandle解析成果為REF_getstaticREF_invokestatic的辦法句柄時，該類有必要初始化。
留意：接口與類的初始化規(guī)則在第三點不同，接口不要氣一切的父接口都進行初始化。
2不同類加載器說明
引導(dǎo)類加載器(BootStrap)：
首要擔(dān)任加載JVM本身需求的類，該加載器由C++完結(jié)，加載的是/lib下的class文件，或許-Xbootclasspath參數(shù)指定的途徑下的jar包，留意有必要由虛擬機依照文件名識別加載jar包，如rt.jar，假如文件名不被虛擬機識別，即便把jar丟到lib目錄下也是沒有最用的（出于考慮，Bootstrap啟動類加載器只加載java、javax、sun最初的類），引導(dǎo)類加載器在hotspot虛擬中運用C++言語完結(jié)，它是虛擬機的一部分。除了引導(dǎo)類加載器之外，其他類加載器都是由Java言語完結(jié)，而且全部集成自java.lang.ClassLoader，他們是獨立于虛擬機外部的。
擴展類加載器(Extension)：
擴展類加載是指Sun公司完結(jié)的類，它是由Sun的ExtClassLoader完結(jié)的，是Lancher類的靜態(tài)內(nèi)部類。他擔(dān)任加載/lib/ext目錄下或有體系變量-Djava.ext.dir指定途徑中的類庫，開發(fā)者能夠直接運用標準擴展類加載器
ViewCode
體系類加載器（運用程序加載器AppClassLoader）：
它是由Sun的AppClassLoader完結(jié)的，它擔(dān)任加載體系途徑j(luò)ava-classpath或許-Djava.class.path指定途徑下的類庫，也便是我們經(jīng)常運用到的classpath途徑，開發(fā)者直接運用體系類的加載器，一般情況下該類加載器是程序組中默許的類加載器，經(jīng)過ClassLoad.getSystemClassLoader()辦法能夠獲取到該類的加載器。
自界說類加載器(CustomClassLoader)：
在程序運轉(zhuǎn)期間,經(jīng)過java.lang.ClassLoader的子類動態(tài)加載class文件,體現(xiàn)java動態(tài)實時類裝入特性
3.ClassLoader加載類進程（雙親派遣）
JVM在加載類時默許采用的雙親派遣機制。通俗講，便是某個特定的類加載器在接到類加載器的懇求時，受限將加載使命委傳給父類加載器，依次遞歸，假如父類加載器能夠完結(jié)類的加載使命，就返回成功；只有父類加載器無法完結(jié)此加載器使命時，才去自己加載
4.ClassLoader加載類進程（雙親派遣流程圖）
5.為什么需求雙親派遣機制？
為了體系類的安全，類似“java.lang.Object”這種中心類，JVM需求確保他們生成的目標都會被認定為同一類型，假如用戶編寫了一個lava.lang.Object的同名類并放在ClassPath中，多個類加載器都去加載這個類到內(nèi)存中，體系中會出現(xiàn)多個不同的Object類，那么類之間的比較傲成果以及唯一性將無法確保，而且假如不運用這種雙親派遣模型將會給虛擬機的安全帶來安全隱患。所以要讓類目標進行比較有意義，條件是他們要被同一個類加載器加載。即“經(jīng)過代理形式，對于java中心類庫的類的加載作業(yè)由引導(dǎo)類加載器一致完結(jié)，確保了Java運用所運用的都是同一個版別的Java中心庫的類，是相互兼容的”
好處是防止內(nèi)存中出現(xiàn)多份相同的字節(jié)碼。
6.能不能自己寫個類叫java.lang.System？答案：通常不能夠，但能夠采納另類辦法到達這個需求。
解說：為了不讓我們寫System類，類加載采用托付機制，這樣能夠確保爸爸們優(yōu)先，爸爸們能找到的類，兒子就沒有機會加載。而System類是Bootstrap加載器加載的，就算自己重寫，也總是運用Java體系供給的System，自己寫的System類底子沒有機會得到加載。
但是，我們能夠自己界說一個類加載器來到達這個意圖，為了防止雙親托付機制，這個類加載器也有必要是特別的。因為體系自帶的三個類加載器都加載特定目錄下的類，假如我們自己的類加載器加載一個特別的目錄，那么體系的加載器就無法加載，也便是最終還是由我們自己的加載器加載。
7.如何自界說類加載器
承繼ClassLoader
overwritefindClass()
8.如何打破雙親派遣？
集成ClassLoader
重寫loadClass辦法