虚拟机类加载机制【双亲委派模型】

站在Java虚拟机角度来看，只存在两种不同的类加载器：

1. 启动类加载器（Bootstrap ClassLoader）:使用C++语言实现，虚拟机的一部分。
2. 其他所有的类加载器：Java语言实现，独立存在于虚拟机外部，且全都继承自抽象类java.lang.ClassLoader。

站在Java开发人员角度来看，类加载器应当划分更细致一下。自JDK1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构。

以下内容基于JDK8及之前版本的Java。

• 三层类加载器
  绝大多数Java程序都会使用到系统提供的3个类加载器来进行加载。

  1. 启动类加载器（Bootstrap Class Loader）
     负责加载存放在<JAVA_HOME>\lib目录，或被-Xbootclasspath参数所指定的路径中存放的，且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar,名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。
     启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给启动类加载器去处理，那直接使用null代替即可。
  2. 扩展类加载器 （Extension Class Loader）
     在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现，负责加载<JAVA_HOME>\lib\ext目录中，或被java.ext.dirs系统变量所指定的路径中所有的类库。
     这是一种Java系统类库的扩展机制，将具有通用性的类库放置在ext目录里以扩展Java SE的功能，在JDK9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。由于是由Java代码实现，开发者可直接在程序中使用扩展类加载器来加载Class文件。
  3. 应用程序类加载器（Application Class Loader）
     由sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystemClassLoader()方法的返回值，也称为“系统类加载器”。
     负责加载用户类路径（ClassPath）上所有的类库，可直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

• 双亲委派模型
  JDK9之前的Java应用都由三种类加载器互相配合来完成加载，也可以加入自定义的类加载器来进行拓展，如增加除了磁盘位置以外的Class文件来源，或通过类加载器实现类的隔离、重载等功能。
  类加载器之间的协作关系“通常”如下：

  
  类加载器双亲委派模型.png

如图，各种类加载器之间的层次关系成为类加载器的“双亲委派模型（Parents Delegation Model）”。它要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。这里的类加载器之间的父子关系一般不是继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

双引号强调这是“通常”的协作关系：类加载器的双亲委派模型在JDK1.2时期引入，并广泛应用于此后几乎所有的Java程序中，它不是强制性约束力的模型，而是推荐用的一种类加载器实现的最佳实践。

双亲委派模型的工作过程：
如果一个类加载器收到了类加载的请求，它首先不会自己加载，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它搜索范围中没有找到所需的类）中，子加载器才会尝试自己去完成加载。

使用双亲委派模型来组织类加载器之间的关系，显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系，如类java.lang.Object，它存放在rt.jar之中，无论哪一种类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。

反之，如果没有使用双亲委派模型，都由各个类加载器自行加载的话，如果用户编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。

双亲委派模型对于保证Java程序的未定运行极为重要，但它的实现去异常简单，用以实现双亲委派的代码仅有短短十余行，全部集中在java.lang.ClassLoader的loadClass()方法之中。

    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }