Java 类加载规则深度解析：从双亲委派到 JDBC 与 Tomcat 的突破

Java 的类加载机制是 JVM 的核心特性，决定了类文件如何被加载并运行。理解这一机制能帮助我们优化代码并解决类加载问题。本文将从基础讲起，逐步分析类加载器的职责（尤其扩展类加载器）、双亲委派模型，以及 JDBC 和 Tomcat 如何打破这一模型。

一、Java 类加载器的基础

JVM 提供了三种类加载器，它们按层次结构协作：

Bootstrap ClassLoader（启动类加载器）
- 用 C++ 实现，嵌入在 JVM 中。
- 加载 Java 核心类库（如 <JAVA_HOME>/jre/lib/rt.jar 中的 java.lang.*、java.util.*）。
- 是所有类加载器的顶层父类，在 Java 中无法直接获取（getClassLoader() 返回 null）。
Extension ClassLoader（扩展类加载器）
- 用 Java 实现（sun.misc.Launcher$ExtClassLoader）。
- 加载扩展类库，通常位于 <JAVA_HOME>/jre/lib/ext 下的 .jar 文件，或由系统属性 java.ext.dirs 指定的路径。
- 父类加载器是 Bootstrap ClassLoader。
扩展类加载器的详细职责

Extension ClassLoader 的设计初衷是为 Java 提供一个扩展机制，允许用户在不修改核心类库的情况下添加功能。它加载的类介于核心类和用户类之间，具有一定的优先级。

具体例子
- 默认扩展库 ：在 <JAVA_HOME>/jre/lib/ext 下，JDK 自带了一些扩展包，例如：
  - dnsns.jar：支持 DNS 名称服务的类。
  - localedata.jar：提供本地化数据支持。
- 自定义扩展 ：假设你开发了一个工具库 mytools.jar，包含类 com.example.MyTool：
  1. 将 mytools.jar 放入 <JAVA_HOME>/jre/lib/ext。
  2. 在代码中直接使用 com.example.MyTool，无需在类路径中显式指定。
  3. Extension ClassLoader 会加载这个类，而无需 Application ClassLoader 介入。
使用场景
- 如果你想为所有 Java 应用提供一个全局工具（如日志增强库），可以将其放入 ext 目录。
- 通过 -Djava.ext.dirs=/custom/path 指定自定义路径，例如加载 /usr/lib/java-extensions 下的扩展库。
注意事项
- 扩展类优先级高于应用程序类，但低于核心类。
- 不建议过度使用，因为它会影响应用的隔离性（所有应用共享同一版本）。
Application ClassLoader（应用类加载器）
- 用 Java 实现（sun.misc.Launcher$AppClassLoader）。
- 加载应用程序类路径（classpath）下的类，包括用户代码和第三方库。
- 父类加载器是 Extension ClassLoader。

职责划分

Bootstrap ：核心类（如 java.lang.String）。
Extension ：扩展类（如 com.example.MyTool）。
Application ：用户类（如你的 Main 类）。

二、双亲委派模型的工作原理

双亲委派模型是 Java 类加载的默认规则，规定了加载器的协作方式。

工作流程

向上委托：Application ClassLoader 接到请求，先委托给 Extension ClassLoader，再委托给 Bootstrap ClassLoader。
向下尝试：Bootstrap 尝试加载，失败则由 Extension 尝试，再失败由 Application 加载。
异常抛出 ：若都失败，抛出 ClassNotFoundException。

设计目的

安全性：防止用户覆盖核心类。
唯一性：避免重复加载。

三、JDBC 如何用线程上下文类加载器打破双亲委派

JDBC 的核心类（如 java.sql.DriverManager）由 Bootstrap ClassLoader 加载，而具体驱动（如 com.mysql.jdbc.Driver）由 Application ClassLoader 加载。

双亲委派的困境

Bootstrap ClassLoader 无法直接加载应用程序中的驱动类。

线程上下文类加载器的解决

DriverManager 通过 ServiceLoader 加载驱动。
ServiceLoader 使用线程上下文类加载器（通常是 Application ClassLoader）加载具体驱动。
高层（Bootstrap）依赖低层（Application）加载的类，打破"父类优先"规则。

四、Tomcat 如何打破双亲委派

Tomcat 是一个 Servlet 容器，需要支持多个 Web 应用的独立运行，每个应用可能使用不同版本的类库。

Tomcat 的类加载器体系

Common ClassLoader ：加载共享类（tomcat/lib）。
Catalina ClassLoader：加载 Tomcat 自身类。
Webapp ClassLoader ：为每个 Web 应用独立创建，加载 WEB-INF/lib 和 WEB-INF/classes 中的类。
Shared ClassLoader（可选）：多个 Web 应用共享某些类。

打破双亲委派的详细机制

Tomcat 的 Webapp ClassLoader 不严格遵循双亲委派，而是采用"优先本地"的策略：

加载顺序
- 当一个类（如 com.example.MyServlet）需要加载时：
  1. Webapp ClassLoader 先尝试从 WEB-INF/lib 或 WEB-INF/classes 加载。
  2. 如果本地找不到，才委托给父类加载器（Common ClassLoader）。
- 这与双亲委派的"先父后子"相反。

实现细节

Webapp ClassLoader 重写了 loadClass() 方法：

java 复制代码

public Class<?> loadClass(String name) throws ClassNotFoundException {
    // 先尝试本地加载
    Class<?> clazz = findLoadedClass(name); // 检查是否已加载
    if (clazz == null) {
        try {
            clazz = findClass(name); // 从本地路径加载
        } catch (ClassNotFoundException e) {
            // 本地失败，委托父类
            clazz = getParent().loadClass(name);
        }
    }
    return clazz;
}

默认的双亲委派实现会先调用 getParent().loadClass()，而 Tomcat 颠倒了顺序。

具体例子
- 假设有两个 Web 应用：
  - webapp1/WEB-INF/lib/log4j-1.2.jar
  - webapp2/WEB-INF/lib/log4j-2.0.jar
- webapp1 的 Webapp ClassLoader 加载 log4j-1.2，webapp2 加载 log4j-2.0，互不干扰。
- 如果用双亲委派，Application ClassLoader 会加载同一版本的 log4j，导致冲突。
为什么要打破？
- 隔离性：确保每个 Web 应用的类库独立。
- 灵活性：支持同一服务器上运行不同版本的依赖。
与双亲委派的结合
- 对于共享类（如 Servlet API），仍委托给 Common ClassLoader，保证一致性。
- 只有应用特有类才优先本地加载。

五、总结

Java 的类加载机制通过三层加载器和双亲委派模型实现了安全与一致性：

Bootstrap：核心类。
Extension ：扩展类（如 mytools.jar）。
Application：用户类。

但在特定场景下：

JDBC：通过线程上下文类加载器，让 Bootstrap 访问 Application 加载的驱动。
Tomcat：通过 Webapp ClassLoader 优先加载本地类，实现应用隔离。

Java 类加载规则深度解析：从双亲委派到 JDBC 与 Tomcat 的突破