双亲委派模型

本文深入探讨Java类加载过程,解析双亲委派模型的工作原理及其优势,并通过实例演示不同类加载器之间的区别。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

说道双亲委派模型,就要从类加载器说起~

Java虚拟机类加载过程是把Class类文件加载到内存,并对Class文件中的数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的java类型的过程。

在加载阶段,java虚拟机需要完成以下3件事:

a.通过一个类的全限定名来获取定义此类的二进制字节流。

b.将定义类的二进制字节流所代表的静态存储结构转换为方法区的运行时数据结构

c.在java堆中生成一个代表该类的java.lang.Class对象,作为方法区数据的访问入口。

而类的加载过程是通过类加载器完成的。


在Java中,任意一个类都需要由加载它的类加载器和这个类本身一同确定其在java虚拟机中的唯一性,即比较两个类是否相等,只有在这两个类是由同一个类加载器加载的前提之下才有意义,否则,即使这两个类来源于同一个Class类文件,只要加载它的类加载器不相同,那么这两个类必定不相等(这里的相等包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法和instanceof关键字的结果)。

看下面的例子: copy

  1. package com.test;    
  2.     
  3. public class ClassLoaderTest {    
  4.     public static void main(String[] args)throws Exception{    
  5.         //匿名内部类实现自定义类加载器    
  6.     ClassLoader myClassLoader = new ClassLoader(){    
  7.     protected Class<?> findClass(String name)throws ClassNotFoundException{    
  8.         //获取类文件名    
  9.     String filename = name.substring(name.lastIndexOf(“.”) + 1) + “.class”;    
  10.     InputStream in = getClass().getResourceAsStream(filename);    
  11.     if(in == null){    
  12.     throw RuntimeException(“Could not found class file:” + filename);    
  13. }    
  14. byte[] b = new byte[in.available()];    
  15. return defineClass(name, b, 0, b.length);    
  16. }catch(IOException e){    
  17.     throw new ClassNotFoundException(name);    
  18. }    
  19. };    
  20. Object obj = myClassLoader.loadClass(“com.test.ClassLoaderTest”).newInstance();    
  21. System.out.println(obj.getClass());    
  22. System.out.println(obj instanceof com.test. ClassLoaderTest);    
  23. }    
  24. }    

输出结果如下:

com.test.ClassLoaderTest

false

之所以instanceof会返回false,是因为com.test.ClassLoaderTest类默认使用Application ClassLoader加载,而obj是通过自定义类加载器加载的,类加载不相同,因此不相等。


说到这里就轮到双亲委派模型出场了。

先看双亲委派模型的经典体系统:


做一个简单解释:

(1).BootStrap ClassLoader:启动类加载器,负责加载存放在%JAVA_HOME%\lib目录中的,或者通被-Xbootclasspath参数所指定的路径中的,并且被java虚拟机识别的(仅按照文件名识别,如rt.jar,名字不符合的类库,即使放在指定路径中也不会被加载)类库到虚拟机的内存中,启动类加载器无法被java程序直接引用。

(2).Extension ClassLoader:扩展类加载器,由sun.misc.Launcher$ExtClassLoader实现,负责加载%JAVA_HOME%\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。

(3).Application ClassLoader:应用程序类加载器,由sun.misc.Launcher$AppClassLoader实现,负责加载用户类路径classpath上所指定的类库,是类加载器ClassLoader中的getSystemClassLoader()方法的返回值,开发者可以直接使用应用程序类加载器,如果程序中没有自定义过类加载器,该加载器就是程序中默认的类加载器。


这里需要注意的是上述三个JDK提供的类加载器虽然是父子类加载器关系,但是没有使用继承,而是使用了组合关系。

从JDK1.2开始,java虚拟机规范推荐开发者使用双亲委派模式(ParentsDelegation Model)进行类加载,其加载过程如下:

(1).如果一个类加载器收到了类加载请求,它首先不会自己去尝试加载这个类,而是把类加载请求委派给父类加载器去完成。

(2).每一层的类加载器都把类加载请求委派给父类加载器,直到所有的类加载请求都应该传递给顶层的启动类加载器。

(3).如果顶层的启动类加载器无法完成加载请求,子类加载器尝试去加载,如果连最初发起类加载请求的类加载器也无法完成加载请求时,将会抛出ClassNotFoundException,而不再调用其子类加载器去进行类加载。

