双亲委派模型

首先说一说什么是类和类加载器

1.类（Class）

我们在编写代码时，创建的每个“*.java”文件都可以认为是一个类，我们使用“class”去定义一个类，例如String.java。

2.类加载器（Class Loader）

（1）将“通过类的全限定名获取描述类的二进制字节流”这件事放在虚拟机外部，由应用程序自己决定如何实现。

（2）我们定义的类，如果我们要在编码中用到这个类，首先就是要先把“*.java”这个文件编译成class文件，然后由对应的“类加载器”加载到JVM中，我们才能够使用这个“类对象”。

在我们日常使用中，类加载器默认有下面3种：

启动类加载器属于虚拟机的一部分，它是用C++写的，看不到源码；其他类加载器是用Java写的，说白了就是一些Java类，一会儿就可以看到了，比如扩展类加载器、应用类加载器。

（1）启动类加载器（Bootstrap Class Loader）：

JDK自带的一款类加载器，用于加载JDK内部的类。Bootstrap类加载器用于加载JDK中$JAVA_HOME/jre/lib下面的那些类，比如rt.jar包里面的类。

（2）扩展类加载器（Extension Class Loader）

主要用于加载JDK扩展包里的类。一般$JAVA_HOME/lib/ext下面的包都是通过这个类加载器加载的，这个包下面的类基本上是以javax开头的。

（3）应用程序类加载器（Application Class Loader）

用来加载开发人员自己平时写的应用代码的类的，加载存放在classpath路径下的那些应用程序级别的类的。

既然只是把class文件装进虚拟机，为什么要用多种加载器呢？因为Java虚拟机启动的时候，并不会一次性加载所有的class文件（内存会爆），而是根据需要去动态加载。

双亲委派模型

双亲委派模式是在Java 1.2后引入的，其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式

为什么叫双亲委派模型而不是父委派模型？

在阅读相关虚拟机书籍以及大多数人的交流中，这种模型叫做双亲委派模型。但是我们在上述概念中得知，这里的请求委托仅仅给了父类加载器去执行，而并不是双亲。那为什么叫做双亲委派模型呢？

对于这个问题处于好奇，所以去网络中去搜素了一番，这样写道：

这是个很蛋疼的翻译问题，实际上在oracle官方文档上，人家是这样描述的：

The Java platform uses a delegation model for loading classes. The basic idea is that every class loader has a “parent” class loader. When loading a class, a class loader first “delegates” the search for the class to its parent class loader before attempting to find the class itself.

用谷歌进行的机翻是这样的：

Java平台使用委托模型来加载类。基本思想是每个类加载器都有一个“父”类加载器。加载类时，类加载器首先将对类的搜索“委派”给其父类加载器，然后再尝试查找类本身。

所以很多博客是以父委派模型去描述

双亲委派模型提及的父类并不是继承关系

上面提及了父类加载器，以Java的特性可能会有人误认为为继承（extend）

这里类加载器之间的父子关系一般不会以继承.(Inheritance)的关系来实现;而是都使用组合(Composition)关系来复用父加载器的代码。

以下代码取自书中：

 {
            // First, check if the class has already been loaded 先判断class是否已经被加载过了
            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;
        }

一、它们分别加载了什么？
转载自：https://zhuanlan.zhihu.com/p/73359363

类加载器是通过类的全限定名（或者说绝对路径）来找到一个class文件的。可以直接打印启动类加载器BootstrapClassLoader的加载路径看看：

URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (URL url : urls) {
    System.out.println(url);
}

输出结果（%20是空格）：

file:/C:/Program%20Files/Java/jre1.8.0_131/lib/resources.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/rt.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/sunrsasign.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/jsse.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/jce.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/charsets.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/jfr.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/classes

可以看到，启动类加载器加载的是jre和jre/lib目录下的核心库，具体路径要看你的jre安装在哪里。再打印一下扩展类加载器ExtentionClassLoader的加载路径看看：

URL[] urls = ((URLClassLoader) ClassLoader.getSystemClassLoader().getParent()).getURLs();
for (URL url : urls) {
    System.out.println(url);
}

输出结果：

file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/access-bridge-64.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/cldrdata.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/dnsns.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/dns_sd.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/jaccess.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/jfxrt.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/localedata.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/nashorn.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/sunec.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/sunjce_provider.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/sunmscapi.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/sunpkcs11.jar
file:/C:/Program%20Files/Java/jre1.8.0_131/lib/ext/zipfs.jar

很明显，扩展类加载器加载的是jre/lib/ext目录下的扩展包。这些类库具体是什么不重要，只需要知道不同的类库可能是被不同的类加载器加载的。

JVM是怎么知道我们把JRE安装到哪里了呢？因为你安装完JDK之后配置了环境变量啊！那些 JAVA_HOME、CLASSPATH 之类的就是干这个用的。
最后是AppClassLoader：

URL[] urls = ((URLClassLoader) ClassLoader.getSystemClassLoader()).getURLs();
for (URL url : urls) {
    System.out.println(url);
}

输出结果：

file:/D:/JavaWorkSpace/PicklePee/bin/

这是当前java工程的bin目录，也就是我们自己的Java代码编译成的class文件所在。

双亲委派模型的好处

