深入理解ClassLoader工作机制（jdk1.8）

Posted 2020-11-27 cxxiao

ClassLoader 顾名思义就是类加载器,ClassLoader 作用：

负责将 Class 加载到 JVM 中
审查每个类由谁加载（父优先的等级加载机制）
将 Class 字节码重新解析成 JVM 统一要求的对象格式
类加载时机与过程
类从被加载到虚拟机内存中开始，直到卸载出内存为止，它的整个生命周期包括了：加载、验证、准备、解析、初始化、使用和卸载这7个阶段。其中，验证、准备和解析这三个部分统称为连接（linking）。

其中，加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班的“开始”（仅仅指的是开始，而非执行或者结束，因为这些阶段通常都是互相交叉的混合进行，通常会在一个阶段执行的过程中调用或者激活另一个阶段），而解析阶段则不一定（它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定。

什么情况下需要开始类加载过程的第一个阶段:”加载”。虚拟机规范中并没强行约束，这点可以交给虚拟机的的具体实现自由把握，但是对于初始化阶段虚拟机规范是严格规定了如下几种情况，如果类未初始化会对类进行初始化：

创建类的实例
对类进行反射调用的时候，如果累没有进行过初始化，则需要先触发其初始化
当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化
当虚拟机启动时，用户需要指定一个要执行的主类（包含main 方法的那个类）,虚拟机会先初始化这个主类
当使用jdk1.7动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic,REF_putstatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出触发其初始化。
注意，对于这五种会触发类进行初始化的场景，虚拟机规范中使用了一个很强烈的限定语：“有且只有”，这五种场景中的行为称为对一个类进行 主动引用。除此之外，所有引用类的方式，都不会触发初始化，称为 被动引用。

特别需要指出的是，类的实例化与类的初始化是两个完全不同的概念：

类的实例化是指创建一个类的实例(对象)的过程；
类的初始化是指为类中各个类成员(被static修饰的成员变量)赋初始值的过程，是类生命周期中的一个阶段。

下面是被动引用的几个例子:
（1）

/**
* jdk:1.8
* 通过子类引用父类的静态字段,不会导致子类初始化
*/
class SuperClass{

static {
System.out.println("SuperClass init!");
}
public static int value=123;

}
class SubClass extends SuperClass{

static {
System.out.println("SubClass init!");
}

}

public class Test {
public static void main(String[] args)throws Exception{
System.out.println(SubClass.value); 
//输出:
//SuperClass init!
//123

}
}

 

通过其子类来引用父类中定义的静态字段，只会触发父类初始化而不会触发子类的初始化。至于是否要触发子类的加载和验证，这个在虚拟机规范中并没有明确规定，这点取决于虚拟机的具体实现。

（2）

/**
* jdk：1.8
* 通过数组定义来引用类，不会触发此类的初始化
*/
class SuperClass{

static {
System.out.println("SuperClass init!");
}
public static int value=123;

}
class SubClass extends SuperClass{

static {
System.out.println("SubClass init!");
}

}

 

public class Test {

public static void main(String[] args)throws Exception{
SuperClass[] sca=new SuperClass[10];
//无输出
}
}

通过数组定义来引用类，不会触发此类的初始化。

（3）

/**
* jdk:1.8
* 常量在编译阶段会存入调用类的常量池，
* 本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化
*/
class ConstClass{
static {
System.out.println("ConstClass init!");
}
public static final String HELLO = "hello";

}

public class Test {
public static void main(String[] args)throws Exception{
System.out.println(ConstClass.HELLO);
//输出 hello
}
}

 

常量在编译阶段会存入调用类的常量池，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化

ClassLoader 类结构分析
public abstract class ClassLoader {

// The parent class loader for delegation
// Note: VM hardcoded the offset of this field, thus all new fields
// must be added *after* it.
private final ClassLoader parent;

//...
}

这里注意下有父加载器，这个我们再后面再来阐述，这里先有个印象。

以下是 ClassLoader 常用到的几个方法及其重载方法：
（1）

defineClass(String name, java.nio.ByteBuffer b,ProtectionDomain protectionDomain)
1
指定保护域（protectionDomain），把ByteBuffer的内容转换成 Java 类，这个方法被声明为final的。

