目录
1、基本概念
1.1 定义
双亲委派模型要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器。
双亲委派模型的工作过程是:
- 如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成。
- 每一个层次的类加载器都是如此。因此,所有的加载请求最终都应该传送到顶层的启动类加载器中。
- 只有当父加载器反馈自己无法完成这个加载请求时(搜索范围中没有找到所需的类),子加载器才会尝试自己去加载。
很多人对“双亲”一词很困惑。这是翻译的锅。“双亲”只是“parents”的直译,实际上并不表示汉语中的父母双亲,而是一代一代很多parent,即parents。
1.2 作用
对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立其在虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间。因此,使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处:类随着它的类加载器一起具备了一种带有优先级的层次关系。
例如类 java.lang.Object
,它由启动类加载器加载。双亲委派模型保证任何类加载器收到的对java.lang.Object
的加载请求,最终都是委派给处于模型最顶端的启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类。
相反,如果没有使用双亲委派模型,由各个类加载器自行去加载的话,如果用户自己编写了一个称为java.lang.Object的类,并用自定义的类加载器加载,那系统中将会出现多个不同的Object类,Java类型体系中最基础的行为也就无法保证,应用程序也将会变得一片混乱。
1.3 结构
1.3.1 系统提供的类加载器
在双亲委派模型的定义中提到了“启动类加载器”。包括启动类加载器,绝大部分Java程序都会使用到以下3种系统提供的类加载器:
- 启动类加载器(Bootstrap ClassLoader)
负责将存放在<JAVA_HOME>/lib
目录中的,或者被-Xbootclasspath
参数所指定的路径中的,并且是虚拟机按照文件名识别的(如rt.jar,名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机内存中。
启动类加载器无法被Java程序直接引用,用户在编写自定义类加载器时,如果需要把加载请求委派给引导类加载器,那直接使用null代替即可。
JDK中的常用类大都由启动类加载器加载,如java.lang.String、java.util.List等。需要特别说明的是,启动类Main class也由启动类加载器加载。
- 扩展类加载器(Extension ClassLoader)
由sun.misc.Launcher$ExtClassLoader
实现。
负责加载<JAVA_HOME>/lib/ext
目录中的,或者被java.ext.dirs
系统变量所指定的路径中的所有类库。
开发者可以直接使用扩展类加载器。
猴子对自己电脑
<JAVA_HOME>/lib/ext
目录下的jar包都非常陌生。看了几个jar包,也没找到常用的类;唯一有点印象的是jfxrt.jar,被用于JavaFX的开发之中。
- 应用程序类加载器(Application ClassLoader)
由sun.misc.Launcher$AppClassLoader
实现。由于这个类加载器是ClassLoader.getSystemClassLoader()
方法的返回值,所以一般也称它为系统类加载器。
它负责加载用户类路径ClassPath
上所指定的类库,开发者可以直接使用这个类加载器。如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。
启动类Main class、其他如工程中编写的类、maven引用的类,都会被放置在类路径下。Main class由启动类加载器加载,其他类由应用程序类加载器加载。
1.3.2 自定义的类加载器
JVM建议用户将应用程序类加载器作为自定义类加载器的父类加载器。
类加载的双亲委派执行流程图如下:
=============================================================================================
=============================================================================================
1、什么是双亲委派机制
当某个类加载器需要加载某个.class
文件时,它首先把这个请求任务委托给它的上级类加载器,递归这个操作,如果上级类加载器都没有加载,自己才会去加载这个类。
2、类加载器的类别
(1)启动类加载器:BootStrapClassLoader
c++
编写,加载java的
核心库 java.*,
构造ExtClassLoader
和AppClassLoader
。由于启动类加载器涉及到虚拟机本地实现细节,开发者无法直接获取到启动类加载器的引用,所以不允许直接通过引用进行操作。
(2)扩展类加载器:ExtClassLoader
java
编写,加载java的扩展库,如classpath
中的jre
,javax.*
或者 java.ext.dir
指定位置中的类,开发者可以直接使用标准扩展类加载器。
(3)应用程序类加载器:AppClassLoader
java
编写,加载应用程序所在的目录,如user.dir
所在的位置的class。
(4)用户自定义类加载器:CustomClassLoader
java
编写,用户自定义的类加载器,可加载指定路径的class
文件。
3、源码分析
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先检查这个classsh是否已经加载过了
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
// c==null表示没有加载,如果有父类的加载器则让父类加载器加载
if (parent != null) {
c = parent.loadClass(name, false);
} else {
//如果父类的加载器为空 则说明递归到bootStrapClassloader了
//bootStrapClassloader比较特殊无法通过get获取
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {}
if (c == null) {
//如果bootstrapClassLoader 仍然没有加载过,则递归回来,尝试自己去加载class
long t1 = System.nanoTime();
c = findClass(name);
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
4、双亲委派机制的执行流程图
5、双亲委派机制的作用
1、防止重复加载同一个.class文件
。通过委托去向上面问一问,加载过了,就不用再加载一遍了,保证数据安全。
2、保证核心 .class文件
不被篡改。通过向上委托的方式,不会去篡改核心 .class 文件
,即使篡改也不会去加载,即使加载也不会是同一个 .class
对象 。不同的类加载器加载同一个.class
也不是同一个Class
对象。这样保证了Class
执行安全。
注意:
(1)深入理解Java中的类加载器:https://www.jianshu.com/p/2026b01fb965
(2)浅谈双亲委派模型:https://www.jianshu.com/p/353c26c744df
(3)java双亲委派机制及作用:https://www.jianshu.com/p/1e4011617650