面试——双亲委派机制

介绍双亲委派机制之前，需要先知道
Java中的集中加载器：
● BootstrapLoader：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等
● ExtClassloader：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
● AppClassLoader：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类
● 自定义加载器：负责加载用户自定义路径下的类包

import sun.misc.Launcher;

import java.net.URL;

public class ClassLoadTest3 {
    public static void main(String[] args) {
        System.out.println(String.class.getClassLoader());
        System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader().getClass().getName());
        System.out.println(ClassLoadTest3.class.getClassLoader().getClass().getName());

        System.out.println();
        ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
        ClassLoader extClassloader = appClassLoader.getParent();
        ClassLoader bootstrapLoader = extClassloader.getParent();
        System.out.println("the bootstrapLoader : " + bootstrapLoader);
        System.out.println("the extClassloader : " + extClassloader);
        System.out.println("the appClassLoader : " + appClassLoader);

        System.out.println();
        System.out.println("bootstrapLoader加载以下文件：");
        URL[] urls = Launcher.getBootstrapClassPath().getURLs();
        for (int i = 0; i < urls.length; i++) {
            System.out.println(urls[i]);
        }

        System.out.println();
        System.out.println("extClassloader加载以下文件：");
        System.out.println(System.getProperty("java.ext.dirs"));

        System.out.println();
        System.out.println("appClassLoader加载以下文件：");
        System.out.println(System.getProperty("java.class.path"));

    }
}

类加载器初始化过程：
sun.misc.Launcher内部源码

从图中可以看出在Launcher构造方法内部，其创建了两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。

双亲委派机制：
在加载某个类时会先委托父加载器寻找目标类，找不到再委托上层父加载器加载，如果所有父加载器在自己的加载类路径下都找不到目标类，则在自己的类加载路径中查找并载入目标类

AppClassLoader加载类的双亲委派机制源码：
AppClassLoader的loadClass方法最终会调用其父类ClassLoader的loadClass方法，该方法的大体逻辑如下：

首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回。
如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加载。
如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的findClass方法来完成类加载。

//ClassLoader的loadClass方法，里面实现了双亲委派机制
protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // 检查当前类加载器是否已经加载了该类
        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();
                //都会调用URLClassLoader的findClass方法在加载器的类路径里查找并加载该类
                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;
    }
}

为什么要设计双亲委派机制：
1、防止重复加载同一个.class。通过委托去向上面问一问，加载过了，就不用再加载一遍
2、保证核心.class不能被篡改。通过委托方式，不会去篡改核心.class，即使篡改也不会去加载，即使加载也不会是同一个.class对象了，不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。
3、如果没有双亲委派模型而是由各个类加载器自行加载的话，如果用户编写了一个java.lang.Object的同名类并放在ClassPath中，那系统中将会出现多个不同的Object类，程序将混乱

Tomcat打破双亲委派机制：
以Tomcat类加载为例，Tomcat 如果使用默认的双亲委派类加载机制行不行？
我们思考一下：Tomcat是个web容器， 那么它要解决什么问题：

1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机。
3. web容器也有自己依赖的类库，不能与应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
4. web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情， web容器需要支持 jsp 修改后不用重启。热部署

再看看我们的问题：Tomcat 如果使用默认的双亲委派类加载机制行不行？
答案是不行的。为什么？

• 第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。
• 第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。
• 第三个问题和第一个问题一样。
• 我们再看第四个问题，我们想我们要怎么实现jsp文件的热加载，jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件

因此Tomcat无法使用传统的双亲委派机制。
Tomcat有自己的类加载机制

• CommonClassLoader：是Tomcat最基本的类加载器，它加载的类可以被Tomcat容器和Web应用访问。
• CatalinaClassLoader：是Tomcat容器私有的类加载器，加载类对于Web应用不可见。
• SharedClassLoader：各个Web应用共享的类加载器，加载的类对于所有Web应用可见，但是对于Tomcat容器不可见。
• WebAppClassLoader：各个Web应用私有的类加载器，加载类只对当前Web应用可见。比如不同war包应用引入了不同的spring版本，这样能加载各自的spring版本，相互隔离。

SPI接口实现类加载打破双亲委派机制：
例如JDBC和JNDI…
JNDI是Java中的标准服务，它的代码由启动类加载器去加载。
但JNDI有对资源进行集中管理和查找，它需要调用由独立厂商在应用程序的ClassPath下的实现了JNDI接口的代码，但启动类加载器不可能人事这些外部代码。
为了解决这个问题，Java后来引入了线程上下文类加载器（Thread Context ClassLoader）。
这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时没有设置，他将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置的话，那这个类加载器默认就是应用程序类加载器。在加载SPI接口时，就可以通过java.lang.Thread类的getContextClassLoader()方法获取应用程序累加器，去加载实现类代码。
有了线程上下文类加载器，JNDI服务就可以使用它去加载所需要的SPI代码实现类，也就是父类加载器请求子类加载器去完成类加载的动作，这样就打破了双亲委派机制。

在实际使用时一般都用下面的经典结构: （获取-使用-还原）

ClassLoader targetClassLoader = null;// 外部参数

ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(targetClassLoader);
    // TODO
} catch (Exception e) {
    e.printStackTrace();
} finally {
    Thread.currentThread().setContextClassLoader(contextClassLoader);
}