双亲委派 模式的类加载机制的优点是java类它的类加载器一起具备了一种带优先级的层次关系,越是基础的类,越是被上层的类加载器进行加载,保证了java程序的稳定运行。双亲委派模式的实现: copy
  1. protected synchronized Class<?> loadClass(String name, Boolean resolve) throws ClassNotFoundException{    
  2.     //首先检查请求的类是否已经被加载过    
  3.     Class c = findLoadedClass(name);    
  4.     if(c == null){    
  5.     try{    
  6.         if(parent != null){//委派父类加载器加载    
  7.     c = parent.loadClass(name, false);    
  8. }    
  9. else{//委派启动类加载器加载    
  10.     c = findBootstrapClassOrNull(name);     
  11. }    
  12. }catch(ClassNotFoundException e){    
  13.     //父类加载器无法完成类加载请求    
  14. }    
  15. if(c == null){//本身类加载器进行类加载    
  16.     c = findClass(name);    
  17. }    
  18. }    
  19. if(resolve){    
  20.     resolveClass(c);    
  21. }    
  22. return c;    
通过双亲委派模型我们就能很好解决文章开始我们自定义的类加载器所出现的问题。

这里需要注意的是在JDK1.2之前,类加载尚未引入双亲委派模式,因此实现自定义类加载器时常常重写loadClass方法,提供双亲委派逻辑,从JDK1.2之后,双亲委派模式已经被引入到类加载体系中,自定义类加载器时不需要在自己写双亲委派的逻辑,因此不鼓励重写loadClass方法,而推荐重写findClass方法。


转自http://blog.youkuaiyun.com/p10010/article/details/50448491~

<think>我们正在讨论Java中的双亲委派模型及其工作原理。根据引用内容,双亲委派模型是Java类加载机制中的一种重要模型,它通过特定的层次结构和委派机制来确保类的唯一性和安全性。首先,类加载器之间的层次关系被称为双亲委派模型。该模型要求除了顶层的启动类加载器外,其余的类加载器都应该有自己的父类加载器(通过组合关系实现)。类加载器在加载类时,首先会委托给父类加载器去尝试加载,只有当父类加载器无法完成加载时,才由自己来加载。双亲委派模型的工作过程如下:1.当一个类加载器收到类加载请求时,它不会自己先尝试加载,而是将这个请求委派给父类加载器完成。2.每一层的类加载器都是如此,因此所有的加载请求最终都会传送到顶层的启动类加载器。3.只有当父类加载馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。双亲委派模型的好处是:-确保核心库的类型安全:例如`java.lang.Object`类,无论哪一个类加载器要加载这个类,最终都会委派给启动类加载器加载,这样就保证了Object类在各种类加载器环境中都是同一个类。-避免重复加载:父类加载器已经加载的类,子类加载器不会再加载。-防止核心API被篡改:如果没有双亲委派模型,用户自定义了一个`java.lang.Object`类,那么系统中就会出现多个不同的Object类,导致混乱。在Java中,类加载器分为几种(引用中提到了四种,但通常我们分为三种):1.启动类加载器(BootstrapClassLoader):加载JAVA_HOME/lib目录下的核心类库,如rt.jar。它是虚拟机的一部分,由C++实现,不是Java类。2.扩展类加载器(ExtensionClassLoader):负责加载JAVA_HOME/lib/ext目录下的扩展类。3.应用程序类加载器(ApplicationClassLoader):也称为系统类加载器,负责加载用户类路径(ClassPath)上的类库。另外,用户也可以自定义类加载器。双亲委派模型的实现代码(在`java.lang.ClassLoader`中)主要体现在`loadClass`方法中。下面是该方法的一个简化描述:```javaprotectedClass<?>loadClass(Stringname,booleanresolve)throwsClassNotFoundException{synchronized(getClassLoadingLock(name)){//首先,检查类是否已经被加载Class<?>c=findLoadedClass(name);if(c==null){try{if(parent!=null){//如果有父加载器,则委派给父加载器加载c=parent.loadClass(name,false);}else{//如果没有父加载器,则委派给启动类加载器c=findBootstrapClassOrNull(name);}}catch(ClassNotFoundExceptione){//父加载器无法加载,捕获异常但不处理,继续往下执行}if(c==null){//如果父加载器没有加载到,则调用自己的findClass方法进行加载c=findClass(name);}}if(resolve){resolveClass(c);}returnc;}}```在双亲委派模型中,类加载器在加载类时,会先递归地委托给父类加载器,直到启动类加载器。如果父类加载器不能加载,子类加载器才会尝试加载。这样保证了同一个类不会被不同的类加载器重复加载,从而保证了类的唯一性。此外,每个类加载器都有一个独立的类名称空间。因此,两个类是否相等,不仅取决于类本身,还取决于加载它们的类加载器。也就是说,同一个类文件被不同的类加载器加载,它们就是不同的类。双亲委派模型是Java安全模型的一部分,但也存在一些缺陷。例如,基础类型需要调用回用户的代码(如SPI服务发现机制),这时就需要打破双亲委派模型。Java提供了线程上下文类加载器(ThreadContextClassLoader)来解决这类问题。总结:双亲委派模型是Java类加载机制的核心,它通过层次化的委派机制保证了类的唯一性和安全性,避免核心类被篡改,并防止了重复加载。</think>### Java双亲委派模型工作原理详解 #### **一、双亲委派模型的核心机制** 双亲委派模型是Java类加载的核心规则,其工作流程如下: 1. **层次结构** - 类加载器分为四层(由高到低): - **启动类加载器**(Bootstrap ClassLoader):加载`JAVA_HOME/lib`核心库(如`rt.jar`) - **扩展类加载器**(Extension ClassLoader):加载`JAVA_HOME/lib/ext`扩展库 - **应用程序类加载器**(Application ClassLoader):加载用户类路径(ClassPath)的类 - **自定义类加载器**:用户实现的加载器 - 父子关系通过**组合**实现(非继承),子加载器持有父加载器的引用[^2] 2. **委派流程** ```mermaid graph TD A[子类加载器收到请求] --> B{是否已加载?} B -- 是 --> C[返回已加载类] B -- 否 --> D[委派父加载器] D --> E{父加载器能否完成?} E -- 能 --> F[返回父加载结果] E -- 否 --> G[子加载器自行加载] ``` - **关键规则**:子加载器必须先将请求委派给父加载器,只有父加载器无法完成时(如不在其搜索范围),子加载器才会尝试加载[^1][^2] #### **二、工作原理解析** 以加载`java.lang.Object`为例: 1. 用户自定义加载器收到请求 → 委派给应用程序类加载器 2. 应用程序类加载器委派给扩展类加载器 3. 扩展类加载器委派给启动类加载器 4. 启动类加载器在`rt.jar`中找到并加载`Object`类 → 逐层返回结果 $$ \text{加载路径:} \text{自定义} \to \text{应用} \to \text{扩展} \to \text{启动} $$ #### **三、核心价值与优势** 1. **安全性保障** - 防止核心API被篡改(如用户伪造`java.lang.Object`类)[^1] - 确保核心类库由可信加载器加载 2. **类唯一性保证** - 类的身份由**加载器+类全名**共同确定 - 不同加载器加载的相同类文件,JVM视为不同类[^3] ```java // 示例:不同加载器加载的String比较 Class<?> strClass1 = loader1.loadClass("java.lang.String"); Class<?> strClass2 = loader2.loadClass("java.lang.String"); System.out.println(strClass1 == strClass2); // 输出false ``` 3. **避免重复加载** - 父加载器已加载的类,子加载器不会重复加载 #### **四、关键代码实现** 在`ClassLoader.loadClass()`中的逻辑: ```java protected Class<?> loadClass(String name, boolean resolve) { synchronized (getClassLoadingLock(name)) { // 1. 检查是否已加载 Class<?> c = findLoadedClass(name); if (c == null) { try { // 2. 委派父加载器 if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 父加载器无法完成 } // 3. 自行加载 if (c == null) { c = findClass(name); } } return c; } } ``` #### **五、打破双亲委派的场景** 在特定场景需绕过该模型: 1. **SPI机制**(如JDBC驱动加载) - 使用线程上下文类加载器(Thread Context ClassLoader) 2. **热部署需求** - 自定义加载器重写`loadClass()`方法 3. **OSGi模块化** - 实现网状加载结构 > **本质矛盾**:基础类需调用用户代码时,必须打破委派链[^4] --- ### 相关问题 1. **双亲委派模型如何解决类冲突问题?** *例如用户自定义了`java.lang.String`类会怎样?* 2. **哪些场景需要打破双亲委派模型?** *请结合JDBC驱动加载的实例说明* 3. **自定义类加载器的实现要点是什么?** *需要重写哪些关键方法?* 4. **不同类加载器加载的类如何实现隔离?** *解释JVM中"类全名+加载器=唯一标识"的原理* 5. **双亲委派模型在模块化系统(如JPMS)中有何变化?** *比较与传统模型的差异* [^1]: 双亲委派模型确保核心类由启动加载器加载,避免用户篡改核心类库 [^2]: 类加载器通过组合实现父子关系,形成层级委派链 [^3]: 类在JVM的唯一性由类加载器和类全名共同决定 [^4]: `ClassLoader`的`loadClass()`和`findClass()`是扩展关键点
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值