• JAVA中的双亲委派机制
  • 发布于 1周前
  • 49 热度
    0 评论
前言
最近有位小伙伴问了我一个问题:JDBC为什么会破坏双亲委派机制?这个问题挺有代表性的。双亲委派机制是Java中非常重要的类加载机制,它保证了类加载的完整性和安全性,避免了类的重复加载。这篇文章就跟大家一起聊聊,Java中类加载的双亲委派机制到底是怎么回事,有哪些破坏双亲委派机制的案例,为什么要破坏双亲委派机制,希望对你会有所帮助。

一. 为什么要双亲委派机制?
我们的Java在运行之前,首先需要把Java代码转换成字节码,即class文件。然后JVM需要把字节码通过一定的方式加载到内存中的运行时数据区。这种方式就是类加载器(ClassLoader)。再通过加载、验证、准备、解析、初始化这几个步骤完成类加载过程,然后再由jvm执行引擎的解释器和JIT即时编译器去将字节码指令转换为本地机器指令进行执行。

我们在使用类加载器加载类的时候,会面临下面几个问题:
1.如何保证类不会被重复加载?类重复加载会出现很多问题。
2.类加载器是否允许用户自定义?
3.如果允许用户自定义,如何保证类文件的安全性?

4.如何保证加载的类的完整性?


为了解决上面的这一系列的问题,我们必须要引入某一套机制,这套机制就是:双亲委派机制。

二. 什么是双亲委派机制?
接下来,我们看看什么是双亲委派机制。双亲委派机制的基本思想是:当一个类加载器试图加载某个类时,它会先委托给其父类加载器,如果父类加载器无法加载,再由当前类加载器自己进行加载。这种层层委派的方式有助于保障类的唯一性,避免类的重复加载,并提高系统的安全性和稳定性。

在Java中默认的类加载器有3层:
1.启动类加载器(Bootstrap Class Loader):负责加载 %JAVA_HOME%/jre/lib 目录下的核心Java类库,比如:rt.jar、charsets.jar等。它是最顶层的类加载器,通常由C++编写。
2.扩展类加载器(Extension Class Loader):负责加载Java的扩展库,一般位于<JAVA_HOME>/lib/ext目录下。
3.应用程序类加载器(Application Class Loader):也称为系统类加载器,负责加载用户类路径(ClassPath)下的应用程序类。

用一张图梳理一下,双亲委派机制中的3种类加载器的层次关系:

但这样不够灵活,用户没法控制,加载自己想要的一些类。于是,Java中引入了自定义类加载器。创建一个新的类并继承ClassLoader类,然后重写findClass方法。该方法主要是实现从那个路径读取 ar包或者.class文件,将读取到的文件用字节数组来存储,然后可以使用父类的defineClass来转换成字节码。

如果想破坏双亲委派的话,就重写loadClass方法,否则不用重写。
类加载器的层次关系改成:

双亲委派机制流程图如下:

具体流程大概是这样的:
1.需要加载某个类时,先检查自定义类加载器是否加载过,如果已经加载过,则直接返回。
2.如果自定义类加载器没有加载过,则检查应用程序类加载器是否加载过,如果已经加载过,则直接返回。
3.如果应用程序类加载器没有加载过,则检查扩展类加载器是否加载过,如果已经加载过,则直接返回。
4.如果扩展类加载器没有加载过,则检查启动类加载器是否加载过,如果已经加载过,则直接返回。
5.如果启动类加载器没有加载过,则判断当前类加载器能否加载这个类,如果能加载,则加载该类,然后返回。
6.如果启动类加载器不能加载该类,则交给扩展类加载器。扩展类加载器判断能否加载这个类,如果能加载,则加载该类,然后返回。
7.如果扩展类加载器不能加载该类,则交给应用程序类加载器。应用程序类加载器判断能否加载这个类,如果能加载,则加载该类,然后返回。
8.如果应用程序类加载器不能加载该类,则交给自定义类加载器。自定义类加载器判断能否加载这个类,如果能加载,则加载该类,然后返回。

