共计 4809 个字符，预计需要花费 13 分钟才能阅读完成。
类加载器的关系
类加载器的分类
- JVM 反对两品种加载器，一种为 疏导类加载器 （Bootstrap ClassLoader）, 另外一种是 自定义类加载器（User Defined ClassLoader）
- 疏导类加载器是由 C /C++ 编写的无法访问到
- Java 虚拟机规定：所有派生于抽象类 ClassLoader 的类加载器都划分为自定义加载器
- 最常见的类加载器只有三个（如上图所示）
用户自定义的类会被零碎类加载器所加载，外围类库的类会被疏导类加载器所加载
public class ClassLoaderTest {public static void main(String[] args) {
// 获取零碎类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader);//sun.misc.Launcher$AppClassLoader@18b4aac2
// 获取其下层：扩大类加载器
ClassLoader extClassLoader = systemClassLoader.getParent();
System.out.println(extClassLoader);//sun.misc.Launcher$ExtClassLoader@1540e19d
// 获取其下层：获取不到疏导类加载器
ClassLoader bootstrapClassLoader = extClassLoader.getParent();
System.out.println(bootstrapClassLoader);//null
// 对于用户自定义类来说：默认应用零碎类加载器进行加载
ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
System.out.println(classLoader);//sun.misc.Launcher$AppClassLoader@18b4aac2
//String 类应用疏导类加载器进行加载的。---> Java 的外围类库都是应用疏导类加载器进行加载的。ClassLoader classLoader1 = String.class.getClassLoader();
System.out.println(classLoader1);//null
}
}零碎自带的类加载器介绍
-
启动类加载器（疏导类加载器、Bootstrap ClassLoader）
- 由 c /c++ 语言实现的，嵌套在 jvm 外部
- 用来加载 java 外围库
- 并不继承 java.lang.ClassLoader，没有父加载器
- 为扩大类加载器和零碎类加载器的父加载器
- 只能加载 java、javax、sun 结尾的类
-
扩大类加载器（Extension ClassLoader）
- java 语言编写，sun.misc.Launche 包下。
- 派生于 ClassLoader 类，父类加载器为 Bootstrap ClassLoader
- 从 java.ext.dirs 零碎属性指定的目录中加载类库或者加载 jre/lib/ext 子目录下的类库（用户能够在该目录下编写 JAR，也会由此加载器所加载）
-
零碎类加载器（System ClassLoaderAppClassLoader）
- 派生于 ClassLoader，父类加载器为 Extension ClassLoader
- 负责加载 classpath 或者零碎属性 java.class.path 指定门路下的类库
- java 语言编写，sun.misc.Launche 包下。
- 负责加载程序中默认的类，能够通过 getSystemClassLoader()办法获取该类的加载器。
-
用户自定义类加载器（前面具体介绍）
- 隔离加载类
- 批改类加载的形式
- 扩大加载源
- 避免源码透露（能够对字节码文件加密）
- 继承 ClassLoader 类形式实现自定义类加载器
对于 ClassLoader
-
ClassLoader 是一个抽象类，其后的所有类加载器都继承此类
注：这些办法都不是形象办法。
获取 ClassLoader 的门路
public class ClassLoaderTest2 {public static void main(String[] args) {
try {
//1.
ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
System.out.println(classLoader);
//2.
ClassLoader classLoader1 = Thread.currentThread().getContextClassLoader();
System.out.println(classLoader1);
//3.
ClassLoader classLoader2 = ClassLoader.getSystemClassLoader().getParent();
System.out.println(classLoader2);
} catch (ClassNotFoundException e) {e.printStackTrace();
}
}
}双亲委派机制（面试）
- Java 虚拟机对 class 文件采纳的是 按需加载 的形式，当须要应用到这个类的时候才会对它的 class 文件加载到内存生成 class 对象，加载的过程中应用的 双亲委派模式，即把申请交给父类解决。
- 如果一个类加载器收到了类加载的申请，它不会本人加载，而是先把这个申请给本人的父类加载器去执行
- 如果这个父类加载器还有父类加载器，则会再将申请给本人的父类加载器，顺次递归到顶层的启动类加载器
- 顺次进行判断是否能实现委派（加载此类），若能实现委派则该类就由此加载器加载，若无奈实现委派，则将委托给子类加载器进行判断是否能实现委派，顺次递归到底层加载器，若期间被加载则实现加载阶段不会再递归（注）。
注：类只能被一个加载器所加载。-
双亲委派的劣势
-
- 防止类的反复加载
- 爱护程序的平安，避免外围 API 被篡改
-
例如：
- 创立一个 java.lang.String 类，因为有双亲委派的机制，所以会将 String 类交给疏导类加载器来判断是否能被加载。疏导加载器判断能够加载此类（是外围类中的 String），实现加载，则 ” 歹意 ” 写的 String 类无奈失效，避免 String 类被歹意篡改。这里也称沙箱平安机制（爱护 java 外围源代码）
package java.lang;
public class String {
//
static{System.out.println("我是自定义的 String 类的动态代码块");
}
// 谬误: 在类 java.lang.String 中找不到 main 办法
public static void main(String[] args) {System.out.println("hello,String");
}
}
// 因为加载的是外围类的 String，在 String 中找不到 main 办法
public class StringTest {public static void main(String[] args) {java.lang.String str = new java.lang.String();// 无输入
StringTest test = new StringTest();
System.out.println(test.getClass().getClassLoader());
}
}package java.lang;
public class ShkStart {
// 谬误：java.lang.SecurityException: Prohibited package name: java.lang
public static void main(String[] args) {System.out.println("hello!");
}
}
// 因为 java.lang 包由疏导类加载器加载，疏导类中并没有此类，为了平安疏导类
毁坏双亲委派模型：
较大规模的毁坏双亲委派模型的有 3 种：
- 因为双亲委派模型是在 JDK1.2 之后才引入的，所以在 JDK1.2 之前是不合乎双亲委派模型的：
- ClassLoader 这类在 JDK1.0 开始有存在的，在 JDK1.2 之前，ClassLoader 中是通过公有办法 loadClassInternal()去调用本人外部的 loadClass()。为了满足双亲委派以及向下兼容，在 JDK1.2 后的 ClassLoader 类中，又为该类增加了 protected 的 findClass()办法，JDK1.2 之后就不举荐通过笼罩重写 loadClass()办法了，而是在新增加的 findClass()办法中书写本人的类加载逻辑，若 loadClass()办法中的父类加载失败则会调用本人的 findClass()办法。
-
因为双亲委派模型的旨意是越外围的类越由高层的加载器所加载（上文提到过的 String 类），假使这些外围类要去调用用户的根底类，例如 JNDI 服务（是对 资源进行集中管理和查找，它须要调用由独立厂商实现并部署在应用程序的 ClassPath 下的 JNDI 接口提供者（SPI,Service Provider Interface）的代码，但启动类加载器不可能 ” 意识 ” 这些代码）
- 为了解决调用问题，设计了一个线程上下文类加载器（Thread Context ClassLoader），这个类加载器能够通过 java.lang.Thread 类的 setContextClassLoaser()办法进行设置，如果创立线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范畴内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
- 有了这个上下文类加载器，就能够去加载所须要的 SPI 代码，实际上就是从父类加载器去申请子类加载器去实现类的加载驱动，违反了双亲委派的一般性规定。Java 中所有波及 SPI 的加载动作基本上都采纳这种形式，例如 JNDI、JDBC、JCE、JAXB 和 JBI 等。
- 为了满足 ” 热部署 ”、” 动静部署 ” 等性能而导致的。在 OSGi（动静模块技术）环境下，类加载器不再是双亲委派模型中的树状构造，而是进一步倒退为更加简单的网状结构，当收到类加载申请时，OSGi 将依照程序进行类搜寻
对于类加载器的一些补充
##### 1. JVM 中判断一个类是否是同一个类有两个必要条件：
- 这两个类的全限定名要统一
- 这两个类被同一个类加载器加载。
2. 对类加载器的援用：
- JVM 必须晓得一个类型是由疏导类加载器（启动类加载器）加载的还是由用户类加载器加载的。
- 如果一个类是由用户类加载器所加载的，那么 JVM 会将这个类加载器的一个援用作为类信息的一部分保留在办法区。
-
当解析一个类型到另外一个类型的援用的时候，JVM 须要保障这两个类型的类加载器是雷同的。
3. 类的被动应用和被动应用
-
被动应用：
- 创立类的实例
- 拜访某个类或接口的动态变量，或者对该动态变量赋值
- 调用类的静态方法
-
反射
-
- 初始化一个类的子类
- JVM 启动时被表明为启动类的类
-
JDK 7 开始提供的动静代理：java.invoke.MethodHandle 实例的解析后果，REF_getStatic、REF_putStatic、REF_invokeStatic 句柄对应的类没有初始化、则初始化
- 除以上 7 种状况，其余应用 Java 类的形式都为被动应用，被动应用不会导致类的初始化。
-
最初
大家看完有什么不懂的能够在下方留言探讨，也能够关注我私信问我，我看到后都会答复的。也欢送大家关注我的公众号：前程有光，马上金九银十跳槽面试季，整顿了 1000 多道将近 500 多页 pdf 文档的 Java 面试题材料放在外面，助你圆梦 BAT！文章都会在外面更新，整顿的材料也会放在外面。谢谢你的观看，感觉文章对你有帮忙的话记得关注我点个赞反对一下！
正文完