类加载器分类
大家好,我是码哥,可以叫我靓仔,《Redis 高手心法》畅销书作者。
先回顾下,在 Java 中,类的初始化分为几个阶段: 加载
、链接
(包括验证、准备和解析)和 初始化
。
而 类加载器
(Class Loader)则是加载阶段中,负责将本地或网络中的指定类的二进制流,加载到 Java 虚拟机中的工具。
在进入正文前,介绍下我的《Java 面试高手心法 58 讲》专栏,帮助你在现在就业压力巨大的情况下比别人多一个杀手锏,拿下心仪 offer。内容涵盖 Java 基础、Java 高级进阶、Redis、MySQL、消息中间件、微服务架构设计等面试必考点、面试高频点。
丢掉你收藏的那些所谓的「面试宝典」,因为它们大多数深度不够,甚至内容还有错误,你只会看完就忘,还浪费时间。这也是为何每次面试你都回答不好,找不到好工作的原因。
引导类加载器 BootstrapClassLoader
引导类加载器 BootstrapClassLoader:引导类加载器是使用 C++ 语言实现的,嵌入在 JVM 中。用于加载 Java 中的核心类库的,不继承自 java.lang.ClassLoader
,在 Java 程序中通常返回 null
。
一般会加载 JAVA_HOME
目录下的 /jre/lib
文件夹下的 jar 和配置。
ClassLoader loader = String.class.getClassLoader();
System.out.println(loader); // 输出 null,因为 String 是由引导类加载器加载的
扩展类加载器 ExtClassLoader
扩展类加载器主要负责加载 Java 的扩展类库,一般会加载 JAVA_HOME
目录下的 /jre/lib/ext
文件夹下的 jar。
继承自 java.lang.ClassLoader
,是用户可以访问的第一个类加载器。
ClassLoader extLoader = ClassLoader.getSystemClassLoader().getParent();
System.out.println(extLoader); // 输出 sun.misc.Launcher$ExtClassLoader
应用类加载器(Application ClassLoader)
应用类加载器是应用程序中默认的类加载器,可以加载 CLASSPATH
变量指定目录下的 jar,由 sun.misc.Launcher$AppClassLoader
实现。
并且一般情况下,我们编写的 Java 应用的类,都是使用该类加载器完成加载的。
ClassLoader appLoader = ClassLoader.getSystemClassLoader();
System.out.println(appLoader); // 输出 sun.misc.Launcher$AppClassLoader
类加载器抽象类 ClassLoader
在 Java 中存在一个类加载器抽象类 ClassLoader
,大多数类加载器都是通过继承这个类来实现的类加载功能。以下是 ClassLoader 类的关键部分代码:
public abstract class ClassLoader {
/*
* 类加载器的父加载器
*/
private final ClassLoader parent;
/**
* 根据类的全限定名加载类
*
* @param name 类名称
* @return 加载的Class对象
* @throws ClassNotFoundException 没有发现指定类异常
*/
public Class<?> loadClass(String name) throws ClassNotFoundException {
// 调用loadClass方法加载类,其中设置resolve=false,表示不立即解析类
return loadClass(name, false);
}
/**
* 根据类的全限定名加载类
*
* @param name 类名称
* @param resolve 是否解析这个类,true=解析,false=不解析
* @return 加载的Class对象
* @throws ClassNotFoundException 没有发现指定类异常
*/
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// 检查类是否已经被加载
Class<?> c = findLoadedClass(name);
// 如果没有加载过
if (c == null) {
// 如果有父类加载器,则委托给父加载器去加载
// 如果没有父类加载器,则判断 Bootstrap 类加载器是否加载过
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
// 如果父类加载器都加载失败,则当前类加载器尝试自行加载
if (c == null) {
c = findClass(name);
}
}
// 据 resolve 参数决定是否解析类
if (resolve) {
resolveClass(c);
}
return c;
}
}
/**
* 查找并加载指定名称的类
*
* @param name 类名称
* @return Class对象
* @throws ClassNotFoundException 没有发现指定类异常
*/
protected Class<?> findClass(String name) throws ClassNotFoundException {
//1. 根据传入的类名,到在特定目录下去寻找类文件,把字节码文件读入内存
// ...
//2. 调用 defineClass 将字节数组转成 Class 对象
return defineClass(buf, off, len);
}
/**
* 将一个 byte[] 转换为 Class 类的实例
*
* @param name 类名称,如果不知道此名称,则该参数为 null
* @param b 组成类数据的字节数组
* @param off 类数据的起始偏移量
* @param len 类数据的长度
* @return Class对象
* @throws ClassFormatError 类格式化异常
*/
protected final Class<?> defineClass(byte[] b, int off, int len) throws ClassFormatError {
...
}
}
类中定义的常用的类加载相关的方法:
方法名称 | 描述 |
---|---|
getParent() | 返回该类加载器的父类加载器 |
loadClass(String name) | 加载指定名称的类,返回 java.lang.Class 实例 |
findClass(String name) | 查找指定名称的类,返回 java.lang.Class 实例 |
findLoadedClass(String name) | 查找已加载的指定名称的类,返回 java.lang.Class 实例 |
defineClass(String name, byte[] b, int off, int len) | 将字节数组转换为一个 Java 类,返回 java.lang.Class 实例 |
resolveClass(Class c) | 连接指定的 Java 类 |
双亲委派模型(Parent Delegation Model)
双亲委派模型 是类加载器的设计模式,其核心思想是:类加载请求由子类加载器向父类加载器逐层委派,直到引导类加载器。
如果父类加载器无法加载,子类加载器才会尝试加载。
如果子类加载器也无法加载该类,就会抛出一个 ClassNotFoundException
异常。
双亲委派机制的作用
我们试想一下,如果不使用这种委托模式,那我们就可以随时使用自定义的 String 类来动态替代 Java 核心 API 中定义的类型,这样会存在非常大的安全隐患。
而双亲委托的方式,就可以避免这种情况,因为 String 已经在启动时就被引导类加载器 (BootstrcpClassLoader) 加载,所以用户自定义的 ClassLoader 永远也无法加载一个用户自己自定义的 String 类,除非你改变 JDK 中 ClassLoader 搜索类的默认算法。
该机制的作用如下。
防止重复加载字节码文件: 将类加载请求先委托给父类,父类加载后子类就不会重复加载该类。所以,双亲委派机制可以防止对某个类重复加载;
防止核心字节码文件被篡改: 一般情况下引导类加载器会先加载 JVM 核心类库,然后其它加载器才会执行,如果其它加载器要加载一个被篡改的核心字节码文件,会将该文件委托给父类加载器,当委托到引导类加载器时,加载器已经加载过该类,就不会对该类进行重复加载。而且就算能被加载,那么加载它的肯定不是相同的类加载器 (不会是引导类加载器),Java 虚拟机中只认可核心类加载器加载的核心类库,所以,双亲委派机制可以防止核心字节码文件被篡改。
简化加载逻辑: 通过委派模式,每个类加载器只需要关注自己负责的那部分类加载逻辑,而不必关心其他类加载器的加载细节,简化了类加载器的实现,降低了系统的复杂度。
自定义类加载器
在某些场景下,标准的类加载器无法满足需求,例如:
热部署:在 Web 服务器中动态加载或更新类。
模块隔离:在同一个 JVM 中加载不同版本的类。
加密解密:加载经过加密的 Class 文件。
默认的类加载器只能加载指定目录下的 Jar 和 Class 文件。
如果需要加载指定位置的类文件并实现一些自定义逻辑,就需要自定义类加载器。
Chaya:如何实现自定义类加载器?
步骤:
继承
java.lang.ClassLoader
类。重写
findClass()
方法,通过字节流读取 Class 文件并转换为Class
对象。
import java.io.*;
public class MyClassLoader extends ClassLoader {
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] classData = loadClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
}
return defineClass(name, classData, 0, classData.length);
}
private byte[] loadClassData(String name) {
String fileName = name.replace('.', '/') + ".class";
try (InputStream is = new FileInputStream(fileName);
ByteArrayOutputStream baos = new ByteArrayOutputStream()) {
int buffer;
while ((buffer = is.read()) != -1) {
baos.write(buffer);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
return null;
}
}
}
示例说明
findClass()
:从文件系统加载 Class 文件,并将其定义为Class
对象。defineClass()
:将字节数组转换为 JVM 可执行的Class
对象。
为了为保证类加载器都正确实现双亲委派机制,在开发自己的类加载器时,只需要重写 findClass()
方法即可。
当然,如果不想使用双亲委派机制时,就需要重写 loadClass()
方法。
打破双亲委派模型
有时为了实现特殊功能,我们需要打破双亲委派模型,例如:
热部署框架:Tomcat、Spring Boot 使用自定义类加载器加载和卸载 Web 应用。
SPI(Service Provider Interface)机制:JDBC 驱动等需要通过
线程上下文类加载器
来加载用户实现的接口。
最后(Ending)
最后,顺带给大家介绍下,我的新书《Redis 高手心法》。
原价 100 元,现在只需要 50。
作者简介
《Redis 高手心法》 作者,InfoQ 签约作者、51CTO Top 红人。拥有 10 年互联网工作经验,作为后端架构师,擅长 Redis、Tomcat、Spring、Kafka、MySQL 技术,对分布式微服务架构有深入了解。
点击卡片,关注我,学技术
往期推荐
面试官拷打:Redis 高可用篇章中面试最常见的 6 个问题!
Redis 7.0 深度探秘:List 数据结构原理与实战指南
重生之从零设计 MySQL 架构
重生之MySQL SQL 执行的 7 大关键步骤,解锁新技能