类加载器原理
类加载器作用
将class文件字节码内容加载到内存中，并将这些静态数据转换成方法区中的运行时数据结构，在堆中生成一个代表这个类的java.lang.Class对象，作为方法区类数据的访问入口
类缓存
标准的Java SE类加载器可以按要求查找类，但一旦某个类被加载到类加载器中，他将维持加载（缓存）一段时间，不过，JVM垃圾收集器可以回收这些Class对象。
类加载器的层次结构（树状结构）
引导(启动)类加载器（Bootstrap Class Loader）
它用来加载Java的核心库(JAVA_HOME/jre/lib/rt.jar 或 sun.boot.class.path 路径下的内容），是用原生代码来实现的（C++）,并不继承自java.lang.ClassLoader
加载扩展类和应用程序类加载器，并指定他们的父类加载器。
扩展类加载器（Extensions Class Loader）
用来加载Java的扩展库(JAVA_HOME/jre/lib/ext/*.jar或 java.ext.dirs 路径下的内容) .java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。
由 sun.misc.Launcher$ExtClassLoader 实现
应用程序类加载器（Application Class Loader）
它根据 Java 应用的类路径（ClassPath, java.class.path）来加载。
一般来说，Java应用的类都是由它来完成加载的。
由 sun.misc.Launcher$AppClassLoader 实现
自定义类加载器
开发人员可以通过继承 java.lang.ClassLoader 类的方式实现自己的类加载器，以满足一些特殊的要求。
注意：除了启动类加载器是由 C++ 编写外，其他都是 Java 编写，且都继承java.lang.ClassLoader
代码测试
public class ClassLoaderTest {
public static void main(String[] args) {
System.out.println(ClassLoader.getSystemClassLoader());
System.out.println(ClassLoader.getSystemClassLoader().getParent());
System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());
}
}
输出结果
sun.misc.Launcher$AppClassLoader@73d16e93
sun.misc.Launcher$ExtClassLoader@15db9742
null
- $ 表示内部类。内部类是个编译时的概念，编译成功后会生成两个类
OuterClass.class和OuterClass$InnerClass.class- 由于启动类加载器无法被 Java 程序直接引用，因此 JVM 默认直接使用 null 代表启动类加载器。
java.lang.ClassLoader 类介绍
作用：
java.lang.ClassLoader 类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即java.lang.Class 类的一个实例。除此之外，ClassLoader 还负责加载 Java 应用所需的资源，如图像文件和配置文件等。不过本文只讨论其加载类的功能。
相关方法：
| 方法 | 解释 |
|---|---|
| getParent() | 返回该类加载器的父类加载器。 |
| loadClass(String name) | 加载名称为 name 的类，返回的结果是 java.lang.Class 类的实例。 |
| findClass(String name) | 查找名称为 name 的类，返回的结果是 java.lang.Class 类的实例。 |
| findLoadedClass(String name) | 查找名称为 name 的已经被加载过的类，返回的结果是 java.lang.Class 类的实例。 |
| defineClass(String name, byte[] b, int off, int len) | 把字节数组 b 中的内容转换成 Java 类，返回的结果是 java.lang.Class 类的实例。这个方法被声明为final 的。 |
| resolveClass(Class<?> c) | 链接指定的 Java 类。 |
类加载器的代理模式
代理模式
交给其他加载器来加载指定类。
双亲委托机制
就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归 (本质上就是loadClass函数的递归调用)。因此，所有的加载请求最终都应该传送到顶层的启动类加载器中。如果父类加载器可以完成这个类加载请求，就成功返回；只有当父类加载器无法完成此加载请求时，子加载器才会尝试自己去加载。
双亲委托机制是为了保证 Java 核心库的类型安全。这种机制就保证不会出现用户自己定义的 java.lang.Object 类的情况。
双亲委托机制除了用于加载类，也是安全的最基本屏障。
- 双亲委托机制是代理模式的一种
- 并不是所有的类加载器都是双亲委托机制
- tomcat 服务器类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类。这与一般类加载器的顺序是相反的。
双亲委派机制代码测试
- 测试一
package com.classloader.test;
public class TestBean {
public TestBean() {
}
}
package com.classloader.test;
public class ClassLoaderTest {
public static void main(String[] args) {
try {
//查看当前系统类路径中包含的路径条目
System.out.println(System.getProperty("java.class.path"));
//调用加载当前类的类加载器（这里即为系统类加载器）加载TestBean
Class typeLoaded = Class.forName("com.classloader.test.TestBean");
//查看被加载的TestBean类型是被那个类加载器加载的
System.out.println(typeLoaded.getClassLoader());
} catch (Exception e) {
e.printStackTrace();
}
}
}
输出
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\charsets.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\deploy.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\access-bridge-64.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\cldrdata.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\dnsns.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\jaccess.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\jfxrt.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\localedata.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\nashorn.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\sunec.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\sunjce_provider.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\sunmscapi.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\sunpkcs11.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\ext\zipfs.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\javaws.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\jce.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\jfr.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\jfxswt.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\jsse.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\management-agent.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\plugin.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\resources.jar;
d:\Develop\Java\jdk8\jdk1.8.0_92\jre\lib\rt.jar;
F:\workspace\idea\ClassLoader\out\production\ClassLoader;
D:\Develop\IntelliJ IDEA\lib\idea_rt.jar
sun.misc.Launcher$AppClassLoader@75b84c92
为了增加可读性，笔者对输出做了调整
- 测试二
将当前工程输出目录下的TestBean.class打包进test.jar剪贴到JAVA_HOME/jre/lib/ext目录下，再运行测试一测试代码
输出
...省略部分输出
sun.misc.Launcher$ExtClassLoader@53ab9242
系统类加载器在接到加载
com.classloader.test.TestBean类型的请求时，首先将请求委派给父类加载器（标准扩展类加载器），标准扩展类加载器抢先完成了加载请求。
相关参考
深入理解 Java 虚拟机
深入理解类加载器
