关于java:JVM知识总结10类加载器

6次阅读

共计 1394 个字符，预计需要花费 4 分钟才能阅读完成。

【JVM 常识总结 -1】JVM 内存模型
【JVM 常识总结 -2】HotSpot 虚拟机对象
【JVM 常识总结 -3】垃圾收集策略与算法
【JVM 常识总结 -4】HotSpot 垃圾收集器
【JVM 常识总结 -5】内存调配与回收策略
【JVM 常识总结 -6】JVM 性能调优
【JVM 常识总结 -7】类的文件构造
【JVM 常识总结 -8】类的加载机会
【JVM 常识总结 -9】类加载的过程
【JVM 常识总结 -10】类加载器

任意一个类，都是加载它的类加载器和这个类自身一起确立其在 Java 虚拟机中的唯一性，每一个类加载器，都有一个独立的类名称空间。
因而，比拟两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即便这两个类来源于同一个 Class 文件，被同一个虚拟机加载，只有加载它们的类加载器不同，那么这两个类就必然不相等。
这里的“相等”，包含代表类 Class 对象的 equals() 办法，isInstance()办法的返回后果，也包含应用 instanceof 关键字做对象所属关系断定等状况。

零碎提供了 3 中类加载器：

启动类加载器（Bootstrap ClassLoader）：负责将寄存在 <JAVA_HOME>\lib 目录中的，并且能被虚拟机辨认的（仅依照文件名辨认，如 rt.jar，名字不合乎的类库即便放在 lib 目录中也不会被加载）类库加载到虚拟机内存中。
扩大类加载器（Extension ClassLoader）：负责加载 <JAVA_HOME>\lib\ext 目录中的所有类库，开发者能够间接应用扩大类加载器。
应用程序类加载器（Application ClassLoader）：因为这个类加载器是 ClassLoader 中的 getSystemClassLoader() 办法的返回值，所以个别也称它为“零碎类加载器”。它负责加载用户类门路（classpath）上所指定的类库，开发者能够间接应用这个类加载器，如果应用程序中没有自定义过本人的类加载器，个别状况下这个就是程序中默认的类加载器。

当然，如有必要，还是能够退出本人定义的类加载器。

双亲委派模型是形容类加载器之间的档次关系。它要求除了顶层的启动类加载器外，其余的类加载器必须有本人的父类加载器。（父子关系个别以继承的形式实现，而是以组合关系来复用父加载器的代码）

如果一个类加载器收到了类加载的申请，它首先不会本人去尝试加载这个类，而是把这个申请委派给父类加载器去实现，每一个档次的类加载器都是如此，因而所有的加载申请都应该传送到顶层的启动类加载器中，只有当父类加载器反馈本人无奈实现这个类加载申请（如：找不到须要的类）时，子加载器才会尝试本人去加载。
在 java.lang.ClassLoader 中的 loadClass 办法中实现该过程。

像 java.lang.Object 这些寄存在 rt.jar 中的类，无论应用哪个类加载器加载，最终都会委派给最顶端的启动类加载器加载，从而使得不同加载器加载的 Object 类都是同一个。
相同，如果没有应用双亲委派机制模型，由各个类加载器自行去加载的话，如果用户本人编写了一个称为 java.lang.Object 的类，并放在 classpath 下，那么零碎就会呈现多个不同的 Object 类，Java 类型体系中最根底的行为也就无奈保障。

正文完