类加载器和双亲委派模型

类加载器按照层次,从顶层到底层,分为以下三种
 (1)启动类加载器(Bootstrap ClassLoader)
  这个类加载器负责将存放在JAVA_HOME/lib下的,或者被-Xbootclasspath参数所指定的路径中的,并且是虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。
 (2)扩展类加载器(Extension ClassLoader)
  这个加载器负责加载JAVA_HOME/lib/ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器
 (3)应用程序类加载器(Application ClassLoader)
  这个加载器是ClassLoader中getSystemClassLoader()方法的返回值,所以一般也称它为系统类加载器。它负责加载用户类路径(Classpath)上所指定的类库,可直接使用这个加载器,如果应用程序没有自定义自己的类加载器,一般情况下这个就是程序中默认的类加载器
 
  类加载的双亲委派模型
  双亲委派模型要求除了顶层的启动类加载器外,其他的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承关系来实现,而是都使用组合关系来复用父加载器的代码
  工作过程:
   如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传递到顶层的启动类加载器中,
   只有当父类加载器反馈自己无法完成这个请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载
  好处:
   Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类Object,它放在rt.jar中,无论哪一个类加载器要加载这个类,最终都是委派给启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类
   判断两个类是否相同是通过classloader.class这种方式进行的,所以哪怕是同一个class文件如果被两个classloader加载,那么他们也是不同的类
 
 实现自己的加载器
  只需要继承ClassLoader,并覆盖findClass方法。
  在调用loadClass方法时,会先根据委派模型在父加载器中加载,如果加载失败,则会调用自己的findClass方法来完成加载
  参考: http://blog.youkuaiyun.com/altchen/article/details/328698
  
  类加载器如何识别
  通过findLoadedClass来识别是否已经加载某个类,这个方法是findLoadedClass0的一个包装类,而findLoadedClass0是一个native方法
<think>我们正在讨论类加载器双亲委派模型。根据引用,双亲委派模型是Java类加载机制的核心,它通过层级委托来加载类。具体来说,当一个类加载器需要加载一个类时,它首先会委托给父类加载器,这样一直递归到启动类加载器。只有当父加载器无法加载时,子加载器才会尝试自己加载。这种机制的好处是避免重复加载,并且保护核心API的安全(如引用[2]所述)。 另外,引用[4]提到双亲委派模型是基石,尽管在某些场景(如Tomcat)中会被打破。引用[5]则举例Tomcat打破了双亲委派模型,因为它需要为每个Web应用提供独立的类加载器,以实现应用隔离。 因此,我们需要详细解释类加载器的类型、双亲委派模型的工作原理、优点以及破坏双亲委派模型的场景。 回答结构如下: 1. 类加载器的作用类型 2. 双亲委派模型的工作原理 3. 双亲委派模型的优点 4. 破坏双亲委派模型的场景(如Tomcat) 5. 总结 同时,注意引用标记,例如在提到双亲委派定义时引用[1][3],在提到优点时引用[2][4],在提到破坏时引用[5]。</think>### Java类加载器双亲委派模型详解 #### 一、类加载器的作用与类型 类加载器是JVM的核心组件,负责将`.class`字节码文件加载到内存并转换成`java.lang.Class`对象。主要分为三类: 1. **启动类加载器(Bootstrap ClassLoader)** - 由C++实现,加载`JAVA_HOME/lib`下的核心库(如rt.jar) - 唯一没有父加载器的加载器 2. **扩展类加载器(Extension ClassLoader)** - 加载`JAVA_HOME/lib/ext`目录的扩展库 - 父加载器是启动类加载器 3. **应用程序类加载器(Application ClassLoader)** - 加载用户类路径(ClassPath)的类 - 父加载器是扩展类加载器 此外还可自定义类加载器(如Tomcat的WebAppClassLoader)[^5]。 #### 二、双亲委派模型工作原理 双亲委派模型是类加载的核心机制,工作流程如下: ```mermaid graph TD A[子类加载器收到加载请求] --> B{父加载器是否已加载?} B -->|是| C[直接返回Class对象] B -->|否| D[委托父加载加载] D --> E{父加载器能否完成?} E -->|能| F[返回Class对象] E -->|不能| G[子加载器自行加载] ``` 具体步骤: 1. 类加载器收到加载请求时,先检查是否已加载过该类 2. **向上委派**:递归将请求委托给父加载器(直到Bootstrap) 3. **向下尝试**:若所有父加载器无法加载,才由发起请求的加载器处理 4. 若最终仍无法加载,抛出`ClassNotFoundException` 例如加载`java.lang.Object`时: - AppClassLoader → ExtClassLoader → BootstrapClassLoader(成功加载) - 若尝试篡改核心类,Bootstrap会优先加载原始类,阻止替换[^2]。 #### 三、双亲委派模型的优势 1. **避免重复加载** 父加载器已加载的类,子加载器不会重复加载[^2]。 2. **保护核心安全** 防止用户自定义类篡改核心API(如`java.lang.*`包)[^2]。 3. **层级隔离性** 不同层级的类加载器加载的类处于不同命名空间,避免冲突。 4. **高效性** 通过委派机制减少不必要的类加载检查。 #### 四、打破双亲委派模型的场景 尽管是Java类加载的基石,特定场景需打破该模型: 1. **SPI服务发现**(如JDBC) - 核心库接口由Bootstrap加载,但实现类需由应用加载加载 - 通过线程上下文类加载器(Thread Context ClassLoader)实现反向委派 2. **热部署场景**(如Tomcat) - 每个Web应用使用独立的`WebAppClassLoader`[^5] - 优先加载应用内的类(而非委派给父加载器),实现应用隔离 - 不同应用可加载同名类的不同版本 3. **模块化系统**(Java 9+) - 模块化系统引入新的类加载机制,允许更细粒度的控制[^4]。 #### 五、双亲委派模型的演进方向 随着技术发展,该模型正在优化: 1. **轻量化** Project Loom虚拟线程要求类加载更高效[^4] 2. **细粒度控制** JPMS模块系统支持按模块隔离依赖 3. **容器化适配** 云原生场景下需平衡隔离性与资源开销 > 示例:Tomcat类加载器层级 > ``` > Bootstrap → System → Common → WebApp1 → WebApp2 > ``` > WebApp加载器优先加载`WEB-INF/classes`,打破委派链[^5]。 #### 总结 双亲委派模型通过层级委托机制(子→父→Bootstrap)保障了安全性、避免类重复加载,是JVM类加载的基石[^1][^3]。但在SPI、热部署等场景需打破模型,未来将向轻量化、细粒度方向演进[^4]。理解该机制对诊断类冲突、实现模块化开发至关重要。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值