thread类_还敢随便说你知道Java类是如何被加载的吗？

作者：空念 | 来源：互联网 | 2023-10-12 19:59

码农每日一题长按关注，工作日每天分享一个技术知识点。转载自https:segmentfault.coma1190000019856086前言最近给一个非Java方向的

码农每日一题长按关注&＃xff0c;工作日每天分享一个技术知识点。

转载自 https://segmentfault.com/a/1190000019856086

前言

最近给一个非Java方向的朋友讲了下双亲委派模型&＃xff0c;朋友让我写篇文章深度研究下JVM的ClassLoader&＃xff0c;我确实也好久没写JVM相关的文章了&＃xff0c;有点手痒痒&＃xff0c;涂了皮炎平也抑制不住。

我在向朋友解释的时候是这么说的&＃xff1a;双亲委派模型中&＃xff0c;ClassLoader在加载类的时候&＃xff0c;会先交由它的父ClassLoader加载&＃xff0c;只有当父ClassLoader加载失败的情况下&＃xff0c;才会尝试自己去加载。这样可以实现部分类的复用&＃xff0c;又可以实现部分类的隔离&＃xff0c;因为不同ClassLoader加载的类是互相隔离的。

不过贸然的向别人解释双亲委派模型是不妥的&＃xff0c;如果在不了解JVM的类加载机制的情况下&＃xff0c;又如何能很好的理解“不同ClassLoader加载的类是互相隔离的”这句话呢&＃xff1f;所以为了理解双亲委派&＃xff0c;最好的方式&＃xff0c;就是先了解下ClassLoader的加载流程。

Java 类是如何被加载的

何时加载类我们首先要清楚的是&＃xff0c;Java类何时会被加载&＃xff1f;

《深入理解Java虚拟机》给出的答案是&＃xff1a;

遇到new、getstatic、putstatic 等指令时。
对类进行反射调用的时候。
初始化某个类的子类的时候。
虚拟机启动时会先加载设置的程序主类。
使用JDK 1.7 的动态语言支持的时候。

其实要我说&＃xff0c;最通俗易懂的答案就是&＃xff1a;当运行过程中需要这个类的时候。那么我们不妨就从如何加载类开始说起。怎么加载类

利用ClassLoader加载类很简单&＃xff0c;直接调用ClassLoder的loadClass()方法即可&＃xff0c;我相信大家都会&＃xff0c;但是还是要举个栗子&＃xff1a;

public class Test { public static void main(String[] args) throws ClassNotFoundException { Test.class.getClassLoader().loadClass("com.wangxiandeng.test.Dog"); } }

上面这段代码便实现了让ClassLoader去加载 “com.wangxiandeng.test.Dog” 这个类&＃xff0c;是不是 so easy。但是JDK 提供的 API 只是冰山一角&＃xff0c;看似很简单的一个调用&＃xff0c;其实隐藏了非常多的细节&＃xff0c;我这个人吧&＃xff0c;最喜欢做的就是去揭开 API 的封装&＃xff0c;一探究竟。

JVM 是怎么加载类的

JVM 默认用于加载用户程序的ClassLoader为AppClassLoader&＃xff0c;不过无论是什么ClassLoader&＃xff0c;它的根父类都是java.lang.ClassLoader。在上面那个例子中&＃xff0c;loadClass()方法最终会调用到ClassLoader.definClass1()中&＃xff0c;这是一个 Native 方法。

static native Class> defineClass1(ClassLoader loader, String name, byte[] b, int off, int len, ProtectionDomain pd, String source);

看到 Native 方法莫心慌&＃xff0c;不要急&＃xff0c;打开OpenJDK源码&＃xff0c;我等继续走马观花便是&＃xff01;

definClass1()对应的 JNI 方法为 Java_java_lang_ClassLoader_defineClass1()&＃xff1a;

JNIEXPORT jclass JNICALLJava_java_lang_ClassLoader_defineClass1(JNIEnv *env, jclass cls, jobject loader, jstring name, jbyteArray data, jint offset, jint length, jobject pd, jstring source){ ...... result &＃61; JVM_DefineClassWithSource(env, utfName, loader, body, length, pd, utfSource); ...... return result; }

Java_java_lang_ClassLoader_defineClass1 主要是调用了JVM_DefineClassWithSource()加载类&＃xff0c;跟着源码往下走&＃xff0c;会发现最终调用的是 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 &＃61; SystemDictionary::resolve_from_stream(class_name, class_loader, protection_domain, &st, CHECK_NULL); ...... return (jclass) JNIHandles::make_local(env, k->java_mirror()); }

上面这段逻辑主要就是利用 ClassFileStream 将要加载的class文件转成文件流&＃xff0c;然后调用SystemDictionary::resolve_from_stream()&＃xff0c;生成 Class 在 JVM 中的代表&＃xff1a;Klass。对于Klass&＃xff0c;大家可能不太熟悉&＃xff0c;但是在这里必须得了解下。说白了&＃xff0c;它就是JVM 用来定义一个Java Class 的数据结构。不过Klass只是一个基类&＃xff0c;Java Class 真正的数据结构定义在 InstanceKlass中。

class InstanceKlass: public Klass { protected: Annotations* _annotations; ...... ConstantPool* _constants; ...... Array* _inner_classes; ...... Array* _methods; Array* _default_methods; ...... Array* _fields; }

可见 InstanceKlass 中记录了一个 Java 类的所有属性&＃xff0c;包括注解、方法、字段、内部类、常量池等信息。这些信息本来被记录在Class文件中&＃xff0c;所以说&＃xff0c;InstanceKlass就是一个Java Class 文件被加载到内存后的形式。

再回到上面的类加载流程中&＃xff0c;这里调用了 SystemDictionary::resolve_from_stream()&＃xff0c;将 Class 文件加载成内存中的 Klass。

resolve_from_stream() 便是重中之重&＃xff01;主要逻辑有下面几步&＃xff1a;1&＃xff1a;判断是否允许并行加载类&＃xff0c;并根据判断结果进行加锁。

bool DoObjectLock &＃61; true; if (is_parallelCapable(class_loader)) { DoObjectLock &＃61; false; } ClassLoaderData* loader_data &＃61; register_loader(class_loader, CHECK_NULL); Handle lockObject &＃61; compute_loader_lock_object(class_loader, THREAD); check_loader_lock_contention(lockObject, THREAD); ObjectLocker ol(lockObject, THREAD, DoObjectLock);

如果允许并行加载&＃xff0c;则不会对ClassLoader进行加锁&＃xff0c;只对SystemDictionary加锁。否则&＃xff0c;便会利用 ObjectLocker 对ClassLoader 加锁&＃xff0c;保证同一个ClassLoader在同一时刻只能加载一个类。ObjectLocker 会在其构造函数中获取锁&＃xff0c;并在析构函数中释放锁。

允许并行加载的好处便是精细化了锁粒度&＃xff0c;这样可以在同一时刻加载多个Class文件。

2&＃xff1a;解析文件流&＃xff0c;生成 InstanceKlass。

