JVM（二）：ClassLoader双亲委派机制源码分析

前言：
为了更好的分析Tomcat的类加载机制，首先要对JDK的类加载机制有较为深入的理解，JDK类加载机制的前期理论在http://www.jianshu.com/p/639f430fe15a中已有阐述，故这里只从源码的角度看待双亲委派机制的代码实现，本文主要验证和解惑的问题是

• 引导类加载器BootStrap ClassLoader、扩展类加载器Extension ClassLoader、应用类加载器Application ClassLoader（或者称为系统类加载器System ClassLoader）加载的内容（哪些文件夹）在源码中是如何体现的
• 类加载器父子关系在源码中如何体现
• 双亲委派机制的整个过程在源码中如何实现

扩展类加载器Extension ClassLoader和应用类加载器Application ClassLoader对应的都是rt.jar下sun.misc.Launcher.class中的两个静态内部类ExtClassLoader和AppClassLoader，两个类以组合的形式存在于Launcher类中；而引导类加载器BootStrap ClassLoader因为是使用C++实现，因此jdk中没有特定的类与之对应，我们可以通过查阅openjdk源码和jdk代码推理的手段理解它，本文使用第二种方式。jdk中类加载相关类图如下所示

JDK类加载器相关类UML图

1. 引导类加载器、扩展类加载器和应用类加载器各自加载哪些内容

引导类加载器加载路径为sun.boot.class.path

BootStrap ClassLoader加载路径

扩展类加载器加载路径为java.ext.dirs，比如ext目录下

Extension ClassLoader加载路径

应用类加载器加载路径为java.class.path，即classpath

Application ClassLoader加载路径

2. 类加载之间的父子关系如何体现

对于该问题的回答，我们需要从sum.misc.Lanucher.class初始化时进行分析

public Launcher() {
        Launcher.ExtClassLoader var1;
        try {
            //                (1)初始化扩展类加载器
            var1 = Launcher.ExtClassLoader.getExtClassLoader();
        } catch (IOException var10) {
            throw new InternalError("Could not create extension class loader");
        }

        try {
            //                (2)初始化应用类加载器
            this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
        } catch (IOException var9) {
            throw new InternalError("Could not create application class loader");
        }
        //                    (3)线程上下文加载器
        Thread.currentThread().setContextClassLoader(this.loader);
        String var2 = System.getProperty("java.security.manager");
        if(var2 != null) {
            SecurityManager var3 = null;
            if(!"".equals(var2) && !"default".equals(var2)) {
                try {
                    var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();
                } catch (IllegalAccessException var5) {
                    ;
                } catch (InstantiationException var6) {
                    ;
                } catch (ClassNotFoundException var7) {
                    ;
                } catch (ClassCastException var8) {
                    ;
                }
            } else {
                var3 = new SecurityManager();
            }

            if(var3 == null) {
                throw new InternalError("Could not create SecurityManager: " + var2);
            }

            System.setSecurityManager(var3);
        }

    }

(1)处注释初始化了扩展类加载器，而真正的调用代码在静态内部类ExtClassLoader.class中的getExtClassLoader()中，我们接着看

ExtClassLoader初始化过程解析

getExtClassLoader()内部通过调用该类的构造器，返回了一个ExtClassLoader的实例，这里构造器传入的参数var0实际上就是ExtClassLoader加载目录的文件对象。第二个红线说明创建ExtClassLoader的实例实际上还得调用其父类URLClassLoader的构造器，其中有三个参数，第二个参数最为重要，该参数表示ExtClassLoader对象的父加载器是谁

 

URLClassLoader构造器

这里URLClassLoader会再调用其父类的构造器，最终止于ClassLoader，这里我们无需关心，现在需要牢记的是ExtClassLoader.class的父类加载器为null
我们接着来看代码的第二个注释初始化应用类加载器，源码中将(1)处创建的ExtClassLoader的实例var1传递给了，应用类加载器的getAppClassLoader()方法，聪明的读者在这里实际上可以推断出，该var1所指代的ExtClassLoader必定就是通过该方法被设置成了Application ClassLoader的父类加载器，bingo

 

 

Application ClassLoader初始化源码

从上图中得知，Application ClassLoader也走了ExtClassLoader的老路，那么这里的var2就是parent扩展类加载器ExtClassLoader了。至此ClassLoader父子关系在JDK源码中是如何做的也就清楚了，但是之前留的问题null为什么会是ExtClassLoader的parent还是没有解决，下面第三个问题的解释中隐藏了该问题的答案。

 

3. 委派机制如何实现

由于类加载器的双亲委派机制，因此，我们可以通过任何一个类加载器加载类的代码来梳理整个类加载器的加载流程，这里我们选择应用类加载器Application ClassLoader，双亲委派机制的具体逻辑存在于类加载器的loadClass方法中

Application ClassLoader的loadClass方法

红线处代码调用Application ClassLoader父类的loadClass方法，而由第一张UML图可知，Application ClassLoader的父类为URLClassLoader和ClassLoader，继续追踪

ClassLoader进行类加载的核心方法

红框内的代码即是实现委派机制的代码，逻辑很简单：如果当前类加载器的父类加载器不为空，就先让副类加载器加载name所对应的类，这里的parent成员变量实际上就是第二个问题中类加载器初始化时传递的父类加载器，这就解释了ExtClassLoader的父类加载器传递的是null，就会执行else的逻辑，调用findBootstrapClassOrNull()，而该方法最终为native方法private native Class findBootstrapClass(String name);，实际上就是调用openjdk中BootStrap ClassLoader的实现去加载该类