本文主要是介绍【JVM】简述类加载器及双亲委派机制,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
双亲委派模型,是加载class文件的一种机制。在介绍双亲委派模型之前,我需要先介绍几种类加载器(Class Loader)。
1,类加载器
Bootstrap,加载lib/rt.jar,charset.jar等中的核心类,由C++实现。其实就是加载的我们通常部署的jdk中的jar包。
Extension,加载扩展包,jre/lib/ext/*.jar,或者由-Djava.ext.dirs指定。pom中通过maven引入的依赖,就是由Ext类加载器加载而来。
App,加载classpath指定内容。就是加载我们自己编写的java类编译出来的class文件,这些类文件在idea中在target包下,在idea中可以查看和设定classpath的路径:
Custom,自定义类加载器,自定义的class loader。继承ClassLoader这个抽象类,重写findClass()方法即可实现自定义类加载器。
2,双亲委派机制
双亲委派机制是JVM加载并初始化class文件的机制,即JVM流程:Loading->Linking->Initializing中的Loading这一部分的机制。
双亲委派机制的流程如下:
在传入类的全限定名后,如java.lang.Object,JVM会首先去寻找类的class文件,挨个加载器去看看是否已经加载(前文已经说过类加载器加载类的范围不同),寻找顺序由下到上;
从下到上找了一遍都没有找到,说明该类的class文件不在JVM中就会从上到下的去让加载器尝试加载,如果该类不是这个加载器的范围,就不会加载,否则,加载器就会将这个类加载到JVM中。
双亲委派机制实质上是对类加载器的权限做了分级,并按照分级来进行寻找或加载。
3,Q&A
3.1,为什么双亲委派机制要区分不同的类加载器,使用一个加载器加载所有class文件不行吗?
使用不同的类加载器并进行加载权限上的区分,主要的作用是为了安全,试想一下,当使用一个加载器加载所有class文件时,那么加载权限上的混淆,使得这个加载器就可以自定义一个如java.lang.Object的类并加载,覆盖掉本来的object,这无疑是无法接受的。这就需要更重要的资源如jdk的class文件由单独一个类加载器加载,并且无法被其他加载器覆盖。
3.2,双亲委派机制为什么要这样从下到上的寻找、再从上到下的加载呢?
同样,也是为了安全。
为什么从上到下的加载?
比如我们还是自定义一个java.lang.Object,应该由Custom Classloader加载,如果不是优先由Bootstrap Classloader加载,而是Custom Classloader优先加载,那么会出现什么情况?custom加载后,就不会继续去bootstrap中加载,因为它会认为已经加载完毕了!所以,更重要的资源,应该优先加载,因此,jdk中的类->pom引入的依赖->自己编写的类编译出来的class文件(target目录中的class文件)->自定义加载器加载(可以自定义加载文件的位置和加载方式)
为什么要从下到上的寻找?
这里我的理解就是,如果有自定义的加载器,我们肯定是希望优先使用我们自定义的custom加载器的。如果没有,剩下App、Ext、Bootstrap三个加载器。这三个加载器,更重要的资源被加载过的可能性更大,因此查找的顺序放在后面;而如App加载自己编写的类的class文件,没有被加载过的可能性更大,因此优先查找。
3.3,双亲委派机制叫这个名字,是因为这些类是从上到下的继承关系吗?
并不是。双亲委派机制,名字翻译的不好,实际上这个机制就是指的孩子向父亲委派、父亲向孩子委派的过程。
实质上,Bootstrap是由C++实现的组件,Custom可以自定义一个继承抽象类ClassLoader,重写findClass()方法即可。而App和Ext,不是继承的关系,如下图:
3.4,能不能打破双亲委派机制
可以的。在自定义Custom类加载器,重写findClass()方法时,当找不到类时不要去向上寻找App类加载器,自然也就打破了双亲委派机制。
4.ClassLoader源码片段
ClassLoader是一个抽象类,其中寻找class文件的loadClass方法,从中可以一窥双亲委派的机制(Ext没有重写这个方法,使用的就是ClassLoader的这个方法)。
注意这里的parent指的是查找顺序上的parent,而不是通常所指的继承关系上的parent。
这篇关于【JVM】简述类加载器及双亲委派机制的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!