双亲委派机制

指的就是：当一个类加载器收到了类加载的请求的时候，他不会直接去加载指定的类，而是把这个请求委托给自己的父加载器去加载。只有父加载器无法加载这个类的时候，才会由当前这个加载器来负责类的加载。

为什么需要双亲委派

因为类加载器之间有严格的层次关系，那么也就使得Java类也随之具备了层次关系。
或者说这种层次关系是优先级。
比如一个定义在java.lang包下的类，因为它被存放在rt.jar之中，所以在被加载过程汇总，会被一直委托到Bootstrap ClassLoader，最终由Bootstrap ClassLoader所加载。
而一个用户自定义的com.hollis.ClassHollis类，他也会被一直委托到Bootstrap ClassLoader，但是因为Bootstrap ClassLoader不负责加载该类，那么会在由Extention ClassLoader尝试加载，而Extention ClassLoader也不负责这个类的加载，最终才会被Application ClassLoader加载。

这种机制有几个好处：

  • 首先，通过委派的方式，可以避免类的重复加载，当父加载器已经加载过某一个类时，子加载器就不会再重新加载这个类。
  • 另外，通过双亲委派的方式，还保证了安全性。因为Bootstrap ClassLoader在加载的时候，只会加载JAVA_HOME中的jar包里面的类，如java.lang.Integer，那么这个类是不会被随意替换的，除非有人跑到你的机器上， 破坏你的JDK。

（那么，就可以避免有人自定义一个有破坏功能的java.lang.Integer被加载。这样可以有效的防止核心Java API被篡改）

“父子加载器”之间的关系是继承吗？

很多人看到父加载器、子加载器这样的名字，就会认为Java中的类加载器之间存在着继承关系。
甚至网上很多文章也会有类似的错误观点。
这里需要明确一下，双亲委派模型中，类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码的。
如下为ClassLoader中父加载器的定义：
image.png

双亲委派是怎么实现的？

双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现并不复杂。
实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中：

image.png

  1.     protected Class<?> loadClass(String name, boolean resolve)
  2.         throws ClassNotFoundException
  3.     {
  4.         synchronized (getClassLoadingLock(name)) {
  5.             // First, check if the class has already been loaded
  6.             Class<?> c = findLoadedClass(name);
  7.             if (c == null) {
  8.                 long t0 = System.nanoTime();
  9.                 try {
  10.                     if (parent != null) {
  11.                         c = parent.loadClass(name, false);
  12.                     } else {
  13.                         c = findBootstrapClassOrNull(name);
  14.                     }
  15.                 } catch (ClassNotFoundException e) {
  16.                     // ClassNotFoundException thrown if class not found
  17.                     // from the non-null parent class loader
  18.                 }
  20.                 if (c == null) {
  21.                     // If still not found, then invoke findClass in order
  22.                     // to find the class.
  23.                     long t1 = System.nanoTime();
  24.                     c = findClass(name);
  26.                     // this is the defining class loader; record the stats
  27.                     sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
  28.                     sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
  29.                     sun.misc.PerfCounter.getFindClasses().increment();
  30.                 }
  31.             }
  32.             if (resolve) {
  33.                 resolveClass(c);
  34.             }
  35.             return c;
  36.         }
  37.     }

逻辑：

  1. 先检查类是否已经被加载过
  2. 若没有加载则调用父加载器的loadClass()方法进行加载
  3. 若父加载器为空则默认使用启动类加载器作为父加载器。
  4. 如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

    如何主动破坏双亲委派机制？

    知道了双亲委派模型的实现，那么想要破坏双亲委派机制就很简单了。
    因为他的双亲委派过程都是在loadClass方法中实现的，那么想要破坏这种机制，那么就自定义一个类加载器，重写其中的loadClass方法，使其不进行双亲委派即可。

    loadClass（）、findClass（）、defineClass（）区别

    ClassLoader中和类加载有关的方法有很多，前面提到了loadClass，除此之外，还有findClass和defineClass等，那么这几个方法有什么区别呢？
  • loadClass()
    • 就是主要进行类加载的方法，默认的双亲委派机制就实现在这个方法中。
  • findClass()
    • 根据名称或位置加载.class字节码
  • definclass()
    • 把字节码转化为Class

