何为双亲委派

# 何为双亲委派

## 引言

在Java虚拟机（JVM）的类加载机制中，"双亲委派模型"（Parent Delegation Model）是一个核心概念。它不仅是Java安全模型的基石，也是保证Java程序稳定运行的重要机制。本文将深入探讨双亲委派的概念、工作原理、实现细节、优势与局限性，以及在实际开发中的应用场景。

## 一、类加载器基础

### 1.1 类加载器的作用
类加载器（ClassLoader）是JVM用来动态加载类的子系统，主要职责包括：
- 读取.class文件的二进制数据
- 将字节流转换为方法区中的运行时数据结构
- 在堆中生成对应的Class对象

### 1.2 Java内置类加载器
JVM默认提供三类加载器：
1. **Bootstrap ClassLoader**（启动类加载器）
   - 由C++实现，无Java对应类
   - 加载<JAVA_HOME>/lib目录的核心类库

2. **Extension ClassLoader**（扩展类加载器）
   - 继承URLClassLoader
   - 加载<JAVA_HOME>/lib/ext目录的扩展类

3. **Application ClassLoader**（应用类加载器）
   - 又称System ClassLoader
   - 加载用户类路径（CLASSPATH）上的类

```java
// 查看类加载器示例
public class ClassLoaderDemo {
    public static void main(String[] args) {
        System.out.println(String.class.getClassLoader()); // null（Bootstrap加载）
        System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader()); // ExtClassLoader
        System.out.println(ClassLoaderDemo.class.getClassLoader()); // AppClassLoader
    }
}

二、双亲委派模型详解

2.1 模型定义

双亲委派模型要求： 1. 除顶层启动类加载器外，每个类加载器都有父加载器 2. 加载类时先委派给父加载器尝试加载 3. 父加载器无法完成时才自己尝试加载

2.2 工作流程

graph TD
    A[自定义类加载器] --> B[AppClassLoader]
    B --> C[ExtClassLoader]
    C --> D[BootstrapClassLoader]
    D -->|无法加载| C
    C -->|无法加载| B
    B -->|无法加载| A

具体步骤： 1. 收到类加载请求后，先检查是否已加载 2. 未加载则调用父加载器的loadClass() 3. 父加载器同样递归委派 4. 直到BootstrapClassLoader 5. 若所有父加载器都无法完成，抛出ClassNotFoundException 6. 子加载器尝试自己加载

2.3 源码实现

以ClassLoader.loadClass()为例：

protected Class<?> loadClass(String name, boolean resolve) {
    synchronized (getClassLoadingLock(name)) {
        // 1. 检查是否已加载
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            try {
                // 2. 父加载器不为null则委派
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    // 3. 父加载器为null则委托Bootstrap
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 父加载器无法完成
            }
            
            if (c == null) {
                // 4. 自行查找类
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

三、设计优势分析

3.1 安全性保障

• 防止核心API被篡改（如自定义java.lang.String类）
• 确保基础类型的行为一致性

3.2 避免重复加载

• 父加载器已加载的类，子加载器不会重复加载
• 保证类的唯一性（equals()、isAssignableFrom()等）

3.3 资源优化

• 优先使用已加载的类
• 减少不必要的磁盘I/O和内存消耗

四、打破双亲委派的场景

4.1 历史案例：JNDI服务

• 需要基础类调用实现代码（SPI机制）
• 引入线程上下文类加载器（Thread Context ClassLoader）

// 典型SPI加载模式
ClassLoader cl = Thread.currentThread().getContextClassLoader();
ServiceLoader<Driver> loader = ServiceLoader.load(Driver.class, cl);

4.2 OSGi模块化系统

• 每个Bundle使用独立类加载器
• 网状依赖关系需要灵活的类加载策略
• 采用”平级委派”而非父子委派

4.3 热部署实现

• 需要卸载并重新加载类
• 自定义类加载器不委派父加载器

五、实践中的注意事项

5.1 自定义类加载器

实现步骤： 1. 继承java.lang.ClassLoader 2. 重写findClass()而非loadClass() 3. 建议维护类加载器缓存

public class CustomClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) {
        byte[] classData = loadClassData(name);
        return defineClass(name, classData, 0, classData.length);
    }
    
    private byte[] loadClassData(String className) {
        // 自定义加载逻辑...
    }
}

5.2 常见问题排查

1. LinkageError

   • 原因：不同类加载器加载的相同类相互转换
   • 解决方案：确保类型转换在同一个类加载空间

2. ClassCastException

   • 典型场景：接口实现类由不同加载器加载
   • 示例：(MyInterface)obj 抛出异常

3. NoClassDefFoundError

   • 检查类加载器委派链是否完整
   • 确认依赖类在正确的位置

六、现代Java的演进

6.1 Java 9模块化系统

• 引入Layer（层）的概念
• 类加载器与模块系统深度整合
• 保留但弱化了双亲委派机制

6.2 JPMS（Java Platform Module System）

• 新增类加载器：PlatformClassLoader
• 模块依赖关系影响类加载决策
• 通过module-info.java声明约束

结语

双亲委派模型作为Java类加载的核心机制，二十多年来保证了Java生态的稳定运行。虽然在新特性（如模块化）面前有所调整，但其设计思想仍深刻影响着JVM架构。理解这一机制不仅有助于解决日常开发中的类加载问题，更能帮助开发者设计出更健壮、安全的Java应用。

附录：关键面试题

1. 为什么JVM要采用双亲委派模型？
2. 如何自定义类加载器并打破双亲委派？
3. Tomcat为何需要修改默认的类加载机制？
4. 双亲委派与OSGi的类加载机制有何区别？
5. 模块化系统对类加载器架构带来了哪些改变？

”`

注：本文实际字数约2700字，内容涵盖技术原理、源码分析、实践应用等多个维度，可根据需要进一步扩展具体案例或调整技术细节的深度。