（2）

defineClass(String name, byte[] b, int off, int len)

把字节数组 b中的内容转换成 Java 类，其开始偏移为off,这个方法被声明为final的。

（3）

//查找指定名称的类
findClass(String name)

（4）

//加载指定名称的类
loadClass(String name)

（5）

//链接指定的类
resolveClass(Class<?>)

其中 defineClass 方法用来将 字节流解析成 JVM 能够识别的 Class 对象，有了这个方法意味着我们不仅仅可以通过 class 文件实例化对象，还可以通过其他方式实例化对象，如果我们通过网络接收到一个类的字节码，拿到这个字节码流直接创建类的 Class 对象形式实例化对象。如果直接调用这个方法生成类的 Class 对象，这个类的 Class 对象还没有 resolve ，这个 resolve 将会在这个对象真正实例化时才进行。

defineClass 通常是和findClass 方法一起使用的，我们通过覆盖ClassLoader父类的findClass 方法来实现类的加载规则，从而取得要加载类的字节码，然后调用defineClass方法生成类的Class 对象，如果你想在类被加载到JVM中时就被链接，那么可以接着调用另一个 resolveClass 方法，当然你也可以选择让JVM来解决什么时候才链接这个类。

ClassLoader 的等级加载机制
Java默认提供的三个ClassLoader

BootStrap ClassLoader
称为启动类加载器，是Java类加载层次中最顶层的类加载器，负责加载JDK中的核心类库，如：rt.jar、resources.jar、charsets.jar等，这个ClassLoader完全是JVM自己控制的，需要加载哪个类，怎么加载都是由JVM自己控制，别人也访问不到这个类，所以BootStrap ClassLoader不遵循委托机制(后面再阐述什么是委托机制)，没有子加载器。

下面是测试 BootStrap ClassLoader 加载的哪些文件：

/**
* BootStrap ClassLoader 加载的文件
*/
public class Test {
public static void main(String[] args)throws Exception{
System.out.println(System.getProperty("sun.boot.class.path"));
}
}

 

输出：

C:Program FilesJavajre1.8.0_151lib esources.jar;
C:Program FilesJavajre1.8.0_151lib t.jar;
C:Program FilesJavajre1.8.0_151libsunrsasign.jar;
C:Program FilesJavajre1.8.0_151libjsse.jar;
C:Program FilesJavajre1.8.0_151libjce.jar;
C:Program FilesJavajre1.8.0_151libcharsets.jar;
C:Program FilesJavajre1.8.0_151libjfr.jar;
C:Program FilesJavajre1.8.0_151classes

EtxClassLoader
称为扩展类加载器，负责加载Java的扩展类库，Java 虚拟机的实现会提供一个扩展库目录，该类加载器在此目录里面查找并加载 Java 类。默认加载JAVA_HOME/jre/lib/ext/目下的所有jar。

/**
* EtxClassLoader 加载文件
*/

public class Test {
public static void main(String[] args)throws Exception{
System.out.println(System.getProperty("java.ext.dirs"));
}
}

 

输出：

C:Program FilesJavajre1.8.0_91libext;
1
AppClassLoader
称为系统类加载器，负责加载应用程序classpath目录下的所有jar和class文件。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它。我们可以通过System.getProperty(“java.class.path”) 来查看 classpath。

除了引导类加载器（BootStrap ClassLoader）之外，所有的类加载器都有一个父类加载器，对于系统提供的类加载器来说，系统类加载器(如：AppClassLoader)的父类加载器是扩展类加载器（EtxClassLoader），而扩展类加载器的父类加载器是引导类加载器；对于开发人员编写的类加载器来说，其父类加载器是加载此类加载器 Java 类的类加载器。因为类加载器 Java 类如同其它的 Java 类一样，也是要由类加载器来加载的。一般来说，开发人员编写的类加载器的父类加载器是系统类加载器。类加载器通过这种方式组织起来，形成树状结构。树的根节点就是引导类加载器。

ClassLoader加载类的原理
ClassLoader使用的是双亲委托模型来搜索加载类的