这里面需要展开讲一下loadClass和findClass，我们前面说过，当我们想要自定义一个类加载器的时候，并且像破坏双亲委派原则时，我们会重写loadClass方法。
那么，如果我们想定义一个类加载器，但是不想破坏双亲委派模型的时候呢？
这时候，就可以继承ClassLoader，并且重写findClass方法。findClass()方法是JDK1.2之后的ClassLoader新添加的一个方法。

  1. /*** @since  1.2  */ 
  2. protected Class<?> findClass(String name) throws ClassNotFoundException {
  3.     throw new ClassNotFoundException(name); 
  4. }

这个方法只抛出了一个异常，没有默认实现。
JDK1.2之后已不再提倡用户直接覆盖loadClass()方法，而是建议把自己的类加载逻辑实现到findClass()方法中。
因为在loadClass()方法的逻辑里，如果父类加载器加载失败，则会调用自己的findClass()方法来完成加载。
所以，如果你想定义一个自己的类加载器，并且要遵守双亲委派模型，那么可以继承ClassLoader，并且在findClass中实现你自己的加载逻辑即可。

双亲委派被破坏的例子

双亲委派机制的破坏不是什么稀奇的事情，很多框架、容器等都会破坏这种机制来实现某些功能。

第一种被破坏的情况是在双亲委派出现之前。

由于双亲委派模型是在JDK1.2之后才被引入的，而在这之前已经有用户自定义类加载器在用了。所以，这些是没有遵守双亲委派原则的。

第二种，是JNDI、JDBC等需要加载SPI接口实现类的情况。
第三种是为了实现热插拔热部署工具。

为了让代码动态生效而无需重启，实现方式时把模块连同类加载器一起换掉就实现了代码的热替换。

第四种时tomcat等web容器的出现。

第五种时OSGI、Jigsaw等模块化技术的应用。

为什么JNDI，JDBC等需要破坏双亲委派？

我们日常开发中，大多数时候会通过API的方式调用Java提供的那些基础类，这些基础类时被Bootstrap加载的。
但是，调用方式除了API之外，还有一种SPI的方式。如典型的JDBC服务，我们通常通过以下方式创建数据库连接：

  1. Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql", "root", "1234");

在以上代码执行之前，DriverManager会先被类加载器加载，因为java.sql.DriverManager类是位于rt.jar下面的 ，所以他会被根加载器加载。
类加载时，会执行该类的静态方法。其中有一段关键的代码是：

  1. ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);

这段代码，会尝试加载classpath下面的所有实现了Driver接口的实现类。
那么，问题就来了。
DriverManager是被根加载器加载的，那么在加载时遇到以上代码，会尝试加载所有Driver的实现类，但是这些实现类基本都是第三方提供的，根据双亲委派原则，第三方的类不能被根加载器加载。
那么，怎么解决这个问题呢？
于是，就在JDBC中通过引入ThreadContextClassLoader（线程上下文加载器，默认情况下是AppClassLoader）的方式破坏了双亲委派原则。
我们深入到ServiceLoader.load方法就可以看到：

  1. public static <S> ServiceLoader<S> load(Class<S> service) {
  2.     ClassLoader cl = Thread.currentThread().getContextClassLoader();
  3.     return ServiceLoader.load(service, cl); 
  4. }

第一行，获取当前线程的线程上下⽂类加载器 AppClassLoader，⽤于加载 classpath 中的具体实现类。

为什么Tomcat要破坏双亲委派

我们知道，Tomcat是web容器，那么一个web容器可能需要部署多个应用程序。
不同的应用程序可能会依赖同一个第三方类库的不同版本，但是不同版本的类库中某一个类的全路径名可能是一样的。
如多个应用都要依赖hollis.jar，但是A应用需要依赖1.0.0版本，但是B应用需要依赖1.0.1版本。这两个版本中都有一个类是com.hollis.Test.class。
如果采用默认的双亲委派类加载机制，那么是无法加载多个相同的类。
所以，Tomcat破坏双亲委派原则，提供隔离的机制，为每个web容器单独提供一个WebAppClassLoader加载器。
Tomcat的类加载机制：为了实现隔离性，优先加载 Web 应用自己定义的类，所以没有遵照双亲委派的约定，每一个应用自己的类加载器——WebAppClassLoader负责加载本身的目录下的class文件，加载不到时再交给CommonClassLoader加载，这和双亲委派刚好相反。