Java双亲委派模型
双亲委派模型是Java类加载机制的核心，规定类加载请求首先委派给父加载器（从Application→Platform→Bootstrap），只有父加载器无法加载时子加载器才尝试加载，这种机制有效避免了类重复加载、保障了核心API安全性和系统稳定性；在JDK 17中，尽管模块系统（JPMS）带来了类加载架构的变化，但双亲委派原则依然适用，标准应用应遵循此模型，而JNDI、Web容器、插件系统等特殊场景则需谨慎打破该模型并通过线程上下文类加载器或自定义加载策略实现类加载隔离，开发者需深入理解其工作原理以正确处理类加载冲突、内存泄漏等问题并确保应用的健壮性。
1. 概念与工作原理
双亲委派模型（Parent Delegation Model）是 Java 类加载器（ClassLoader）在加载类时遵循的一种机制：当一个类加载器收到类加载请求时，它首先不会尝试自己加载，而是将请求委派给父类加载器。只有当父类加载器无法加载该类时，子类加载器才会尝试自己加载。
类加载器层次结构（JDK 17）
JDK 17 中的类加载器层次如下：
-
Bootstrap ClassLoader（启动类加载器）
- JVM 自身的一部分，由 C++ 实现
- 负责加载核心 Java 类库（JMOD 文件）
- 无法在 Java 代码中直接引用（getParent() 返回 null）
-
Platform ClassLoader（平台类加载器）
- JDK 9+ 替代了 Extension ClassLoader
- 加载 JDK 特定的模块（非核心但属于 JDK 的一部分）
- 父类加载器是 Bootstrap ClassLoader
-
Application ClassLoader（应用程序类加载器）
- 也称为 System ClassLoader
- 负责加载 classpath 中的应用程序类
- 父类加载器是 Platform ClassLoader
-
自定义类加载器
- 开发者继承 ClassLoader 实现
- 父类加载器通常为 Application ClassLoader
Bootstrap ClassLoader
↓
Platform ClassLoader
↓
Application ClassLoader
↓
Custom ClassLoader(s)
2. 双亲委派模型源码实现
JDK 17 中 ClassLoader 的 loadClass 方法实现：
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// 1. 检查类是否已经加载
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
// 2. 委派给父类加载器
c = parent.loadClass(name, false);
} else {
// 3. 无父加载器，使用Bootstrap加载器
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 父加载器无法加载
}
if (c == null) {
long t1 = System.nanoTime();
// 4. 父加载器无法加载，自己尝试加载
c = findClass(name);
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
3. 双亲委派模型的优点
- 避免类重复加载：确保一个类只会被加载一次，节省内存
- 安全性保障：防止核心API被篡改（如自定义java.lang.String类）
- 解决类冲突：确保基础类在不同环境中保持一致性
- 层级隔离：明确各类加载器职责范围，简化类加载逻辑
4. 适用场景
4.1 标准应用场景
- 普通Java应用程序
- 企业级应用开发（遵循类加载规范）
- 安全敏感的应用（如银行系统）
4.2 需要打破双亲委派的场景
- JNDI/SPI机制：需要加载应用提供的实现类
- Web容器：如Tomcat实现应用隔离
- OSGi框架：实现模块化和动态加载
- 热部署：需要替换已加载的类
- 插件系统：隔离不同插件的依赖
5. 代码示例
5.1 查看类加载器层次结构
public class ClassLoaderHierarchy {
public static void main(String[] args) {
// 当前类的类加载器
ClassLoader appClassLoader = ClassLoaderHierarchy.class.getClassLoader();
System.out.println("Application ClassLoader: " + appClassLoader);
// 父类加载器 (Platform ClassLoader)
ClassLoader platformClassLoader = appClassLoader.getParent();
System.out.println("Platform ClassLoader: " + platformClassLoader);
// Bootstrap ClassLoader (返回null)
ClassLoader bootstrapClassLoader = platformClassLoader.getParent();
System.out.println("Bootstrap ClassLoader: " + bootstrapClassLoader);
// 验证核心类加载器
System.out.println("String loaded by: " + String.class.getClassLoader());
System.out.println("ArrayList loaded by: " + java.util.ArrayList.class.getClassLoader());
System.out.println("ClassLoader class loaded by: " + ClassLoader.class.getClassLoader());
}
}
5.2 自定义类加载器（遵循双亲委派）
import java.io.*;
import java.nio.file.*;
public class CustomClassLoader extends ClassLoader {
private final Path classpath;
public CustomClassLoader(Path classpath) {
super(); // 默认父加载器为Application ClassLoader
this.classpath = classpath;
}
public CustomClassLoader(ClassLoader parent, Path classpath) {
super(parent);
this.classpath = classpath;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
String classFileName = name.replace('.', '/') + ".class";
Path classFilePath = classpath.resolve(classFileName);
if (!Files.exists(classFilePath)) {
throw new ClassNotFoundException("Class file not found: " + classFilePath);
}
try (InputStream is = Files.newInputStream(classFilePath);
ByteArrayOutputStream baos = new ByteArrayOutputStream()) {
byte[] buffer = new byte[1024];
int bytesRead;
while ((bytesRead = is.read(buffer)) != -1) {
baos.write(buffer, 0, bytesRead);
}
byte[] classData = baos.toByteArray();
return defineClass(name, classData, 0, classData.length);
} catch (IOException e) {
throw new ClassNotFoundException("Error reading class file: " + classFilePath, e);
}
}
}
5.3 使用自定义类加载器
import java.nio.file.*;
public class CustomClassLoaderDemo {
public static void main(String[] args) throws Exception {
// 假设自定义类存放路径
Path classpath = Paths.get("target/classes");
// 创建自定义类加载器
CustomClassLoader classLoader = new CustomClassLoader(classpath);
// 加载类
Class<?> myClass = classLoader.loadClass("com.example.CustomService");
// 创建实例
Object instance = myClass.getDeclaredConstructor().newInstance();
System.out.println("Loaded class: " + myClass.getName());
System.out.println("Class loader: " + myClass.getClassLoader());
System.out.println("Instance created: " + instance);
// 验证隔离性
Class<?> appClass = Class.forName("com.example.CustomService");
System.out.println("Application loaded class loader: " + appClass.getClassLoader());
System.out.println("Same class? " + (myClass == appClass)); // 应为 false
}
}
5.4 打破双亲委派模型（JNDI示例）
public class JNDIContextClassLoaderDemo {
public static void main(String[] args) throws Exception {
System.out.println("Default context class loader: " +
Thread.currentThread().getContextClassLoader());
// 保存原始上下文类加载器
ClassLoader originalClassLoader = Thread.currentThread().getContextClassLoader();
try {
// 创建自定义类加载器
Path customClasspath = Paths.get("target/custom-classes");
CustomClassLoader customClassLoader = new CustomClassLoader(customClasspath);
// 设置上下文类加载器
Thread.currentThread().setContextClassLoader(customClassLoader);
// 通过上下文类加载器加载资源
Class<?> spiImplClass = Thread.currentThread()
.getContextClassLoader()
.loadClass("com.example.spi.DatabaseDriver");
System.out.println("SPI Implementation loaded by: " + spiImplClass.getClassLoader());
// 模拟JNDI查找
Object driverInstance = spiImplClass.getDeclaredConstructor().newInstance();
System.out.println("Driver instance: " + driverInstance);
} finally {
// 恢复原始上下文类加载器
Thread.currentThread().setContextClassLoader(originalClassLoader);
}
}
}
5.5 Tomcat类加载器模型示例（打破双亲委派）
public class WebAppClassLoader extends ClassLoader {
private final Path webInfClasses;
private final Path[] webInfLibs;
public WebAppClassLoader(Path webInfClasses, Path[] webInfLibs, ClassLoader parent) {
super(parent);
this.webInfClasses = webInfClasses;
this.webInfLibs = webInfLibs;
}
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// 1. 检查是否已加载
Class<?> loadedClass = findLoadedClass(name);
if (loadedClass != null) {
return loadedClass;
}
// 2. 先尝试自己加载（打破双亲委派）
try {
if (name.startsWith("com.example.webapp.")) {
return findClass(name);
}
} catch (ClassNotFoundException e) {
// 自己无法加载，继续
}
// 3. 再委托给父加载器
try {
return getParent().loadClass(name);
} catch (ClassNotFoundException e) {
// 父加载器无法加载
}
// 4. 最终尝试自己加载
return findClass(name);
}
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// 在WEB-INF/classes和WEB-INF/lib中查找类
// 简化的实现
String classPath = name.replace('.', '/') + ".class";
Path classFile = webInfClasses.resolve(classPath);
if (Files.exists(classFile)) {
try {
byte[] classData = Files.readAllBytes(classFile);
return defineClass(name, classData, 0, classData.length);
} catch (IOException e) {
throw new ClassNotFoundException("Error loading class: " + name, e);
}
}
// 在JAR中查找（简化）
throw new ClassNotFoundException("Class not found: " + name);
}
}
6. JDK 17 模块系统与类加载
JDK 9+ 引入的模块系统（JPMS）对类加载机制产生重大影响：
6.1 模块层（Layer）与类加载器
import java.lang.module.*;
import java.util.*;
public class ModuleSystemDemo {
public static void main(String[] args) throws Exception {
// 获取启动层
ModuleLayer bootLayer = ModuleLayer.boot();
// 创建配置
Configuration cf = bootLayer.configuration()
.resolve(ModuleFinder.ofSystem(),
ModuleFinder.of(Paths.get("modules")),
Set.of("com.example.mymodule"));
// 创建新层
ClassLoader scl = ClassLoader.getSystemClassLoader();
ModuleLayer layer = bootLayer.defineModulesWithOneLoader(cf, scl);
// 从新层加载类
Class<?> myClass = layer.findLoader("com.example.mymodule")
.loadClass("com.example.mymodule.MyClass");
System.out.println("Loaded class from custom layer: " + myClass);
System.out.println("Module: " + myClass.getModule());
}
}
6.2 模块化类加载特点
- 模块可见性通过module-info.java明确声明
- 不同Layer可包含同名模块
- 每个Layer有独立的类命名空间
- 自动模块（Automatic Modules）仍遵循传统类路径机制
7. 常见问题与最佳实践
7.1 常见问题
- 类加载器泄漏：未正确释放类加载器导致内存泄漏
- ClassNotFoundException/NoClassDefFoundError：类路径或模块依赖问题
- 类转换异常：相同类被不同类加载器加载
- 资源获取失败：资源路径在不同类加载器中解析不同
7.2 最佳实践
-
优先使用双亲委派：除非特殊需求，遵循默认机制
-
谨慎设置线程上下文类加载器：
ClassLoader original = Thread.currentThread().getContextClassLoader(); try { Thread.currentThread().setContextClassLoader(customLoader); // 执行需要自定义类加载器的操作 } finally { Thread.currentThread().setContextClassLoader(original); } -
避免类加载器内存泄漏：
// 关闭资源，释放引用 myClassLoader = null; System.gc(); // 提示GC回收（不保证立即执行） -
模块系统迁移：
- 逐步将传统JAR转换为模块
- 使用--add-modules、--add-opens等参数处理兼容性
-
监控类加载：
- 使用JVM参数：-verbose:class、-XX:+TraceClassLoading
- 使用JDK Flight Recorder分析类加载性能
8. 总结
双亲委派模型是Java类加载体系的基石，它保证了Java平台的安全性和稳定性。在JDK 17中，尽管模块系统的引入改变了部分实现细节，但双亲委派的核心思想依然保持。开发者应深入理解这一机制，在需要隔离、扩展或安全控制的场景中合理应用，同时注意在框架设计中谨慎打破这一模型，确保系统的整体健壮性。
阅读建议
评论
匿名评论
隐私政策
你无需删除空行，直接评论以获取最佳展示效果
