Java------类加载机制

环境变量

---

我们在安装JDK的时候，需要进行环境变量的配置，即path与classpath,大部分人都知道path的作用，是为了能在cmd中使用java等一些命令，那classpath呢？根据字面意思我们可以理解成是配置类路径，那他到底是怎么加载的呢？这就涉及到了Java内部的机制-----类加载机制

(1)配置path
    path=.;jdk\bin;
    配置path的目的是为了能在cmd中使用java、javac、javadoc命令
(2)配置classpath
    当我们在cmd中输入java XXXX这个命令的时候，java虚拟机启动了类加载器，将我们的XXXX的实例加载到了内存中。

类加载机制

---

那么类加载器又是怎么找到我们的class文件的呢，这就涉及到了我们的类加载机制，在java类加载器中，有三种加载器，按照层级顺序由上至下分别是：引导加载器、扩展加载器、系统加载器。
(1)系统加载器：系统加载器会去我们配置的classpath环境变量的路径中去查找类文件。
(2)扩展加载器：扩展加载器会去我们的jdk/lib/ext目录中去查找
(3)引导加载器：引导加载器会去我们的jdk/jre/lib/rt.jar中去查找

类加载顺序

当我们执行java命令的时候，首先会启动系统加载器，但是他不会立马去classpath里面查询，而是他必须先向上一层的加载器去申请执行权，会先询问扩展加载器我是否可以加载，而扩展加载器也不会立马加载，他会先去向引导加载器申请执行权，引导加载器已经是最上层了，所以他首先会去jdk/jre/lib/rt.jar中查找类，很显然的是rt.jar中不会存在我们自己写的类，所以他会通知下级，也就是引导加载器，让引导加载器来加载，引导加载器中如果也没有，那么会通知系统加载器来加载，如果系统加载器中也没有，那么则会抛出NoClassDefFoundError异常
PS:如果我们没有配置classpath变量，那么则会去我们的默认路径找，也就是cmd中的当前路径

验证实例

我们写一个类来测试一下类加载器的顺序

public class TestDemo{
    public static void main(String agrs[]){
        System.out.println("TestDemo");
    }
}

通过java命令运行之后，正常输出了TestDemo

我们在TestDemo.java中添加一句输入语句，打印字符串“扩展加载器”

public class TestDemo{
    public static void main(String agrs[]){
        System.out.println("TestDemo");
        System.out.println("扩展加载器");
    }
}

下面我通过jar命令将我们的TestDemo打包成jar文件

我们将TestDemo.jar剪切到我们的扩展加载器的查询路径下,也就是jdk/lib/ext目录中。
然后我们将TestDemo.java中打印”引导加载器”的语句改为打印”系统加载器”用来区分我们之前打包的TestDemo.jar中的class文件

public class TestDemo{
    public static void main(String agrs[]){
        System.out.println("TestDemo");
        System.out.println("系统加载器");
    }
}

现在我们编译运行，看看结果

说明并没有加载我们当前路径下的TestDemo.class文件，而是加载了扩展加载器路径下的TestDemo.class

总结

根据打印结构我们可以知道，类加载器的查询顺序是自下而上，即使系统加载器-扩展加载器-引导加载器，而类的加载顺序是自上而下，如果上层加载器的路径中有该类，则上层加载器会加载该类。