Tomcat的非双亲委派加载

一、tomcat的非双亲委派加载

双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。

【违背双亲委派】： tomcat 为了实现隔离性，没有遵守这个约定，每个 webappClassLoader 加载自己的目录下的 class 文件，不会传递给父类加载器。例如：如果 tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类，该怎么办？我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作。

tomcat 为了实现隔离性和热替换，没有使用默认的类加载器，而是自己实现了类加载器： 一个 web 容器可能要部署两个或者多个应用程序，不同的应用程序，可能会依赖同一个第三方类库的不同版本，因此要保证每一个应用程序的类库都是独立、相互隔离的。

【违背双亲委派三个方面】：（1）向前兼容；（2）加载 SPI 接口实现类；（3）热部署

【Tomcat 类加载过程】：

tomcat 的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础类 (Object,String 等)，各个 web 应用自己的类加载器 (WebAppClassLoader) 会优先加载，加载不到时再交给 commonClassLoader 走双亲委托。具体的加载逻辑位于 WebAppClassLoaderBase.loadClass() 方法中，这里以文字描述加载一个类过程：

先在本地缓存中查找是否已经加载过该类 (对于一些已经加载了的类，会被缓存在 resourceEntries 这个数据结构中)，如果已经加载即返回，否则 继续下一步。
让系统类加载器 (AppClassLoader) 尝试加载该类，主要是为了防止一些基础类会被 web 中的类覆盖，如果加载到即返回，返回继续。
前两步均没加载到目标类，那么 web 应用的类加载器将自行加载，如果加载到则返回，否则继续下一步。
最后还是加载不到的话，则委托父类加载器 (Common ClassLoader) 去加载。

---

二、实现机制——线程上下文类加载器

Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。而问题在于，SPI 的接口是 Java 核心库的一部分，是由引导类加载器来加载的；SPI 实现的 Java 类一般是由系统类加载器来加载的。引导类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的代理模式无法解决这个问题。

线程上下文类加载器正好解决了这个问题。如果不做任何的设置，Java 应用的线程的上下文类加载器默认就是系统上下文类加载器。在 SPI 接口的代码中使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。线程上下文类加载器在很多 SPI 的实现中都会用到。

使用线程上下文类加载器，可以在执行线程中抛弃双亲委派加载链模式，使用线程上下文里的类加载器加载类。典型的例子有：通过线程上下文来加载第三方库 jndi 实现，而不依赖于双亲委派。大部分 java application 服务器 (jboss, tomcat…) 也是采用 contextClassLoader 来处理 web 服务。还有一些采用 hot swap 特性的框架，也使用了线程上下文类加载器，比如 seasar (full stack framework in japenese)。线程上下文从根本解决了一般应用不能违背双亲委派模式的问题。

---

【Java 面试那点事】

这里致力于分享 Java 面试路上的各种知识，无论是技术还是经验，你需要的这里都有！

这里可以让你【快速了解 Java 相关知识】，并且【短时间在面试方面有跨越式提升】

面试路上，你不孤单！