双亲委派机制
1)什么是双亲委派
虚拟机在加载类的过程中需要使用类加载器进行加载,而在Java中,类加载器有很多,那么当JVM想要加载一个.class文件的时候,到底应该由哪个类加载器加载呢?这就不得不提到"双亲委派机制"。
首先,我们需要知道的是,Java语言系统中支持以下4种类加载器:
- Bootstrap ClassLoader 启动类加载器:主要负责加载Java核心类库,%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。
- Extention ClassLoader 标准扩展类加载器:主要负责加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。
- Application ClassLoader 应用类加载器:主要负责加载当前应用的classpath下的所有类。
- User ClassLoader 用户自定义类加载器:用户自定义的类加载器,可加载指定路径的class文件。
也就是说,一个用户自定义的类,如com.hollis.ClassHollis 是无论如何也不会被Bootstrap和Extention加载器加载的
这四种类加载器之间,是存在着一种层次关系的,如下图
一般认为上一层加载器是下一层加载器的父加载器,那么,除了BootstrapClassLoader之外,所有的加载器都是有父加载器的。
那么,所谓的双亲委派机制,指的就是:当一个类加载器收到了类加载的请求的时候,他不会直接去加载指定的类,而是把这个请求委托给自己的父加载器去加载。只有父加载器无法加载这个类的时候,才会由当前这个加载器来负责类的加载。
2)为什么需要双亲委派
因为类加载器之间有严格的层次关系,那么也就使得Java类也随之具备了层次关系。比如一个定义在java.lang包下的类,因为它被存放在rt.jar之中,所以在被加载过程汇总,会被一直委托到Bootstrap ClassLoader,最终由Bootstrap ClassLoader所加载。
而一个用户自定义的com.hollis.ClassHollis类,他也会被一直委托到Bootstrap ClassLoader,但是因为Bootstrap ClassLoader不负责加载该类,那么会在由Extention ClassLoader尝试加载,而Extention ClassLoader也不负责这个类的加载,最终才会被Application ClassLoader加载。
这种机制有几个好处。
首先,通过委派的方式,可以避免类的重复加载,当父加载器已经加载过某一个类时,子加载器就不会再重新加载这个类。
另外,通过双亲委派的方式,还保证了安全性。假如我们自己编写一个类java.util.Object
,它的实现可能有一定的危险性或者隐藏的bug。而我们知道Java自带的核心类里面也有java.util.Object
,如果JVM启动的时候先行加载的是我们自己编写的java.util.Object
,那么就有可能出现安全问题!
3)加载器之间的关系
双亲委派模型中,类加载器之间的父子关系一般不会以继承(Inheritance)的关系来实现,而是都使用组合(Composition)关系来复用父加载器的代码的。
如下为ClassLoader中父加载器的定义:
public abstract class ClassLoader {
// The parent class loader for delegation
private final ClassLoader parent;
}
4)双亲委派的实现原理
双亲委派模型对于保证Java程序的稳定运作很重要,但它的实现并不复杂。
实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中:
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
代码不难理解,主要就是以下几个步骤:
1、先检查类是否已经被加载过
2、若没有加载则调用父加载器的loadClass()方法进行加载
3、若父加载器为空则默认使用启动类加载器作为父加载器。
4、如果父类加载失败,抛出ClassNotFoundException异常后,再调用自己的findClass()方法进行加载。
5)为什么需要破坏双亲委派
假设我们有一个接口 PaymentService
和两个实现类:
PaymentServiceImplA
(来自ThirdPartyA
)PaymentServiceImplB
(来自ThirdPartyB
)
如果这两个实现类都被放在应用的类路径下,并且你使用了双亲委派机制,加载过程如下:
- 加载请求:当你在代码中使用
PaymentServiceImplA
或PaymentServiceImplB
时,类加载器会收到加载请求。 - 委派机制:
- 首先,Bootstrap ClassLoader 会尝试加载请求的类。如果该类不在 Java 核心库中(比如
java.lang
、java.util
等),则 Bootstrap ClassLoader 会失败。 - 然后,Extension ClassLoader 会尝试加载。如果类仍然不在扩展库中,则加载失败。
- 接下来,Application ClassLoader(也称为 Web ClassLoader,在 Web 应用中)会尝试加载这个类。
- 首先,Bootstrap ClassLoader 会尝试加载请求的类。如果该类不在 Java 核心库中(比如
- 加载的结果:
- 如果
PaymentServiceImplA
和PaymentServiceImplB
都存在于类路径下,Application ClassLoader 将会加载它们。但因为它们属于不同的第三方库,它们的类名必须是唯一的。
- 如果
可能出现的问题
- 命名冲突:如果
ThirdPartyA
和ThirdPartyB
的实现类都定义为PaymentServiceImpl
,这将导致类命名冲突,最终只有一个实现会被加载,而另一个可能会被忽略或引发错误。 - 版本冲突:如果
PaymentServiceImplA
和PaymentServiceImplB
依赖于不同版本的同一库(例如,commons-logging
),它们将会加载到同一个 Application ClassLoader 中,这也可能导致运行时错误。
6)怎么破坏双亲委派
知道了双亲委派模型的实现,那么想要破坏双亲委派机制就很简单了。
因为他的双亲委派过程都是在loadClass方法中实现的,那么想要破坏这种机制,那么就自定义一个类加载器,重写其中的loadClass方法,使其不进行双亲委派即可。
loadClass()、findClass()、defineClass()区别
ClassLoader中和类加载有关的方法有很多,前面提到了loadClass,除此之外,还有findClass和defineClass等,那么这几个方法有什么区别呢?
- loadClass()
- 就是主要进行类加载的方法,默认的双亲委派机制就实现在这个方法中。
- findClass()
- 根据名称或位置加载.class字节码
- definclass()
- 把字节码转化为Class
这里面需要展开讲一下loadClass和findClass,我们前面说过,当我们想要自定义一个类加载器的时候,并且像破坏双亲委派原则时,我们会重写loadClass方法。
那么,如果我们想定义一个类加载器,但是不想破坏双亲委派模型的时候呢?
这时候,就可以继承ClassLoader,并且重写findClass方法。findClass()方法是JDK1.2之后的ClassLoader新添加的一个方法。
/**
* @since 1.2
*/
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
这个方法只抛出了一个异常,没有默认实现。
JDK1.2之后已不再提倡用户直接覆盖loadClass()方法,而是建议把自己的类加载逻辑实现到findClass()方法中。
因为在loadClass()方法的逻辑里,如果父类加载器加载失败,则会调用自己的findClass()方法来完成加载。
所以,如果你想定义一个自己的类加载器,并且要遵守双亲委派模型,那么可以继承ClassLoader,并且在findClass中实现你自己的加载逻辑即可。
7)破坏双亲委派的例子
1. Tomcat 的类加载机制
背景
Tomcat 是一个广泛使用的 Java Web 服务器和 Servlet 容器。它使用自己的类加载机制来处理 Web 应用和其他组件的类加载。
破坏双亲委派的原因
- 隔离性:Tomcat 需要将不同的 Web 应用(WAR 文件)隔离开来,以防止它们之间的类冲突。不同应用可能会依赖于相同名称的类,但这些类的实现可能不同。
- 灵活性:允许不同的 Web 应用使用不同版本的同一个库(例如,
commons-logging
),而不影响其他应用。
实现
Tomcat 使用多个类加载器:
- Web 应用类加载器:负责加载应用的类。
- 父加载器(通常是
Application ClassLoader
):负责加载 Tomcat 自身的类和一些共享库。
具体而言,当 Tomcat 加载一个 Web 应用时,它的类加载器会优先加载应用内的类。如果该类在应用内找不到,才会委托给父加载器。这种方式允许 Web 应用使用自己的类而不是全局共享的类。
2. JBoss/WildFly 的类加载机制
背景
JBoss/WildFly 是另一个流行的 Java EE 应用服务器,采用了类似的策略来处理类加载。
破坏双亲委派的原因
- 模块化:JBoss/WildFly 允许开发者将应用划分为多个模块,每个模块可以有自己独立的依赖。
- 防止版本冲突:允许不同模块之间使用不同版本的相同库。
实现
- JBoss/WildFly 使用模块加载器,模块中的类默认不经过双亲委派机制。每个模块都可以有自己的类路径,减少类冲突的风险。
3. 例子总结
例如,如果在 Tomcat 中有两个 Web 应用:
- 应用 A 使用
commons-logging
的 1.1 版本。 - 应用 B 使用
commons-logging
的 1.2 版本。
如果不破坏双亲委派机制,两个应用会共享同一个 commons-logging
类,这可能导致运行时错误和版本不兼容。但由于 Tomcat 的类加载器会优先加载应用自身的类,因此各自的 commons-logging
版本会被正确加载。
8)类加载器的使用场景
什么时候使用默认加载器
- 常规应用开发:
- 大多数 Java 应用程序、Web 应用和企业应用都可以使用默认的类加载器(
Application ClassLoader
),因为它能够从类路径中自动加载需要的类。
- 大多数 Java 应用程序、Web 应用和企业应用都可以使用默认的类加载器(
- 使用标准库:
- 当你的应用仅依赖于 Java 标准库和已经在类路径下的第三方库时,默认类加载器通常足够。
什么时候使用自定义类加载器
- 特殊路径加载:
- 当需要从非标准路径(如网络、数据库或特定文件夹)加载类时,使用自定义类加载器可以满足这种需求。
- 版本冲突管理:
- 在同一项目中需要使用多个版本的同名类时,自定义类加载器可以隔离它们,避免命名冲突。
- 动态生成类:
- 如果你的应用需要在运行时动态生成和加载类(例如,通过字节码操作库),则自定义类加载器是必要的。
- 类增强和修改:
- 对于需要在类加载时进行字节码修改或增强(如 AOP 框架),使用自定义类加载器是合适的。
参考:https://www.cnblogs.com/hollischuang/p/14260801.html
标签:委派,loadClass,ClassLoader,双亲,findClass,浅析,加载 From: https://www.cnblogs.com/awstan/p/18514371