2.类加载器分类及双亲委派机制

2.类加载器分类

JVM支持两种类型的类加载器,分别是引导类加载器Bootstrap ClassLoader和自定义类加载器User-Defined ClassLoader。

从概念上来讲,自定义类加载器一般指的是程序中开发人员自定义的一类类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。

无论类加载器的类型如何划分,在程序中我们最常见的类加载器始终只有3个,如图:

用户自定义类使用的是系统类加载器进行加载

java的核心类库都是使用引导类加载器进行加载的,例如String类

通过getClassLoader()方法不能获取到引导类加载器获取结果为null,引导类加载器是c/c++语言实现的。

2.1启动类加载器

启动类加载器(引导类加载器Bootstrap ClassLoader)

1.这个类加载器使用c/c++语言实现的,嵌套在JVM内部
2.它用来加载Java的核心库(JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容),用于提供JVM自身需要的类
3.并不继承自java.lang.ClassLoader,没有父加载器。
4.加载扩展类和应用程序类加载器,并指定为他们的父类加载器。
5.处于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

2.2扩展类加载器

扩展类加载器(Extension ClassLoader)

1.Java语言编写,由sun.misc.Launcher$ExtClassLoader实现。
2.派生于ClassLoader类
3.父类加载器为启动类加载器
4.从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。

2.3应用程序加载器

应用程序加载器(系统类加载器AppClassLoader)

1.java语言编写,由sun.misc.Launcher$AppClassLoader实现
2.派生于ClassLoader类
3.父类加载器为扩展类加载器
4.它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
5.该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载
6.通过ClassLader#getSystemClassLoader()方法可以获取到该类加载器

2.4用户自定义类加载器

User ClassLoader用户自定义类加载器(后续章节详细概述,此处先了解)

除了上面三个自带的以外,用户还能制定自己的类加载器,但是所有自定义的类加载器都应该继承自java.lang.ClassLoader。比如热部署、tomcat都会用到自定义类加载器。

在java的日常应用程序开发中,类的加载几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,来定制类的加载方式。

为什仫要自定义类加载器?

隔离加载类
修改类加载的方式
扩展加载源
防止源码泄露

用户自定义类加载器实现步骤:

1.开发人员可以通过继承抽象类java.lang.ClassLoader类的方式,实现自己的类加载器,以满足一些特殊的需求。
2.在JDK1.2之前,在自定义类加载器时,总会去继承ClassLoader类并重写loadClass()方法,从而实现自定义的类加载类,但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法,而是建议把自定义的类加载逻辑写在findClass()方法中。
3.在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己去编写findClass()方法及其获取字节码流的方式,使自定义类加载器编写更加简洁。

3.双亲委派机制

Java虚拟机对class文件采用的是按需加载的方式,也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时,java虚拟机采用的是双亲委派模式,即把请求交由父类处理,它是一种任务委派模式。

工作原理:

如果一个类加载器收到了类加载的请求,他首先会从自己缓存里查找是否之前加载过这个class,加载过直接返回,没加载过的话他不会自己亲自去加载,他会把这个请求委派给父类加载器去完成,若父加载器为空则默认使用启动类加载器作为父加载器,每一层都是如此,类似递归,一直递归到顶层父类。

也就是Bootstrap ClassLoader,只要加载完成就会返回结果,如果顶层父类加载器无法加载此class,则会返回去交给子类加载器去尝试加载,若最底层的子类加载器也没找到,则会抛出ClassNotFoundException

源代码都在java.lang.ClassLoader中的loadClass方法之中,代码如下:

protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先,检查请求的类是否已经加载过
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
// 说明父类加载器无法完成加载请求
}
if (c == null) {
// 在父类加载器无法加载的时候
// 再调用本身的findClass方法来进行加载
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;
}
}

逻辑清晰易懂:先检查是否已经被加载过,若没有加载则调用父加载器的loadClass方法, 如父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败,抛出ClassNotFoundException 异常后,再调用自己的findClass方法进行加载。

1.如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行;

2.如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终到达顶层启动类加载器;

3.如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派机制。

父类判断自己是否可以加载的条件就是类加载器分类中,每个加载器加载的包不同,例如启动类加载器加载java、javax等包的类,扩展类加载器可以加载ext目录下的类

优势:

1.避免类的重复加载

2.保护程序安全,防止核心API被随意篡改,如:

定义与核心库中相同包路径且同名的类Stirng(报错:找不到主程序)

package java.lang;
/*
自定义包java.lang
创建与核心库中相同的类名String
*/
public class String {
static{
System.out.println("我是自定义的String类的静态代码块");
}
/*
* 错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为:
public static void main(String[] args)
否则 JavaFX 应用程序类必须扩展javafx.application.Application
Process finished with exit code 1
* */
public static void main(String[] args) {
System.out.println("hello,String");
}
}

定义与核心库中相同包路径但类名不同的类(报错:安全问题)

package java.lang;
public class StringExt {
/*
* java.lang.SecurityException: Prohibited package name: java.lang
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:662)
at java.lang.ClassLoader.defineClass(ClassLoader.java:761)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main"
Process finished with exit code 1
*/
public static void main(String[] args) {
System.out.println("hello!");
}
}

沙箱安全机制:

自定义Stirng类,但是在加载自定义String类的时候会率先使用引导类加载器加载,而引导类加载器在加载的过程中会先加载jdk自带的文件(rt.jar包中java\lang\String.class),报错信息说没有main方法,就是因为加载的是rt.jar包中的String类。这样可以保证对java核心源代码的保护,这就是沙箱安全机制。

在JVM中表示两个class对象是否为同一个类,存在两个必要条件:

1.类的完整类名必须一致,包括包名。

2.加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。

换句话说,在JVM中,即使这两个对象(class对象)来源同一个Class文件,被同一个虚拟机所加载,但只要加载它们的ClassLoader实例对象不同,那么这两个类对象也是不相等的。

JVM必须知道一个类型是由启动类加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候,JVM需要保证这两个类型的类加载器是相同的。

类的主动使用和被动使用:

java程序对类的使用方式分为:主动使用和被动使用

主动使用,又分为七种情况:

创建类的实例
访问某个类或接口的静态变量,或者对该静态变量赋值
调用类的静态方法
反射(比如:Class.forName("com.leizi.Test"))
初始化一个类的子类
Java虚拟机启动时被标明为启动类的类
JDK7开始提供的动态语言支持:java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化,则初始化

除了以上七种情况,其他使用Java类的方式都被看做是对类的被动使用都不会导致类的初始化。

3.1如何破坏双亲委任模型?

大佬地址:
https://www.javazhiyin.com/80670.html
https://www.javazhiyin.com/93379.html
posted @   Lz_蚂蚱  阅读(69)  评论(0编辑  收藏  举报
点击右上角即可分享
微信分享提示
评论
收藏
关注
推荐
深色
回顶
收起