ClassLoader怎么加载class

ClassLoader即类加载器，负责将 .class 文件(可能在磁盘上, 也可能在网络上) 加载到内存中, 并为之生成对应的Java.lang.Class 对象，当 JVM 启动时，会形成由三个类加载器组成的初始类加载器层次结构：bootstrap classloader ——> extension classloader ——> system classloader

bootstrap classloader：引导（也称为原始）类加载器，它负责加载Java的核心类。这个加载器的是非常特殊的，它实际上不是 java.lang.ClassLoader的子类，而是由JVM自身实现的。可以通过执行以下代码来获得bootstrap classloader加载了那些核心类库：

extension classloader －扩展类加载器，它负责加载JRE的扩展目录（JAVA_HOME/jre/lib/ext或者由java.ext.dirs系统属性指定的）中的JAR包。这为引入除Java核心类以外的新功能提供了一个标准机制。因为默认的扩展目录对所有从同一个JRE中启动的JVM都是通用的，所以放入这个目录的 JAR类包对所有的JVM和system classloader都是可见的。

extension classloader是system classloader的parent，而bootstrap classloader是extension classloader的parent，但 bootstrap classloader 不是一个实际的classloader。

system classloader －系统（也称为应用）类加载器，它负责在JVM被启动时，加载来自在命令java中的-classpath或者java.class.path系统属性或者 CLASSPATH操作系统属性所指定的JAR类包和类路径。

可以通过静态方法ClassLoader.getSystemClassLoader()找到该类加载器。如果没有特别指定，则用户自定义的任何类加载器都将该类加载器作为它的父加载器。

classloader 加载类用的是全盘负责委托机制。

全盘负责：即是当一个classloader加载一个Class的时候，这个Class所依赖的和引用的所有 Class也由这个classloader负责载入，除非是显式的使用另外一个classloader载入

委托机制：先让parent（父）类加载器 (而不是super，它与parent classloader类不是继承关系)寻找，只有在parent找不到的时候才从自己的类路径中去寻找。

l类加载还采用了cache机制：如果 cache中保存了这个Class就直接返回它，如果没有才从文件中读取和转换成Class，并存入cache，这就是为什么修改了Class但是必须重新启动JVM才能生效的原因。

1. 检测此Class是否载入过（即在cache中是否有此Class），如果有到8,如果没有到2

2. 如果parent classloader不存在（没有parent，那parent一定是bootstrap classloader了），到4

3. 请求parent classloader载入，如果成功到8，不成功到5

4. 请求jvm从bootstrap classloader中载入，如果成功到8

5. 寻找Class文件（从与此classloader相关的类路径中寻找）。如果找不到则到7.

6. 从文件中载入Class，到8.

7. 抛出ClassNotFoundException.

8. 返回Class.

ClassLoader的作用

我们都知道java程序写好以后是以.java（文本文件）的文件存在磁盘上，然后，我们通过(bin/javac.exe)编译命令把.java文件编译成.class文件（字节码文件），并存在磁盘上。但是程序要运行，首先一定要把.class文件加载到JVM内存中才能使用的，我们所讲的classLoader,就是负责把磁盘上的.class文件加载到JVM内存中，如下图所示：

你可以认为每一个Class对象拥有磁盘上的那个.class字节码内容,每一个class对象都有一个getClassLoader()方法，得到是谁把我从.class文件加载到内存中变成Class对象的。

ClassLoader层次结构

请执行如下程序：

public class Test {
public static void main(String[] args) {
ClassLoader classLoader = Test.class.getClassLoader();
System.out.println(classLoader);

ClassLoader classLoader1 = classLoader.getParent();
System.out.println(classLoader1);

ClassLoader classLoader2 = classLoader1.getParent();
System.out.println(classLoader2);
}
}

它的输出是：

sun.misc.Launcher$AppClassLoader@2a139a55
sun.misc.Launcher$ExtClassLoader@7852e922
null

得到了 classLoader2就是null值了。这里其实有三个类加载器:

: 根类加载器(null)

它是由本地代码(c/c++)实现的，你根本拿不到他的引用，但是他实际存在，并且加载一些重要的类，它加载(%JAVA_HOME%\jre\lib),如rt.jar(runtime)、i18n.jar等，这些是Java的核心类。

(2): 扩展类加载器(ExtClassLoader)

虽说能拿到，但是我们在实践中很少用到它，它主要加载扩展目录下的jar包， %JAVA_HOME%\lib\ext

(3): 应用类加载器(AppClassLoader)

它主要加载我们应用程序中的类，如Test,或者用到的第三方包,如jdbc驱动包等。

这里的父类加载器与类中继承概念要区分，它们在class定义上是没有父子关系的。

Class加载时调用类加载器的顺序

当一个类要被加载时，有一个启动类加载器和实际类加载器的概念，这个概念请看如下分析

如上面的Test.class要进行加载时，它将会启动应用类加载器进行加载Test类，但是这个应用类加载器不会真正去加载他，而是会调用看是否有父加载器，结果有，是扩展类加载器，扩展类加载器也不会直接去加载，它看自己是否有父加载器没，结果它还是有的，是根类加载器。

所以这个时候根类加载器就去加载这个类，可在%JAVA_HOME%\jre\lib下，它找不到com.wangmeng.Test这个类，所以他告诉他的子类加载器，我找不到，你去加载吧，子类扩展类加载器去%JAVA_HOME%\lib\ext去找，也找不着，它告诉它的子类加载器 AppClassLoader，我找不到这个类，你去加载吧，结果AppClassLoader找到了，就加到内存中，并生成Class对象。
这个时间时候启动类加载器（应用类加载器）和实际类加载器（应用类加载器）是同一个.

这就是Java中著名的委托加载机制，看如下图：