使用双亲委派模型来组织类加载器之间的关系，:有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang .Object,.它存放在:rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中;那系统中将会出现多个不同的Object类, Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。如果读者有兴趣的话，可以尝试去编写-一个与rt.jar类库中已有类重名的Java类，将会发现可以正常编译，但永远无法被加载运行。

如果你自己写的一个类与核心类库中的类重名，会发现这个类可以被正常编译，但永远无法被加载运行。因为你写的这个类不会被应用类加载器加载，而是被委托到顶层，被启动类加载器在核心类库中找到了。如果没有双亲委托机制来确保类的全局唯一性，谁都可以编写一个java.lang.Object类放在classpath下，那应用程序就乱套了。

从安全的角度讲，通过双亲委托机制，Java虚拟机总是先从最可信的Java核心API查找类型，可以防止不可信的类假扮被信任的类对系统造成危害。

破坏双亲委派模型

第一次破坏：

由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则在JDK1.0时代就已经存在，面对已经存在的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。在此之前，用户去继承java.lang.ClassLoader的唯一目的就是为了重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法唯一逻辑就是去调用自己的loadClass()。

第二次破坏：

双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类的同一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的API，但世事往往没有绝对的完美。

如果基础类又要调用回用户的代码，那该么办？

一个典型的例子就是JNDI服务，JNDI现在已经是Java的标准服务，
它的代码由启动类加载器去加载（在JDK1.3时放进去的rt.jar），但JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者的代码，但启动类加载器不可能“认识”这些代码。

为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，他将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文加载器，JNDI服务就可以使用它去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则，但这也是无可奈何的事情。Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI、JDBC、JCE、JAXB和JBI等。

第三次破坏：

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求导致的，这里所说的“动态性”指的是当前一些非常“热门”的名词：代码热替换、模块热部署等，简答的说就是机器不用重启，只要部署上就能用。
OSGi实现模块化热部署的关键则是它自定义的类加载器机制的实现。每一个程序模块(Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi幻境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当受到类加载请求时，OSGi将按照下面的顺序进行类搜索：
1）将java.＊开头的类委派给父类加载器加载。
2）否则，将委派列表名单内的类委派给父类加载器加载。
3）否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载。
4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
7）否则，类加载器失败。

JDBC为什么要破坏双亲委派模型

问题背景

在JDBC 4.0之后实际上我们不需要再调用Class.forName来加载驱动程序了，我们只需要把驱动的jar包放到工程的类加载路径里，那么驱动就会被自动加载。

这个自动加载采用的技术叫做SPI，数据库驱动厂商也都做了更新。可以看一下jar包里面的META-INF/services目录，里面有一个java.sql.Driver的文件，文件里面包含了驱动的全路径名。

使用上，我们只需要通过下面一句就可以创建数据库的连接：

Connection con =    
             DriverManager.getConnection(url , username , password ) ;

问题解答

因为类加载器受到加载范围的限制，在某些情况下父类加载器无法加载到需要的文件，这时候就需要委托子类加载器去加载class文件。

JDBC的Driver接口定义在JDK中，其实现由各个数据库的服务商来提供，比如MySQL驱动包。DriverManager 类中要加载各个实现了Driver接口的类，然后进行管理，但是DriverManager位于 JAVA_HOME中jre/lib/rt.jar 包，由BootStrap类加载器加载，而其Driver接口的实现类是位于服务商提供的 Jar 包，根据类加载机制，当被装载的类引用了另外一个类的时候，虚拟机就会使用装载第一个类的类装载器装载被引用的类。也就是说BootStrap类加载器还要去加载jar包中的Driver接口的实现类。我们知道，BootStrap类加载器默认只负责加载 $JAVA_HOME中jre/lib/rt.jar 里所有的class，所以需要由子类加载器去加载Driver实现，这就破坏了双亲委派模型。

查看DriverManager类的源码，看到在使用DriverManager的时候会触发其静态代码块，调用 loadInitialDrivers() 方法，并调用ServiceLoader.load(Driver.class) 加载所有在META-INF/services/java.sql.Driver 文件里边的类到JVM内存，完成驱动的自动加载。

每个Tomcat的webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

事实上，tomcat之所以造了一堆自己的classloader，大致是出于下面三类目的：

对于各个 webapp中的 class和 lib，需要相互隔离，不能出现一个应用中加载的类库会影响另一个应用的情况，而对于许多应用，需要有共享的lib以便不浪费资源。
与 jvm一样的安全性问题。使用单独的 classloader去装载 tomcat自身的类库，以免其他恶意或无意的破坏；
热部署。相信大家一定为 tomcat修改文件不用重启就自动重新装载类库而惊叹吧。

为什么要自定义加载类
我们需要的类不一定存放在已经设置好的classPath下(有系统类加载器AppClassLoader加载的路径)，对于自定义路径中的class类文件的加载，我们需要自己的ClassLoader
有时我们不一定是从类文件中读取类，可能是从网络的输入流中读取类，这就需要做一些加密和解密操作，这就需要自己实现加载类的逻辑，当然其他的特殊处理也同样适用。
可以定义类的实现机制，实现类的热部署,如OSGi中的bundle模块就是通过实现自己的ClassLoader实现的。