InstanceKlass* k &＃61; NULL; k &＃61; KlassFactory::create_from_stream(st, class_name, loader_data, protection_domain, NULL, // host_klass NULL, // cp_patches CHECK_NULL);3&＃xff1a;利用SystemDictionary注册生成的 Klass。

SystemDictionary 是用来帮助保存 ClassLoader 加载过的类信息的。准确点说&＃xff0c;SystemDictionary并不是一个容器&＃xff0c;真正用来保存类信息的容器是 Dictionary&＃xff0c;每个ClassLoaderData 中都保存着一个私有的 Dictionary&＃xff0c;而 SystemDictionary 只是一个拥有很多静态方法的工具类而已。我们来看看注册的代码&＃xff1a;

if (is_parallelCapable(class_loader)) { InstanceKlass* defined_k &＃61; find_or_define_instance_class(h_name, class_loader, k, THREAD); if (!HAS_PENDING_EXCEPTION && defined_k !&＃61; k) { // If a parallel capable class loader already defined this class, register &＃39;k&＃39; for cleanup. assert(defined_k !&＃61; NULL, "Should have a klass if there&＃39;s no exception"); loader_data->add_to_deallocate_list(k); k &＃61; defined_k; } } else { define_instance_class(k, THREAD); }

如果允许并行加载&＃xff0c;那么前面就不会对ClassLoader加锁&＃xff0c;所以在同一时刻&＃xff0c;可能对同一Class文件加载了多次。但是同一Class在同一ClassLoader中必须保持唯一性&＃xff0c;所以这里会先利用 SystemDictionary 查询 ClassLoader 是否已经加载过相同 Class。

如果已经加载过&＃xff0c;那么就将当前线程刚刚加载的InstanceKlass加入待回收列表&＃xff0c;并将 InstanceKlass* k 重新指向利用SystemDictionary查询到的 InstanceKlass。

如果没有查询到&＃xff0c;那么就将刚刚加载的 InstanceKlass 注册到 ClassLoader的 Dictionary 中中。

虽然并行加载不会锁住ClassLoader&＃xff0c;但是会在注册 InstanceKlass 时对 SystemDictionary 加锁&＃xff0c;所以不需要担心InstanceKlass 在注册时的并发操作。

如果禁止了并行加载&＃xff0c;那么直接利用SystemDictionary将 InstanceKlass 注册到 ClassLoader的 Dictionary 中即可。

resolve_from_stream()的主要流程就是上面三步&＃xff0c;很明显&＃xff0c;最重要的是第二步&＃xff0c;从文件流生成InstanceKlass。

生成InstanceKlass 调用的是 KlassFactory::create_from_stream() 方法&＃xff0c;它的主要逻辑就是下面这段代码。

ClassFileParser parser(stream, name, loader_data, protection_domain, host_klass, cp_patches, ClassFileParser::BROADCAST, // publicity level CHECK_NULL); InstanceKlass* result &＃61; parser.create_instance_klass(old_stream !&＃61; stream, CHECK_NULL);

原来 ClassFileParser 才是真正的主角啊&＃xff01;它才是将Class文件升华成InstanceKlass的幕后大佬&＃xff01;

不得不说的ClassFileParser

ClassFileParser 加载Class文件的入口便是 create_instance_klass()。顾名思义&＃xff0c;用来创建InstanceKlass的。

create_instance_klass()主要就干了两件事&＃xff1a;

(1)&＃xff1a;为 InstanceKlass 分配内存。

InstanceKlass* const ik &＃61; InstanceKlass::allocate_instance_klass(*this, CHECK_NULL);(2)&＃xff1a;分析Class文件&＃xff0c;填充 InstanceKlass 内存区域。fill_instance_klass(ik, changed_by_loadhook, CHECK_NULL);我们先来说道说道第一件事&＃xff0c;为 InstanceKlass 分配内存。内存分配代码如下&＃xff1a;

const int size &＃61; 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 &＃61; parser.loader_data(); InstanceKlass* ik; ik &＃61; new (loader_data, size, THREAD) InstanceKlass(parser, InstanceKlass::_misc_kind_other);这里首先计算了 InstanceKlass 在内存中的大小&＃xff0c;要知道&＃xff0c;这个大小在 Class 文件编译后就被确定了。然后便 new 了一个新的 InstanceKlass 对象。这里并不是简单的在堆上分配内存&＃xff0c;要注意的是Klass 对 new 操作符进行了重载&＃xff1a;

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 的时候调用了 Metaspace::allocate()&＃xff1a;

MetaspaceObj::Type type, TRAPS) { ...... MetadataType mdtype &＃61; (type &＃61;&＃61; MetaspaceObj::ClassType) ? ClassType : NonClassType; ...... MetaWord* result &＃61; loader_data->metaspace_non_null()->allocate(word_size, mdtype); ...... return result; }

由此可见&＃xff0c;InstanceKlass 是分配在 ClassLoader的 Metaspace(元空间) 的方法区中。从 JDK8 开始&＃xff0c;HotSpot 就没有了永久代&＃xff0c;类都分配在 Metaspace 中。Metaspace 和永久代不一样&＃xff0c;采用的是 Native Memory&＃xff0c;永久代由于受限于 MaxPermSize&＃xff0c;所以当内存不够时会内存溢出。

分配完 InstanceKlass 内存后&＃xff0c;便要着手第二件事&＃xff0c;分析Class文件&＃xff0c;填充 InstanceKlass 内存区域。

ClassFileParser 在构造的时候就会开始分析Class文件&＃xff0c;所以fill_instance_klass()中只需要填充即可。填充结束后&＃xff0c;还会调用 java_lang_Class::create_mirror()创建 InstanceKlass 在Java 层的 Class 对象。

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); }

到这儿&＃xff0c;Class 文件已经完成了华丽的转身&＃xff0c;由冷冰冰的二进制文件&＃xff0c;变成了内存中充满生命力的 InstanceKlass。

再谈双亲委派

如果你耐心的看完了上面的源码分析&＃xff0c;你一定对 “不同 ClassLoader 加载的类是互相隔离的” 这句话的理解又上了一个台阶。

我们总结下&＃xff1a;每个 ClassLoader 都有一个 Dictionary 用来保存它所加载的 InstanceKlass 信息。并且&＃xff0c;每个 ClassLoader 通过锁&＃xff0c;保证了对于同一个 Class&＃xff0c;它只会注册一份 InstanceKlass 到自己的 Dictionary 。

正式由于上面这些原因&＃xff0c;如果所有的 ClassLoader 都由自己去加载 Class 文件&＃xff0c;就会导致对于同一个 Class 文件&＃xff0c;存在多份 InstanceKlass&＃xff0c;所以即使是同一个 Class 文件&＃xff0c;不同 InstanceKlasss 衍生出来的实例类型也是不一样的。

举个栗子&＃xff0c;我们自定义一个 ClassLoader&＃xff0c;用来打破双亲委派模型&＃xff1a;

public class CustomClassloader extends URLClassLoader { public CustomClassloader(URL[] urls) { super(urls); } &＃64;Override protected Class> loadClass(String name, boolean resolve) throws ClassNotFoundException { if (name.startsWith("com.wangxiandeng")) { return findClass(name); } return super.loadClass(name, resolve); } }再尝试加载 Student 类&＃xff0c;并实例化&＃xff1a;

Exception in thread "main" java.lang.ClassCastException: com.wangxiandeng.Student cannot be cast to com.wangxiandeng.Student为什么呢&＃xff1f;

因为实例化的 Student 对象所属的 InstanceKlass 是由 CustomClassLoader 加载生成的&＃xff0c;而我们要强转的类型 Student.Class 对应的 InstanceKlass 是由系统默认的 ClassLoader 生成的&＃xff0c;所以本质上它们就是两个毫无关联的 InstanceKlass&＃xff0c;当然不能强转。

有同学问到&＃xff1a;为什么“强转的类型 Student.Class 对应的 InstanceKlass 是由系统默认的 ClassLoader 生成的”&＃xff1f;其实很简单&＃xff0c;我们反编译下字节码&＃xff1a;

public static void main(java.lang.String[]) throws java.lang.Exception; descriptor: ([Ljava/lang/String;)V flags: ACC_PUBLIC, ACC_STATIC Code: stack&＃61;4, locals&＃61;5, args_size&＃61;1 0: iconst_1 1: anewarray #2 // class java/net/URL 4: astore_1 5: aload_1 6: iconst_0 7: invokestatic #3 // Method java/lang/Thread.currentThread:()Ljava/lang/Thread; 10: invokevirtual #4 // Method java/lang/Thread.getContextClassLoader:()Ljava/lang/ClassLoader; 13: ldc #5 // String 15: invokevirtual #6 // Method java/lang/ClassLoader.getResource:(Ljava/lang/String;)Ljava/net/URL; 18: aastore 19: new #7 // class com/wangxiandeng/classloader/CustomClassloader 22: dup 23: aload_1 24: invokespecial #8 // Method com/wangxiandeng/classloader/CustomClassloader."":([Ljava/net/URL;)V 27: astore_2 28: aload_2 29: ldc #9 // String com.wangxiandeng.Student 31: invokevirtual #10 // Method com/wangxiandeng/classloader/CustomClassloader.loadClass:(Ljava/lang/String;)Ljava/lang/Class; 34: astore_3 35: aload_3 36: invokevirtual #11 // Method java/lang/Class.newInstance:()Ljava/lang/Object; 39: checkcast #12 // class com/wangxiandeng/Student 42: astore 4 44: return

可以看到在利用加载的Class初始化实例后&＃xff0c;调用了 checkcast 进行类型转化&＃xff0c;checkcast 后的操作数 #12 即为Student这个类在常量池中的索引&＃xff1a;#12 &＃61; Class #52 // com/wangxiandeng/Student。

下面我们可以看看 checkcast 在 HotSpot 中的实现。

HotSpot 目前有三种字节码执行引擎&＃xff0c;目前采用的是模板解释器&＃xff0c;早期的 HotSpot 采用的是字节码解释器。模板解释器对于指令的执行都是用汇编写的&＃xff0c;而字节码解释器采用的C&＃43;&＃43;进行的翻译&＃xff0c;为了看起来比较舒服&＃xff0c;我们就不看汇编了&＃xff0c;直接看字节码解释器就行了。如果你的汇编功底很好&＃xff0c;当然也可以直接看模板解释器。

废话不多说&＃xff0c;我们来看看字节码解释器对于checkcast的实现&＃xff0c;代码在 bytecodeInterpreter.cpp 中&＃xff1a;

CASE(_checkcast): if (STACK_OBJECT(-1) !&＃61; NULL) { VERIFY_OOP(STACK_OBJECT(-1)); // 拿到 checkcast 指令后的操作数&＃xff0c;本例子中即 Student.Class 在常量池中的索引&＃xff1a;#12 u2 index &＃61; Bytes::get_Java_u2(pc&＃43;1); // 如果常量池还没有解析&＃xff0c;先进行解析&＃xff0c;即将常量池中的符号引用替换成直接引用&＃xff0c; //此时就会触发Student.Class 的加载 if (METHOD->constants()->tag_at(index).is_unresolved_klass()) { CALL_VM(InterpreterRuntime::quicken_io_cc(THREAD), handle_exception); } // 获取上一步系统加载的Student.Class 对应的 InstanceKlass Klass* klassOf &＃61; (Klass*) METHOD->constants()->resolved_klass_at(index); // 获取要强转的对象的实际类型&＃xff0c;即我们自己手动加载的Student.Class 对应的 InstanceKlass Klass* objKlass &＃61; STACK_OBJECT(-1)->klass(); // ebx // 现在就比较简单了&＃xff0c;直接看看上面的两个InstanceKlass指针内容是否相同 // 不同的情况下则判断是否存在继承关系 if (objKlass !&＃61; klassOf && !objKlass->is_subtype_of(klassOf)) { // Decrement counter at checkcast. BI_PROFILE_SUBTYPECHECK_FAILED(objKlass); ResourceMark rm(THREAD); char* message &＃61; 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&＃61;*/false, objKlass); } else { // Profile checkcast with null_seen and receiver. BI_PROFILE_UPDATE_CHECKCAST(/*null_seen&＃61;*/true, NULL); }

通过对上面代码的分析&＃xff0c;我相信大家已经理解了 “强转的类型 Student.Class 对应的 InstanceKlass 是由系统默认的 ClassLoader 生成的” 这句话了。

双亲委派的好处是尽量保证了同一个 Class 文件只会生成一个 InstanceKlass&＃xff0c;但是某些情况&＃xff0c;我们就不得不去打破双亲委派了&＃xff0c;比如我们想实现 Class 隔离的时候。

回复下箫陌同学的问题&＃xff1a;

// 如果常量池还没有解析&＃xff0c;先进行解析&＃xff0c;即将常量池中的符号引用替换成直接引用&＃xff0c; //此时就会触发Student.Class 的加载 if (METHOD->constants()->tag_at(index).is_unresolved_klass()) { CALL_VM(InterpreterRuntime::quicken_io_cc(THREAD), handle_exception); }

请问&＃xff0c;为何这里会重新加载 Student.Class&＃xff1f;jvm 是不是有自己的 class 加载链路&＃xff0c;然后系统循着链路去查找 class 是否已经被加载&＃xff1f;那该怎么把自定义的 CustomClassloader 加到这个查询链路中去呢&＃xff1f;

第一种方法&＃xff1a;设置启动参数 java -Djava.system.class.loader第二种方法&＃xff1a;利用Thread.setContextClassLoder这里就有点技巧了&＃xff0c;看下代码&＃xff1a;

public class Test { public static void main(String[] args) throws Exception { URL url[] &＃61; new URL[1]; url[0] &＃61; Thread.currentThread().getContextClassLoader().getResource(""); final CustomClassloader customClassloader &＃61; new CustomClassloader(url); Thread.currentThread().setContextClassLoader(customClassloader); Class clazz &＃61; customClassloader.loadClass("com.wangxiandeng.ClassTest"); Object object &＃61; clazz.newInstance(); Method method &＃61; clazz.getDeclaredMethod("test"); method.invoke(object); } } public class ClassTest { public void test() throws Exception{ Class clazz &＃61; Thread.currentThread().getContextClassLoader().loadClass("com.wangxiandeng.Student"); Student student &＃61; (Student) clazz.newInstance(); System.out.print(student.getClass().getClassLoader()); } }

要注意的是在设置线程的ClassLoader后&＃xff0c;并不是直接调用 new ClassTest().test()。为什么呢&＃xff1f;因为直接强引用的话&＃xff0c;会在解析 Test.Class 的常量池时&＃xff0c;利用系统默认的 ClassLoader 加载了 ClassTest&＃xff0c;从而又触发了 ClassTest.Class 的解析。为了避免这种情况的发生&＃xff0c;这里利用 CustomClassLoader 去加载 ClassTest.Class&＃xff0c;再利用反射机制调用test()&＃xff0c;此时在解析 ClassTest.Class 的常量池时&＃xff0c;就会利用 CustomClassLoader 去加载 Class 常量池项&＃xff0c;也就不会发生异常了。

总结

写完这篇文章&＃xff0c;手也不痒了&＃xff0c;甚爽&＃xff01;这篇文章从双亲委派讲到了 Class 文件的加载&＃xff0c;最后又绕回到双亲委派&＃xff0c;看似有点绕&＃xff0c;其实只有理解了 Class 的加载机制&＃xff0c;才能更好的理解类似双亲委派这样的机制&＃xff0c;否则只死记硬背一些空洞的理论&＃xff0c;是无法起到由内而外的理解的。