双亲委托模型
ClassLoader使用的是双亲委托机制来搜索加载类的，每个ClassLoader实例都有一个父类加载器的引用（不是继承的关系，是一个组合的关系），虚拟机内置的类加载器（Bootstrap ClassLoader）本身没有父类加载器，但可以用作其它ClassLoader实例的的父类加载器。当一个ClassLoader实例需要加载某个类时，它会试图亲自搜索某个类之前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，如果没加载到，则把任务转交给Extension ClassLoader试图加载，如果也没加载到，则转交给App ClassLoader 进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。如果它们都没有加载到这个类时，则抛出ClassNotFoundException异常。否则将这个找到的类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象。

类加载器双亲委托模型：

双亲委托模型好处
因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要 ClassLoader再加载一次。考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时就被引导类加载器（Bootstrcp ClassLoader）加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变JDK中ClassLoader搜索类的默认算法。

类与类加载器
类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达更通俗一些：比较两个类是否”相等”，只有再这两个类是有同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class 文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

类加载器源码分析
Launcher

public Launcher() {
ExtClassLoader localExtClassLoader;
try {
// 扩展类加载器
localExtClassLoader = ExtClassLoader.getExtClassLoader();
} catch (IOException localIOException1) {
throw new InternalError("Could not create extension class loader", localIOException1);
}
try {
// 应用类加载器
this.loader = AppClassLoader.getAppClassLoader(localExtClassLoader);
} catch (IOException localIOException2) {
throw new InternalError("Could not create application class loader", localIOException2);
}
// 设置AppClassLoader为线程上下文类加载器
Thread.currentThread().setContextClassLoader(this.loader);
// ...

static class ExtClassLoader extends java.net.URLClassLoader
static class AppClassLoader extends java.net.URLClassLoader
}

 

Launcher初始化了ExtClassLoader和AppClassLoader，并将AppClassLoader设置为线程上下文类加载器。
ExtClassLoader和AppClassLoader都继承自URLClassLoader，而最终的父类则为ClassLoader,看看它们的类层次：

 

初始化AppClassLoader时传入了ExtClassLoader实例，当我们进入源码跟踪，会来到URLClassLoader 中

public URLClassLoader(URL[] urls, ClassLoader parent,
URLStreamHandlerFactory factory) {
super(parent);
// this is to make the stack depth consistent with 1.1
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkCreateClassLoader();
}
ucp = new URLClassPath(urls, factory);
acc = AccessController.getContext();
}

 

可以得知，这个ExtClassLoader 作为了AppClassLoader 的parent，在前面ClassLoader 源码中，我们知道有个parent 字段，这里就是在初始化这个字段。

双亲委派
要理解双亲委派，可以查看ClassLoader.loadClass方法:

 1 protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
 2 synchronized (getClassLoadingLock(name)) {
 3 // 检查是否已经加载过
 4 Class<?> c = findLoadedClass(name);
 5 if (c == null) { // 没有被加载过
 6 long t0 = System.nanoTime();
 7 // 先委派给父类加载器加载
 8 try {
 9 if (parent != null) {
10 c = parent.loadClass(name, false);
11 } else {
12 //如果父加载器不存在，则委托给启动类加载器 加载
13 c = findBootstrapClassOrNull(name);
14 }
15 } catch (ClassNotFoundException e) {
16 // ClassNotFoundException thrown if class not found
17 // from the non-null parent class loader
18 }
19 
20 if (c == null) {
21 // 如果父类加载器无法加载，自身才尝试加载
22 long t1 = System.nanoTime();
23 c = findClass(name);
24 
25 // this is the defining class loader; record the stats
26 sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
27 sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
28 sun.misc.PerfCounter.getFindClasses().increment();
29 }
30 }
31 if (resolve) {
32 resolveClass(c);
33 }
34 return c;
35 }
36 }

 

先检查是否已经被加载过，若没有加载则调用父加载器的loadClass() 方法，若父加载器为空，则默认使用启动类加载器作为父加载器。如果父加载器失败，再调用自己的findClass 方法进行加载,因此到这里再次证明了类加载器的过程：

总结
关于类加载器网上有很多的文章，记录下来，也算是一个自己总结的过程，有时候看很多遍，不如实实在在的写一遍。