一、类加载器分类
JVM支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined classLoader)。
从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生于抽象类classLoader的类加载器都划分为自定义类加载器。
无论类加载器的类型如何划分,在程序中我们最常见的类加载器始终只有3个,如下所示:
public class HelloApp {
public static void main(String[] args) {
// 获取系统类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
// 这里是jdk11 jdk.internal.loader.ClassLoaders$AppClassLoader@2437c6dc
System.out.println(systemClassLoader);
ClassLoader platformClassLoader = systemClassLoader.getParent();
// 这里是jdk11 jdk.internal.loader.ClassLoaders$PlatformClassLoader@dfd3711
System.out.println(platformClassLoader);
// 返回的值为null,因为bootstrapClassLoader非java语言编写
ClassLoader bootstrapClassLoader = platformClassLoader.getParent();
System.out.println(bootstrapClassLoader);
// 对于用户自定义类 默认使用systemClassLoader加载器
ClassLoader classLoader = HelloApp.class.getClassLoader();
System.out.println(classLoader);
// 返回值是null,也就是说java核心api是使用引导类加载器加载
ClassLoader classLoader1 = String.class.getClassLoader();
System.out.println(classLoader1);
}
}
二、引导类、扩展类、系统类加载器的使用和演示
虚拟机自带的加载器
启动类加载器(引导类加载器,Bootstrap classLoader)
- 这个类加载使用c/C++语言实现的,嵌套在JVM内部。
- 它用来加载Java的核心库(JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容),用于提供JVM自身需要的类
- 并不继承自java.lang.ClassLoader,没有父加载器。加载扩展类和应用程序类加载器,并指定为他们的父类加载器。
- 出于安全考虑,Bootstrap启动类加载器只加载包名为java、 javax、sun等开头的类
扩展类加载器(Extension classLoader)
- Java语言编写,由sun.misc.Launcher$ExtClassLoader实现。
- 派生于classLoader类
- 父类加载器为启动类加载器
- 从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/ lib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。
应用程序类加载器(系统类加载器,AppclassLoader)
- java语言编写,由sun.misc.Launcher$AppclassLoader实现
- 派生于classLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
- 该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载
- 通过classLoader#getsystemclassLoader ()方法可以获取到该类加载器
三、用户自定义类加载器
在Java的日常应用程序开发中,类的加载几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,来定制类的加载方式。为什么要自定义类加载器?
- 隔离加载类
- 修改类加载的方式
- 扩展加载源
- 防止源码泄漏
用户自定义类加载器实现步骤:
- 开发人员可以通过继承抽象类java.lang.classLoader类的方式,实现自己的类加载器,以满足一些特殊的需求
- 在JDK1.2之前,在自定义类加载器时,总会去继承classLoader类并重写loadclass ()方法,从而实现自定义的类加载类,但是在JDK1.2之后已不再建议用户去覆盖loadclass ()方法,而是建议把自定义的类加载逻辑写在findclass ()方法中
- 在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己去编写findclass()方法及其获取字节码流的方式,使自定义类加载器编写更加简洁。
四、ClassLoader常用方法及获取方法
ClassLoader类,它是一个抽象类,其后所有的类加载器都继承自classLoader(不包括启动类加载器)。
方法名称 | 描述 |
getParentO | 返回该类加载器的超类加载器 |
loadClass(String name) | 加载名称为name的类,返回结果为 java.lang.Class类的实例 |
findClass(String name) | 查找名称为name 的类,返回结果为java.lang.Class类的实例 |
findLoadedClass(String name) | 查找名称为name 的已经被加载过的类,返阿结果为 java.lang.Class 类的实例 |
defineClass(String name,byte[]b,int off,int len) | 把字节数组b中的内容转换为一个Java类,返回结果为java.Iang.Class类的实例 |
resolveClass(Class<?> c) | 连接指定的一个Java类 |
五、双亲委派机制
Java虚拟机对class文件采用的是按需加载的方式,也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时,Java虚拟机采用的是双亲委派模式,即把请求交由父类处理,它是一种任务委派模式。
六、双亲委派机制的优势
案例:
优势
- 避免类的重复加载
- 保护程序安全,防止核心api被随意篡改
如果自定义的包就叫java.lang包,在该包下自定义一个类并运行,则会报错。因为java.lang包是由引导类加载器加载。引导类加载器发现运行的不是java核心包会抛出安全异常。
七、沙箱安全机制
自定义String类,但是在加载自定义String类的时候会率先使用引导类加载器加载,而引导类加载器在加载的过程中会先加载jdk自带的文件(rt.jar包中java \lang\String.class),报错信息说没有main方法,就是因为加载的是rt.jar包中的String类。这样可以保证对java核心源代码的保护,这就是沙箱安全机制。