9.如果自定义类加载器,也无法加载这个类,则直接抛ClassNotFoundException异常。


这样做的好处是:
1.保证类不会重复加载。加载类的过程中,会向上问一下是否加载过,如果已经加载了,则不会再加载,这样可以保证一个类只会被加载一次。

2.保证类的安全性。核心的类已经被启动类加载器加载了,后面即使有人篡改了该类,也不会再加载了,防止了一些有危害的代码的植入。


三. 破坏双亲委派机制的场景
既然Java中引入了双亲委派机制,为什么要破坏它呢?
答:因为它有一些缺点。

下面给大家列举一下,破坏双亲委派机制最常见的场景。

3.1 JNDI
JNDI是Java中的标准服务,它的代码由启动类加载器去加载。但JNDI要对资源进行集中管理和查找,它需要调用由独立厂商在应用程序的ClassPath下的实现了JNDI接口的代码,但启动类加载器不可能“认识”这些外部代码。为了解决这个问题,Java后来引入了线程上下文类加载器(Thread Context ClassLoader)。

这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置。如果创建线程时没有设置,他将会从父线程中继承一个,如果在应用程序的全局范围内都没有设置过的话,那这个类加载器默认就是应用程序类加载器。有了线程上下文加载器,JNDI服务就可以使用它去加载所需要的SPI代码,也就是父类加载器请求子类加载器去完成类加载的动作,这样就打破了双亲委派机制。

3.2 JDBC
原生的JDBC中Driver驱动本身只是一个接口,并没有具体的实现,具体的实现是由不同数据库类型去实现的。例如,MySQL的mysql-connector.jar中的Driver类具体实现的。原生的JDBC中的类是放在rt.jar包,是由启动类加载器进行类加载的。在JDBC中需要动态去加载不同数据库类型的Driver实现类,而mysql-connector.jar中的Driver实现类是用户自己写的代码,启动类加载器肯定是不能加载的,那就需要由应用程序启动类去进行类加载。

为了解决这个问题,也可以使用线程上下文类加载器(Thread Context ClassLoader)。

3.3  Tomcat容器
Tomcat是Servlet容器,它负责加载Servlet相关的jar包。此外,Tomcat本身也是Java程序,也需要加载自身的类和一些依赖jar包。这样就会带来下面的问题:
.一个Tomcat容器下面,可以部署多个基于Servlet的Web应用,但如果这些Web应用下有同名的Servlet类,又不能产生冲突,需要相互独立加载和运行才行。但如果多个Web应用,使用了相同的依赖,比如:SpringBoot、Mybatis等。这些依赖包所涉及的文件非常多,如果全部都独立,可能会导致JVM内存不足。也就是说,有些公共的依赖包,最好能够只加载一次。
.我们还需要将Tomcat本身的类,跟Web应用的类隔离开。
这些原因导致,Tomcat没有办法使用传统的双亲委派机制加载类了。

那么,Tomcat加载类的机制是怎么样的?

CommonClassLoader:是Tomcat最基本的类加载器,它加载的类可以被Tomcat容器和Web应用访问。
CatalinaClassLoader:是Tomcat容器私有的类加载器,加载类对于Web应用不可见。
SharedClassLoader:各个Web应用共享的类加载器,加载的类对于所有Web应用可见,但是对于Tomcat容器不可见。

WebAppClassLoader:各个Web应用私有的类加载器,加载类只对当前Web应用可见。比如不同war包应用引入了不同的Spring版本,这样能加载各自的Spring版本,相互隔离。


3.4 热部署
由于用户对程序动态性的追求,比如:代码热部署、代码热替换等功能,引入了OSGi(Open Service Gateway Initiative)。OSGi中的每一个模块(称为Bundle)。当程序升级或者更新时,可以只停用、重新安装然后启动程序的其中一部分,对企业来说这是一个非常诱人的功能。OSGi的Bundle类加载器之间只有规则,没有固定的委派关系。

各个Bundle加载器是平级关系。不是双亲委派关系。
用户评论