你知道 Java 类是如何被加载的吗？
一：前言
最近給一個(gè)非Java方向的朋友講了下雙親委派模型，朋友讓我寫篇文章深度研究下JVM的ClassLoader，我確實(shí)也好久沒(méi)寫JVM相關(guān)的文章了，有點(diǎn)手癢癢，涂了皮炎平也抑制不住。
我在向朋友解釋的時(shí)候是這么說(shuō)的：雙親委派模型中，ClassLoader在加載類的時(shí)候，會(huì)先交由它的父ClassLoader加載，只有當(dāng)父ClassLoader加載失敗的情況下，才會(huì)嘗試自己去加載。這樣可以實(shí)現(xiàn)部分類的復(fù)用，又可以實(shí)現(xiàn)部分類的隔離，因?yàn)椴煌珻lassLoader加載的類是互相隔離的。
不過(guò)貿(mào)然的向別人解釋雙親委派模型是不妥的，如果在不了解JVM的類加載機(jī)制的情況下，又如何能很好的理解“不同ClassLoader加載的類是互相隔離的”這句話呢？所以為了理解雙親委派，最好的方式，就是先了解下ClassLoader的加載流程。
二：Java 類是如何被加載的
2.1：何時(shí)加載類
我們首先要清楚的是，Java類何時(shí)會(huì)被加載？
《深入理解Java虛擬機(jī)》給出的答案是：
1：遇到new、getstatic、putstatic 等指令時(shí)。
2：對(duì)類進(jìn)行反射調(diào)用的時(shí)候。
3：初始化某個(gè)類的子類的時(shí)候。
4：虛擬機(jī)啟動(dòng)時(shí)會(huì)先加載設(shè)置的程序主類。
5：使用JDK 1.7 的動(dòng)態(tài)語(yǔ)言支持的時(shí)候。
其實(shí)要我說(shuō)，最通俗易懂的答案就是：當(dāng)運(yùn)行過(guò)程中需要這個(gè)類的時(shí)候。
那么我們不妨就從如何加載類開(kāi)始說(shuō)起。
2.2：怎么加載類
利用ClassLoader加載類很簡(jiǎn)單，直接調(diào)用ClassLoder的loadClass（）方法即可，我相信大家都會(huì)，但是還是要舉個(gè)栗子：
上面這段代碼便實(shí)現(xiàn)了讓ClassLoader去加載 “com.wangxiandeng.test.Dog” 這個(gè)類，是不是 so easy。但是JDK 提供的 API 只是冰山一角，看似很簡(jiǎn)單的一個(gè)調(diào)用，其實(shí)隱藏了非常多的細(xì)節(jié)，我這個(gè)人吧，最喜歡做的就是去揭開(kāi) API 的封裝，一探究竟。
2.3：JVM 是怎么加載類的
JVM 默認(rèn)用于加載用戶程序的ClassLoader為AppClassLoader，不過(guò)無(wú)論是什么ClassLoader，它的根父類都是java.lang.ClassLoader。在上面那個(gè)例子中，loadClass（）方法最終會(huì)調(diào)用到ClassLoader.definClass1（）中，這是一個(gè) Native 方法。
看到 Native 方法莫心慌，不要急，打開(kāi)OpenJDK源碼，我等繼續(xù)走馬觀花便是！
definClass1（）對(duì)應(yīng)的 JNI 方法為 Java_java_lang_ClassLoader_defineClass1（）
JNIEXPORT jclass JNICALL Java_java_lang_ClassLoader_defineClass1(JNIEnv *env,jclass cls,jobject loader,jstring name,jbyteArray data,jint offset,jint length,jobject pd,jstring source) {......result = JVM_DefineClassWithSource(env, utfName, loader, body, length, pd, utfSource);......return result; }Java_java_lang_ClassLoader_defineClass1 主要是調(diào)用了JVM_DefineClassWithSource（）加載類，跟著源碼往下走，會(huì)發(fā)現(xiàn)最終調(diào)用的是 jvm.cpp 中的 jvm_define_class_common（）方法。
static jclass jvm_define_class_common(JNIEnv *env, const char *name,jobject loader, const jbyte *buf,jsize len, jobject pd, const char *source,TRAPS) {......ClassFileStream st((u1*)buf, len, source, ClassFileStream::verify);Handle class_loader (THREAD, JNIHandles::resolve(loader));if (UsePerfData) {is_lock_held_by_thread(class_loader,ClassLoader::sync_JVMDefineClassLockFreeCounter(),THREAD);}Handle protection_domain (THREAD, JNIHandles::resolve(pd));Klass* k = SystemDictionary::resolve_from_stream(class_name,class_loader,protection_domain,&st,CHECK_NULL);......return (jclass) JNIHandles::make_local(env, k->java_mirror()); }上面這段邏輯主要就是利用 ClassFileStream 將要加載的class文件轉(zhuǎn)成文件流，然后調(diào)用SystemDictionary::resolve_from_stream（），生成 Class 在 JVM 中的代表：Klass。對(duì)于Klass，大家可能不太熟悉，但是在這里必須得了解下。說(shuō)白了，它就是JVM 用來(lái)定義一個(gè)Java Class 的數(shù)據(jù)結(jié)構(gòu)。不過(guò)Klass只是一個(gè)基類，Java Class 真正的數(shù)據(jù)結(jié)構(gòu)定義在 InstanceKlass中。
class InstanceKlass: public Klass {protected:Annotations* _annotations;......ConstantPool* _constants;......Array<jushort>* _inner_classes;......Array<Method*>* _methods;Array<Method*>* _default_methods;......Array<u2>* _fields; }可見(jiàn) InstanceKlass 中記錄了一個(gè) Java 類的所有屬性，包括注解、方法、字段、內(nèi)部類、常量池等信息。這些信息本來(lái)被記錄在Class文件中，所以說(shuō)，InstanceKlass就是一個(gè)Java Class 文件被加載到內(nèi)存后的形式。
再回到上面的類加載流程中，這里調(diào)用了 SystemDictionary::resolve_from_stream（），將 Class 文件加載成內(nèi)存中的 Klass。
resolve_from_stream（） 便是重中之重！主要邏輯有下面幾步：
1：判斷是否允許并行加載類，并根據(jù)判斷結(jié)果進(jìn)行加鎖。
bool DoObjectLock = true; if (is_parallelCapable(class_loader)) {DoObjectLock = false; } ClassLoaderData* loader_data = register_loader(class_loader, CHECK_NULL); Handle lockObject = compute_loader_lock_object(class_loader, THREAD); check_loader_lock_contention(lockObject, THREAD); ObjectLocker ol(lockObject, THREAD, DoObjectLock);如果允許并行加載，則不會(huì)對(duì)ClassLoader進(jìn)行加鎖，只對(duì)SystemDictionary加鎖。否則，便會(huì)利用 ObjectLocker 對(duì)ClassLoader 加鎖，保證同一個(gè)ClassLoader在同一時(shí)刻只能加載一個(gè)類。ObjectLocker 會(huì)在其構(gòu)造函數(shù)中獲取鎖，并在析構(gòu)函數(shù)中釋放鎖。
允許并行加載的好處便是精細(xì)化了鎖粒度，這樣可以在同一時(shí)刻加載多個(gè)Class文件。
2：解析文件流，生成 InstanceKlass。
InstanceKlass* k = NULL;k = KlassFactory::create_from_stream(st,class_name,loader_data,protection_domain,NULL, // host_klassNULL, // cp_patchesCHECK_NULL);3：利用SystemDictionary注冊(cè)生成的 Klass。
SystemDictionary 是用來(lái)幫助保存 ClassLoader 加載過(guò)的類信息的。準(zhǔn)確點(diǎn)說(shuō)，SystemDictionary并不是一個(gè)容器，真正用來(lái)保存類信息的容器是 Dictionary，每個(gè)ClassLoaderData 中都保存著一個(gè)私有的 Dictionary，而 SystemDictionary 只是一個(gè)擁有很多靜態(tài)方法的工具類而已。
我們來(lái)看看注冊(cè)的代碼：
if (is_parallelCapable(class_loader)) {InstanceKlass* defined_k = find_or_define_instance_class(h_name, class_loader, k, THREAD);if (!HAS_PENDING_EXCEPTION && defined_k != k) {// If a parallel capable class loader already defined this class, register 'k' for cleanup.assert(defined_k != NULL, "Should have a klass if there's no exception");loader_data->add_to_deallocate_list(k);k = defined_k;} } else {define_instance_class(k, THREAD); }如果允許并行加載，那么前面就不會(huì)對(duì)ClassLoader加鎖，所以在同一時(shí)刻，可能對(duì)同一Class文件加載了多次。但是同一Class在同一ClassLoader中必須保持唯一性，所以這里會(huì)先利用 SystemDictionary 查詢 ClassLoader 是否已經(jīng)加載過(guò)相同 Class。
如果已經(jīng)加載過(guò)，那么就將當(dāng)前線程剛剛加載的InstanceKlass加入待回收列表，并將 InstanceKlass* k 重新指向利用SystemDictionary查詢到的 InstanceKlass。
如果沒(méi)有查詢到，那么就將剛剛加載的 InstanceKlass 注冊(cè)到 ClassLoader的 Dictionary 中 中。
雖然并行加載不會(huì)鎖住ClassLoader，但是會(huì)在注冊(cè) InstanceKlass 時(shí)對(duì) SystemDictionary 加鎖，所以不需要擔(dān)心InstanceKlass 在注冊(cè)時(shí)的并發(fā)操作。
如果禁止了并行加載，那么直接利用SystemDictionary將 InstanceKlass 注冊(cè)到 ClassLoader的 Dictionary 中即可。
resolve_from_stream（）的主要流程就是上面三步，很明顯，最重要的是第二步，從文件流生成InstanceKlass。
生成InstanceKlass 調(diào)用的是 KlassFactory::create_from_stream（）方法，它的主要邏輯就是下面這段代碼。
ClassFileParser parser(stream,name,loader_data,protection_domain,host_klass,cp_patches,ClassFileParser::BROADCAST, // publicity levelCHECK_NULL);InstanceKlass* result = parser.create_instance_klass(old_stream != stream, CHECK_NULL);原來(lái) ClassFileParser 才是真正的主角啊！它才是將Class文件升華成InstanceKlass的幕后大佬！
2.4：不得不說(shuō)的ClassFileParser
ClassFileParser 加載Class文件的入口便是 create_instance_klass（）。顧名思義，用來(lái)創(chuàng)建InstanceKlass的。
create_instance_klass（）主要就干了兩件事：
(1)：為 InstanceKlass 分配內(nèi)存
InstanceKlass* const ik =InstanceKlass::allocate_instance_klass(*this, CHECK_NULL);(2)：分析Class文件，填充 InstanceKlass 內(nèi)存區(qū)域
fill_instance_klass(ik, changed_by_loadhook, CHECK_NULL);
我們先來(lái)說(shuō)道說(shuō)道第一件事，為 InstanceKlass 分配內(nèi)存。
內(nèi)存分配代碼如下：
const int size = InstanceKlass::size(parser.vtable_size(),parser.itable_size(),nonstatic_oop_map_size(parser.total_oop_map_count()),parser.is_interface(),parser.is_anonymous(),should_store_fingerprint(parser.is_anonymous())); ClassLoaderData* loader_data = parser.loader_data(); InstanceKlass* ik; ik = new (loader_data, size, THREAD) InstanceKlass(parser, InstanceKlass::_misc_kind_other);這里首先計(jì)算了InstanceKlass在內(nèi)存中的大小，要知道，這個(gè)大小在Class 文件編譯后就被確定了。
然后便 new 了一個(gè)新的 InstanceKlass 對(duì)象。這里并不是簡(jiǎn)單的在堆上分配內(nèi)存，要注意的是Klass 對(duì) new 操作符進(jìn)行了重載：
void* Klass::operator new(size_t size, ClassLoaderData* loader_data, size_t word_size, TRAPS) throw() {return Metaspace::allocate(loader_data, word_size, MetaspaceObj::ClassType, THREAD); }分配 InstanceKlass 的時(shí)候調(diào)用了 Metaspace::allocate（）：
MetaspaceObj::Type type, TRAPS) {......MetadataType mdtype = (type == MetaspaceObj::ClassType) ? ClassType : NonClassType;......MetaWord* result = loader_data->metaspace_non_null()->allocate(word_size, mdtype);......return result; }由此可見(jiàn)，InstanceKlass 是分配在 ClassLoader的 Metaspace（元空間） 的方法區(qū)中。從 JDK8 開(kāi)始，HotSpot 就沒(méi)有了永久代，類都分配在 Metaspace 中。Metaspace 和永久代不一樣，采用的是 Native Memory，永久代由于受限于 MaxPermSize，所以當(dāng)內(nèi)存不夠時(shí)會(huì)內(nèi)存溢出。
分配完 InstanceKlass 內(nèi)存后，便要著手第二件事，分析Class文件，填充 InstanceKlass 內(nèi)存區(qū)域。
ClassFileParser 在構(gòu)造的時(shí)候就會(huì)開(kāi)始分析Class文件，所以fill_instance_klass（）中只需要填充即可。填充結(jié)束后，還會(huì)調(diào)用 java_lang_Class::create_mirror（）創(chuàng)建 InstanceKlass 在Java 層的 Class 對(duì)象。
void ClassFileParser::fill_instance_klass(InstanceKlass* ik, bool changed_by_loadhook, TRAPS) {.....ik->set_class_loader_data(_loader_data);ik->set_nonstatic_field_size(_field_info->nonstatic_field_size);ik->set_has_nonstatic_fields(_field_info->has_nonstatic_fields);ik->set_static_oop_field_count(_fac->count[STATIC_OOP]);ik->set_name(_class_name);......java_lang_Class::create_mirror(ik,Handle(THREAD, _loader_data->class_loader()),module_handle,_protection_domain,CHECK); }順便提一句，對(duì)于Class文件結(jié)構(gòu)不熟悉的同學(xué)，可以看下我兩年前寫的一篇文章：
《汪先生：Jvm之用java解析class文件》
到這兒，Class文件已經(jīng)完成了華麗的轉(zhuǎn)身，由冷冰冰的二進(jìn)制文件，變成了內(nèi)存中充滿生命力的InstanceKlass。
三：再談雙親委派
如果你耐心的看完了上面的源碼分析，你一定對(duì) “不同ClassLoader加載的類是互相隔離的” 這句話的理解又上了一個(gè)臺(tái)階。
我們總結(jié)下：每個(gè)ClassLoader都有一個(gè) Dictionary 用來(lái)保存它所加載的InstanceKlass信息。并且，每個(gè) ClassLoader 通過(guò)鎖，保證了對(duì)于同一個(gè)Class，它只會(huì)注冊(cè)一份 InstanceKlass 到自己的 Dictionary 。
正式由于上面這些原因，如果所有的 ClassLoader 都由自己去加載 Class 文件，就會(huì)導(dǎo)致對(duì)于同一個(gè)Class文件，存在多份InstanceKlass，所以即使是同一個(gè)Class文件，不同InstanceKlasss 衍生出來(lái)的實(shí)例類型也是不一樣的。
舉個(gè)栗子，我們自定義一個(gè) ClassLoader，用來(lái)打破雙親委派模型：
public class CustomClassloader extends URLClassLoader {public CustomClassloader(URL[] urls) {super(urls);}@Overrideprotected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {if (name.startsWith("com.wangxiandeng")) {return findClass(name);}return super.loadClass(name, resolve);} }再嘗試加載Studen類，并實(shí)例化：
public class Test {public static void main(String[] args) throws Exception {URL url[] = new URL[1];url[0] = Thread.currentThread().getContextClassLoader().getResource("");CustomClassloader customClassloader = new CustomClassloader(url);Class clazz = customClassloader.loadClass("com.wangxiandeng.Student");Student student = (Student) clazz.newInstance();} }運(yùn)行后便會(huì)拋出類型強(qiáng)轉(zhuǎn)異常：
Exception in thread "main" java.lang.ClassCastException:com.wangxiandeng.Student cannot be cast to com.wangxiandeng.Student為什么呢？
因?yàn)閷?shí)例化的Student對(duì)象所屬的 InstanceKlass 是由CustomClassLoader加載生成的，而我們要強(qiáng)轉(zhuǎn)的類型Student.Class 對(duì)應(yīng)的 InstanceKlass 是由系統(tǒng)默認(rèn)的ClassLoader生成的，所以本質(zhì)上它們就是兩個(gè)毫無(wú)關(guān)聯(lián)的InstanceKlass，當(dāng)然不能強(qiáng)轉(zhuǎn)。
有同學(xué)問(wèn)到：為什么“強(qiáng)轉(zhuǎn)的類型Student.Class 對(duì)應(yīng)的 InstanceKlass 是由系統(tǒng)默認(rèn)的ClassLoader生成的”？
其實(shí)很簡(jiǎn)單，我們反編譯下字節(jié)碼：
可以看到在利用加載的Class初始化實(shí)例后，調(diào)用了 checkcast 進(jìn)行類型轉(zhuǎn)化，checkcast 后的操作數(shù) #12 即為Student這個(gè)類在常量池中的索引：
#12 = Class #52 // com/wangxiandeng/Student
下面我們可以看看 checkcast 在HotSpot中的實(shí)現(xiàn)。
HotSpot 目前有三種字節(jié)碼執(zhí)行引擎，目前采用的是模板解釋器，可以看下我這篇文章：《汪先生：JVM之模板解釋器》。
早期的HotSpot采用的是字節(jié)碼解釋器。模板解釋器對(duì)于指令的執(zhí)行都是用匯編寫的，而字節(jié)碼解釋器采用的C++進(jìn)行的翻譯，為了看起來(lái)比較舒服，我們就不看匯編了，直接看字節(jié)碼解釋器就行了。如果你的匯編功底很好，當(dāng)然也可以直接看模板解釋器，我之前寫的文章《汪先生：JVM之創(chuàng)建對(duì)象源碼分析》這里就是分析模板解釋器對(duì)于 new 指令的實(shí)現(xiàn)。
廢話不多說(shuō)，我們來(lái)看看字節(jié)碼解釋器對(duì)于checkcast的實(shí)現(xiàn)，代碼在 bytecodeInterpreter.cpp 中
CASE(_checkcast):if (STACK_OBJECT(-1) != NULL) {VERIFY_OOP(STACK_OBJECT(-1));// 拿到 checkcast 指令后的操作數(shù)，本例子中即 Student.Class 在常量池中的索引：#12u2 index = Bytes::get_Java_u2(pc+1);// 如果常量池還沒(méi)有解析，先進(jìn)行解析，即將常量池中的符號(hào)引用替換成直接引用，//此時(shí)就會(huì)觸發(fā)Student.Class 的加載if (METHOD->constants()->tag_at(index).is_unresolved_klass()) {CALL_VM(InterpreterRuntime::quicken_io_cc(THREAD), handle_exception);}// 獲取上一步系統(tǒng)加載的Student.Class 對(duì)應(yīng)的 InstanceKlassKlass* klassOf = (Klass*) METHOD->constants()->resolved_klass_at(index);// 獲取要強(qiáng)轉(zhuǎn)的對(duì)象的實(shí)際類型，即我們自己手動(dòng)加載的Student.Class 對(duì)應(yīng)的 InstanceKlassKlass* objKlass = STACK_OBJECT(-1)->klass(); // ebx// 現(xiàn)在就比較簡(jiǎn)單了，直接看看上面的兩個(gè)InstanceKlass指針內(nèi)容是否相同// 不同的情況下則判斷是否存在繼承關(guān)系if (objKlass != klassOf && !objKlass->is_subtype_of(klassOf)) {// Decrement counter at checkcast.BI_PROFILE_SUBTYPECHECK_FAILED(objKlass);ResourceMark rm(THREAD);char* message = SharedRuntime::generate_class_cast_message(objKlass, klassOf);VM_JAVA_ERROR(vmSymbols::java_lang_ClassCastException(), message, note_classCheck_trap);}// Profile checkcast with null_seen and receiver.BI_PROFILE_UPDATE_CHECKCAST(/*null_seen=*/false, objKlass);} else {// Profile checkcast with null_seen and receiver.BI_PROFILE_UPDATE_CHECKCAST(/*null_seen=*/true, NULL);}通過(guò)對(duì)上面代碼的分析，我相信大家已經(jīng)理解了 “強(qiáng)轉(zhuǎn)的類型Student.Class 對(duì)應(yīng)的 InstanceKlass 是由系統(tǒng)默認(rèn)的ClassLoader生成的” 這句話了。
雙親委派的好處是盡量保證了同一個(gè)Class文件只會(huì)生成一個(gè)InstanceKlass，但是某些情況，我們就不得不去打破雙親委派了，比如我們想實(shí)現(xiàn)Class隔離的時(shí)候。
回復(fù)下簫陌同學(xué)的問(wèn)題：
// 如果常量池還沒(méi)有解析，先進(jìn)行解析，即將常量池中的符號(hào)引用替換成直接引用，
//此時(shí)就會(huì)觸發(fā)Student.Class 的加載
if (METHOD->constants()->tag_at(index).is_unresolved_klass()) {
CALL_VM(InterpreterRuntime::quicken_io_cc(THREAD), handle_exception);
}
請(qǐng)問(wèn)，為何這里會(huì)重新加載Student.Class？jvm是不是有自己的class加載鏈路，然后系統(tǒng)循著鏈路去查找class是否已經(jīng)被加載？那該怎么把自定義的CustomClassloader 加到這個(gè)查詢鏈路中去呢？
第一種方法：設(shè)置啟動(dòng)參數(shù) java -Djava.system.class.loader
第二種方法：利用Thread.setContextClassLoder
這里就有點(diǎn)技巧了，看下代碼：
public class Test {public static void main(String[] args) throws Exception {URL url[] = new URL[1];url[0] = Thread.currentThread().getContextClassLoader().getResource("");final CustomClassloader customClassloader = new CustomClassloader(url);Thread.currentThread().setContextClassLoader(customClassloader);Class clazz = customClassloader.loadClass("com.wangxiandeng.ClassTest");Object object = clazz.newInstance();Method method = clazz.getDeclaredMethod("test");method.invoke(object);} } public class ClassTest {public void test() throws Exception{Class clazz = Thread.currentThread().getContextClassLoader().loadClass("com.wangxiandeng.Student");Student student = (Student) clazz.newInstance();System.out.print(student.getClass().getClassLoader());} }要注意的是在設(shè)置線程的ClassLoader后，并不是直接調(diào)用 new ClassTest().test()。為什么呢？因?yàn)橹苯訌?qiáng)引用的話，會(huì)在解析Test.Class的常量池時(shí)，利用系統(tǒng)默認(rèn)的ClassLoader加載了ClassTest，從而又觸發(fā)了ClassTest.Class的解析。為了避免這種情況的發(fā)生，這里利用CustomClassLoader去加載ClassTest.Class，再利用反射機(jī)制調(diào)用test（），此時(shí)在解析ClassTest.Class的常量池時(shí)，就會(huì)利用CustomClassLoader去加載Class常量池項(xiàng)，也就不會(huì)發(fā)生異常了。
四：總結(jié)
寫完這篇文章，手也不癢了，甚爽！這篇文章從雙親委派講到了Class文件的加載，最后又繞回到雙親委派，看似有點(diǎn)繞，其實(shí)只有理解了Class的加載機(jī)制，才能更好的理解類似雙親委派這樣的機(jī)制，否則只死記硬背一些空洞的理論，是無(wú)法起到由內(nèi)而外的理解的。
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的你知道 Java 类是如何被加载的吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 助力共享经济，芝麻信用背后的技术
- 下一篇： 混合云模式下 MaxCompute +