class加载过程之 ClassLoader（类加载器）原理

Java从编码到执行

        首先我们来看一下Java是如何从编码到执行的呢？ 我们有一个x.java文件通过执行javac命令可以变成x.class文件，当我们调用Java命令的时候class文件会被装载到内存中，这个过程叫做classloader。一般情况下我们自己写代码的时候会用到Java的类库，所以在加载的时候也会把Java类库相关的类也加载到内存中。装载完成之后会调用字节码解释器和JIT即时编译器来进行解释和编译，编译完之后由执行引擎开始执行，执行引擎下面对应的就是操作系统硬件了。下图是大体的流程：

        

class加载过程：
    1.loading  :把class 文件load到内存
           1.双亲委派，主要出于安全考虑

           2.ClassLoader 的源码

                 findInCache -> parent.loadClass -> findClass()

             3.自定义类加载器

                1.继承ClassLoader

                2.重写 findClass() 方法，使用defineClass方法将byte[] 转为 class
    2.linking
          1.verification 验证文件是否符合JVM规定（是否cafe baby开头）
          2.preparation  静态成员变量赋默认值
          3.resolution   解析。将类、方法、属性 等符号引用解析为直接引用，常量池中  的各种符号引用解析为指针、偏移量等内存地址的直接引用

   3. initializing 
        调用类初始化代码，给静态成员变量赋初始值  

 

下面重点介绍类加载器原理

一、什么是ClassLoader?

         大家都知道，当我们写好一个Java程序之后，不是管是CS还是BS应用，都是由若干个.class文件组织而成的一个完整的Java应用程序，当程序在运行时，即会调用该程序的一个入口函数来调用系统的相关功能，而这些功能都被封装在不同的class文件当中，所以经常要从这个class文件中要调用另外一个class文件中的方法，如果另外一个文件不存在的，则会引发系统异常。而程序在启动的时候，并不会一次性加载程序所要用的所有class文件，而是根据程序的需要，通过Java的类加载机制（ClassLoader）来动态加载某个class文件到内存当中的，从而只有class文件被载入到了内存之后，才能被其它class所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。

二、Java默认提供的三个ClassLoader

1.BootStrap ClassLoader :

        启动类加载器，是Java 类加载层次中最顶层的类加载器，负责加载JDK中的核心类库，如：rt.jar、resources.jar、charsets.jar等
2.Extension ClassLoader :

        扩展类加载器，负责加载Java的扩展类库，默认加载JAVA_HOME/jre/lib/ext/目录下的所有jar.
3.App ClassLoader :

        系统类加载器，负责加载应用程序classpath目录下的所有jar 和class 文件。
       

注意： 除了Java默认提供的三个ClassLoader之外，用户还可以根据需要定义自已的ClassLoader，而这些自定义的ClassLoader都必须继承自java.lang.ClassLoader类，也包括Java提供的另外二个ClassLoader（Extension ClassLoader和App ClassLoader）在内，但是Bootstrap ClassLoader不继承自ClassLoader，因为它不是一个普通的Java类，底层由C++编写，已嵌入到了JVM内核当中，当JVM启动后，Bootstrap ClassLoader也随着启动，负责加载完核心类库后，并构造Extension ClassLoader和App ClassLoader类加载器。

三、ClassLoader加载类的原理

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

 JVM是按需动态加载，采用双亲委派机制

 双亲委派 是一个 孩子向父亲方向，然后父亲向孩子放学的双亲委派过程

类加载器的加载过程是分成不同的层次来加载的，不同的类加载器来加载不同的class文件，  Bootstrap >Extension>Application>Custom(自定义类加载器)

1、第一个类加载器的层次为：Bootstrap 称为启动类加载器，是Java类加载层次中最顶层的类加载器，负责加载JDK中的核心类库。

2、第二个类加载器的层次为：Extension 是用来加载扩展类的，主要负责加载Java的扩展类库,默认加载JAVA_HOME/jre/lib/ext/目录下的所有jar包。

3、第三个类加载器的层次为：Application 又称为系统类加载器,负责在JVM启动时,加载来自在命令java中的classpath或者java.class.path系统属性或者CLASSPATH操作系统属性所指定的JAR类包和类路径。

下图为类加载的一个全过程：

用比较通俗的话来解释这个过程，当有一个类需要被加载时，首先要判断这个类是否已经被加载到内存，判断加载与否的过程是有顺序的，如果有自己定义的类加载器，会先到custom class loader 的cache（缓存）中去找是否已经加载，若已加载直接返回结果，否则到App的cache中查找，如果已经存在直接返回，如果不存在，到Extension中查找，存在直接返回，不存在继续向父加载器中寻找直到Bootstrap顶层，如果依然没找到，那就是没有加载器加载过这个类，需要委派对应的加载器来加载，先看看这个类是否在自己的加载范围内，如果是直接加载返回结果，若不是继续向下委派，以此类推直到最下级，如果最终也没能加载，就会直接抛异常 ClassNotFoundException，这就是双亲委派模式。

 

双亲委派：其工作原理的是，如果一个类加载器收到了类加载请求，并不会直接去加载，而是自下而上的向顶层类加载器查找是否已经被加载了，如果被加载就不用进行加载，如果未被加载过，则会自上而下的检查是否属于自己加载的范围，如果属于则加载，如果不属于则向下委托，直到类被加载进来才能叫做成功，如果加载不成功就会抛异常classnotfoundexeption,这就叫做双亲委派。

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

 

 参考文字：https://blog.csdn.net/xyang81/article/details/7292380