这是我参与8月更文挑战的第11天,活动详情查看: 8月更文挑战
前言
在类的生命周期中,第一个阶段是就是类的加载阶段,在这个阶段,非数组类的二进制字节流被加载进内存中,并生成一个java.lang.Class
对象。
本文主要论述发生在这一阶段的故事。
一. 类加载器
1.1 类加载器的种类
JVM 中内置了三个重要的 ClassLoader,除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自
java.lang.ClassLoader
(图)类加载器的层次关系
对于JVM来说,类加载器分为两种:
- 启动类加载器:对于Hotsopt虚拟机来说,启动类加载器是用C++实现的,它属于虚拟机的一部分
- 其他类加载器:这类加载器都使用Java语言实现,独立于虚拟机之外,并且全部继承于
java.lang.ClassLoader
这些类加载器需要由启动类加载到内存中才能去加载其他的类
对于开发者来说,类加载器可以分为三类:
- 启动类加载器(Bootstrap ClassLoader):负责加载
${JAVA_HOME}/jre/lib
目录下,或者被-Xbootclasspath
参数指定的路径中,能被虚拟机识别的类库;启动类加载器无法被开发人员使用。 - 扩展类加载器(Extension ClassLoader):主要负责加载
%JRE_HOME%/lib/ext
目录下的 jar 包和类,或被java.ext.dirs
系统变量所指定的路径下的 jar 包;开发人员可以直接使用扩展类加载器。 - 应用程序类加载器(Application ClassLoader):面向我们用户的加载器,负责加载当前应用 classpath 下的所有 jar 包和类;开发者可以直接使用该类加载器。
1.2 查询该类的类加载器
示例代码:
public class Test {
public static void main(String[] args) {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
System.out.println(classLoader);
System.out.println(classLoader.getParent());
System.out.println(classLoader.getParent().getParent());
}
}
复制代码
输出:
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@4eec7777
null
复制代码
第三个为null的原因是因为HotSopt的BootstrapClassLoader
是用C++实现的,找不到一个具体的对象
1.3 自定义类加载器
通常情况下,我们都是直接使用系统类加载器,但有些是有也需要我们自定义类加载器,比如通过网络传输的字节码文件,为了安全通过了加密处理,这时系统加载器就无法加载这些类了
除了 BootstrapClassLoader
其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader
;如果我们要自定义自己的类加载器,只需要继承 ClassLoader
即可
二. 双亲委派机制
每个类都有自己的类加载器,系统中的
ClassLoader
在协同工作的时候会默认使用 双亲委派机制
双亲委派机制:
- 在类加载的时候,系统会首先判断当前类是否被加载过。已经被加载的类会直接返回,否则才会尝试加载。
- 加载的时候,首先会把该请求委派给父类加载器的
loadClass()
处理,当父类加载器为 null 时,会使用启动类加载器BootstrapClassLoader
作为父类加载器,所有的请求都会到达启动类加载器中。 - 当请求到达
BootstrapClassLoader
中,会自顶向下检查是否能被加载,直到有人说我可以。
2.1 双亲委派机制的代码实现
在
java.lang.ClassLoader
的loadClass()
中
public Class<?> loadClass(String name)throws ClassNotFoundException {
return loadClass(name, false);
}
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
// 首先判断该类型是否已经被加载
Class c = findLoadedClass(name);
if (c == null) {
//如果没有被加载,就委托给父类加载或者委派给启动类加载器加载
try {
if (parent != null) {
//如果存在父类加载器,就委派给父类加载器加载
c = parent.loadClass(name, false);
} else {
//如果不存在父类加载器,就检查是否是由启动类加载器加载的类,通过调用本地方法native Class findBootstrapClass(String name)
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器和启动类加载器都不能完成加载任务,才调用自身的加载功能
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
复制代码
2.2 为什么要采用双亲委派机制
双亲委派机制,可以避免类被重复加载,特别是系统的核心类。
假如现在有人想替换系统级别的类:java.lang.String
,在双亲委派机制下,它已经被BootstrapClassLoader
加载过了,其他类加载器没有机会再加载了。
因此,双亲委派模型保证了 Java 程序的稳定运行,也保证了 Java 的核心 API 不被篡改。
三. 总结
JVM的类加载机制,总结为以下几点:
- 全盘委托机制:当一个类加载器负责加载某个Class时,该Class所依赖的和引用的其他Class也将由该类加载器负责载入,除非显示使用另外一个类加载器来载入
- 缓存机制:缓存机制将会保证所有加载过的Class都会被缓存,当程序中需要使用某个Class时,类加载器先从缓存区寻找该Class,才会执行加载逻辑,并存入缓存区
- 双亲委派机制:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把请求委托给父加载器去完成,依次向上;如果父类加载器无法加载,再依次向下