Java类加载器和双亲委派模型及Tomcat/SPI为什么要打破双亲委派

JDK 提供的三层类加载器

Bootstrap ClassLoader

启动类加载器，最顶层的类加载器，任何类的加载都要询问它，主要用于加载核心类库JAVA_HOME/lib目录下的jar包，比如rt.jar、resources.jar、charsets.jar。
也可以通过-Xbootclasspath参数手动指定加载路径。
这个加载器是C++编写的，随着 JVM 启动，通过代码获取为null。

Extention ClassLoader

扩展类加载器，主要用于加载JAVA_HOME/lib/ext/目录下的jar包。也可以通过系统变量java.ext.dirs参数手动指定加载路径。
这个加载器是个Java类，继承自URLClassLoader。

Application ClassLoader

应用程序类加载器，有时候也叫作System ClassLoader。负责加载我们应用程序里classpath下的类库。我们写的代码，会首先尝试使用这个类加载器进行加载。

我们可以通过继承java.lang.ClassLoader类实现自定义的类加载器，做一些个性化的扩展功能。

类加载器的问题

虽然类加载器做了分类分工，但如果某用户自己编写了一个java.lang.Object的类，并放在程序的classpath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为就无法保证，应用程序也会变得一片混乱。
为了核心API库不被随意篡改，便出现了双亲委派模型。

双亲委派模型

当一个类收到了类加载请求时，他不会尝试自己去加载这个类，而是把这个请求委派给上一层加载器询问是否已加载，每一个层次类加载器都是如此，只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到请求加载的Class），子类加载器才会尝试自己去加载。

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承(Inheritance)的关系来实现，而是都使用组合(Composition)关系来复用父加载器的代码。

这样的话，即使有用户在自己的项目中写了java.lang.Object的类，也不会被加载，因为顶层类加载器已经加载了。

双亲委派模型的好处：保证了JVM的安全、稳定运行。

看ClassLoader源码的加载逻辑：

public abstract class ClassLoader {
     
	// ...
	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;
        }
    }
	// ...
}

ClassLoader的loadClass()方法，首先使用 parent 尝试进行类加载，parent 失败后才轮到自己。同时，我们也注意到，这个方法是可以被覆盖的，也就是双亲委派机制并不一定生效（双亲委派可以被打破）。

自定义类加载器

Tomcat 类加载器

Tomcat实现了四个自己的类加载器，Catania类加载器负责加载catania.sh中指定的启动类，Shard类加载器负责加Tomcat/lib下共享的类库。需要注意的是Catania类加载器、Shard类加载器是遵循双亲委派模型的。
部署在Tomcat/webapps下的*.war包项目，首先会尝试WebAppClassLoader类加载器进行加载，等它加载不到的时候，再交给上层的ClassLoader进行加载。 这样Tomcat就打破了双亲委派机制。

Tomcat的类加载器的目的：

1、为了实现隔离性。对于各个 webapp中的 class和 lib需要相互隔离，不能出现一个应用中加载的类库会影响另一个应用的情况。
2、为了实现共享。对于许多应用都会用到的类库放在共享目录用Shared类加载器加载，以便不浪费资源。
3、与JVM一样的安全性问题。使用单独的ClassLoader去装载Tomcat自身的类库，以免其他恶意或无意的破坏。
4、热部署。Tomcat可以实现修改文件不用重启就自动重新装载类库的功能。

SPI机制

SPI（Service Provider Interface）机制，是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。

按双亲委派机制，SPI的实现父类加载器无法加载到具体的实现类，这时候就需要子类加载器去加载class文件。这样SPI就打破了双亲委派机制。

以JDBC举例，DriverManager类和ServiceLoader类都是属于 rt.jar 的，它们的类加载器是Bootstrap ClassLoader顶层类加载器。而具体的数据库驱动却属于业务代码，这是启动类加载器是无法加载的。所以java.util.ServiceLoader类进行动态装载时，使用了线程的上下文类加载器进行加载。