2. 类加载器子系统
本文主要介绍类加载子系统,其中包括类的加载过程:加载、链接、初始化;以及 ClassLoader 的分类和 ClassLoader 的双亲委派机制等内容。
2.1. 内存结构
简图

详细图
类的加载分为3个环节:Loading -> Linking -> Initialization
加载需要用到类加载器,类加载器分为3种
BootStrap ClassLoader
:引导类加载器Extension ClassLoader
:扩展类加载器Application ClassLoader
:应用程序类加载器
PC寄存器(PC Register):每个线程一份,所以放了很多份
虚拟机栈(Stack Area):每个线程一份,每个线程的栈里一个一个的解构称为栈帧。还有一些细节的内部结构后续对应的章节会详细讲解。
Stack Area
- LV - Local Variables 本地变量表
- OS - Operation Stack 操作数栈
- DL - Dynamic Linking 动态链接
- RA - Return Address 返回地址
堆区(Heap Area):主要是创建JAVA对象的,这些对象,我们主体都分配在这个堆空间当中,也是我们内存当中算是最大的一块空间,也是GC,重点要考虑的一块空间。堆区是共享的,被多个线程所共享的。
方法区(Method Area):主要是来存放我们的一些类的信息、一些常量、一些域信息、方法信息等等。方法区,只有HotSpot虚拟机才有,像JRockit和J9他们其实都没有。
如果自己想手写一个Java虚拟机的话,主要考虑哪些结构呢?
- 类加载器
- 执行引擎
2.2 类加载器与类的加载过程
2.2.1 类加载器子系统作用

- 类加载器子系统负责从文件系统或者网络中加载Class文件,class文件在文件开头有特定的文件标识CAFA BABE(0xCAFEBABE)。
- ClassLoader 只负责Class文件的加载,至于它是否可以运行,则有 Execution Engine决定。
- 加载的类信息存放在一块称为方法区(Method
Area)的内存空间。除了类的信息外,方法区中还会存放运行时常量池信息,可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)。
字节码文件是物理磁盘上的一个文件,类加载器主要负责把这个文件加载到内存中,然后生成大的class的一个实例。
字节码结构中的常量池(constant pool),在运行的时候加载到内容中,就称为运行时常量池。

《Java虚拟机原理图解》 1.1、class文件基本组织结构 这篇文章对于类的字节码结构有更深入的讲解,第二部分也会深入讲解。此处了解即可。
2.2.2 类加载器ClasLoader角色

- class file 存在本地硬盘上,可以理解为设计师在纸上的模板,而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
- class file 加载到JVM中,被称为DNA元数据模板,放在方法区(Method Area)。
- 在.class 文件 JVM 最终成为元数据模板,此过程就要一个运输工具(类加载器 Class Loader),扮演一个快递员的角色。
2.2.3 类的加载过程


/**
*示例代码
*/
public class HelloLoader {
public static void main(String[] args) {
System.out.println("谢谢ClassLoader加载我...");
System.out.println("你的大恩大德,我下辈子再报!");
}
}
加载(Loading)
我们这里提到的类的加载过程是一个宏观上的概念,然后它分成三个环节。三个环节中的第一个环节,恰好也称为叫加载,这个加载呢是狭义上的。而类的加载过程中的加载是广义上的加载。
第一步的加载,是整体加载过程的三个环节中的第一个环节啊,恰好也叫做加载而,指将字节码文件加载到内存中。
- 通过一个类的全限定名获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的
java.lang.Class
对象,作为方法区这个类的各种数据的访问入口。
是一个虚的概念,具体的落地要看JDK的版本。JDK7及以前叫永久代(Permanent generation),JDK8及以后叫元空间(Meta space)
加载到内存中的类,是java.lang.Class
的一个实例。
补充:加载.class文件的方式
- 从本地系统中直接加载
- 通过网络获取。典型场景:Web Applet
- 从zip压缩包中读取,称为日后jar、war格式的基础
- 运行时计算生成,使用最多的是:动态代理技术
- 由其他文件生成,典型场景:JSP应用
- 从专有数据库中提取.class文件,比较少见
- 从加密文件中获取,典型的防Class文件被反编译的保护措施
Java打包后的文件如:war
、jar
、apk
等格式的文件,如果将后缀改为zip是可以解压的。解压后是一些class文件。
链接(Linking)
两个工具
- jclasslib-bytecode-viewer:查看字节码文件
- Binary Viewer:查看二进制文件数据
IDEA有对应的插件可以使用,这样用起来更方便些
- jclasslib Bytecode Viewer:查看字节码文件
- BinEd - Binary/Hex Editor:查看二进制文件
如果在IDEA中您的jclasslib Bytecode Viewer是中文版,可以通过下面的文章中的方法切换为英文版。
软件百度网盘分享:


验证(Verify)
目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,保证被加载类的正确性,保证被加载类的正确性,不会危害虚拟机自身安全。
主要包括四种验证:
- 文件格式验证
- 元数据验证
- 字节码验证
- 符号引用验证

准备(Prepare)
- 为类变量分配内存并且设置该类变量的默认初始值,即零值
- 这里不包含final修饰的static,因为final在编译的时候就会分配了,准备阶段会显式初始化;
- 这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。
以下面代码为例
public class HelloApp {
private static int a = 1; //prepare: a = 0 ---> initial : a = 1
public static void main(String[] args) {
System.out.println(a);
}
}
- 在准备阶段 a 会被赋一个初值 0 (即零值).
- 在初始化阶段,会将 a 的值赋值为1.
这个时候还没有创建对象,还是类的一个加载过程。当我们去创建一个对象(如使用new
关键字创建对象)时,才会涉及到实际实例变量的具体的初始化。
解析(Resolve)
- 将常量池内的符号引用转换为直接引用的过程
- 事实上,解析操作往往会伴随着JVM在执行完初始化之后再执行
- 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
- 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的
CONSTANT_Class_info
、CONSTANT_Fieldref_info
、CONSTANT_Methodref_info
等。
javap -v chapter02/target/classes/com/atguigu/HelloApp.class
这部分了解即可。
初始化(Initialization)
- 初始化阶段就是执行类构造器方法
<clinit>()
的过程 - 此方法不需要定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来
- 构造器方法中指令按语句在源文件中出现的顺序执行。
<clinit>()
不同于类的构造器。(关联:构造器是虚拟机视角下的<init>()
)- 若该类具有父类,JVM会保证子类的
<clinit>()
执行前,父类的<clinit>()
已经执行完毕 - 虚拟机必须保证一个类的
<clinit>()
方法在多线程下被同步加锁。
public class ClassInitTest {
private static int num = 1;
public static void main(String[] args) {
System.out.println(ClassInitTest.num);
}
}

在IDEA中如何使用jclasslib Bytecode Viewer插件?
- 编译项目(Build -> Build Project)
- 编译完成后,在
target
文件夹下,找到编译后的类,并选中它 - 选择 View -> Show Bytecode with Jclasslib,即可打开jclasslib查看窗口。
<clinit>()
public class ClassInitTest {
private static int num = 1;
static {
num = 2;
number = 20;
// System.out.println(number); // 报错,非法的前向引用 Illegal forward reference
}
private static int number = 10; // prepare: number = 0 --> initial: 20 --> 10
public static void main(String[] args) {
System.out.println(num);
System.out.println(number);
}
}
输出
2
10
0 iconst_1
1 putstatic #3 <org/depsea/jvm/chapter02/java/ClassInitTest.num : I>
4 iconst_2
5 putstatic #3 <org/depsea/jvm/chapter02/java/ClassInitTest.num : I>
8 bipush 20
10 putstatic #5 <org/depsea/jvm/chapter02/java/ClassInitTest.number : I>
13 bipush 10
15 putstatic #5 <org/depsea/jvm/chapter02/java/ClassInitTest.number : I>
18 return
8 bipush 20
10 putstatic #5 <org/depsea/jvm/chapter02/java/ClassInitTest.number : I>
13 bipush 10
15 putstatic #5 <org/depsea/jvm/chapter02/java/ClassInitTest.number : I>
从字节码中可以看出先给 number
赋值为了 20
,然后又赋值了为 10
。此部分验证了:构造器方法中指令按语句在源文件中出现的顺序执行。
这里的构造器方法是指类的构造器方法,即clinit()
public class ClinitTest {
private int a = 10;
public static void main(String[] args) {
int b = 2;
}
}
以上代码中不存在静态变量的定义和静态代码块。因此字节码中不包含clinit
方法。

public class ClinitTest {
private int a = 10;
private static int c = 20;
public static void main(String[] args) {
int b = 2;
}
}

<init>()
init 对应的就是类的构造器,在一个类中至少有一个构造器。如果我们没有显式的声明类的构造器,那么就会默认存在一个无参构造器。如果我们声明了一个构造器(这个构造器不是无参构造器),那么就不会生成无参构造器,除非我们再声明一个。
public class ClinitTest {
private int a = 10;
private int num = 0;
private static int c = 20;
public ClinitTest() {
}
public ClinitTest(int num) {
this.num = num;
}
public static void main(String[] args) {
int b = 2;
}
}

在这个类中,我们声明了两个构造函数。那么就会生成两个<init>()
方法。
0 aload_0
1 invokespecial #1 <java/lang/Object.<init>>
4 aload_0
5 bipush 10
7 putfield #2 <org/depsea/jvm/chapter02/ClinitTest.a>
10 aload_0
11 iconst_0
12 putfield #3 <org/depsea/jvm/chapter02/ClinitTest.num>
15 return
0 aload_0
1 invokespecial #1 <java/lang/Object.<init>>
4 aload_0
5 bipush 10
7 putfield #2 <org/depsea/jvm/chapter02/ClinitTest.a>
10 aload_0
11 iconst_0
12 putfield #3 <org/depsea/jvm/chapter02/ClinitTest.num>
15 aload_0
16 iload_1
17 putfield #3 <org/depsea/jvm/chapter02/ClinitTest.num>
20 return
<clinit>()
后续
若该类具有父类,JVM会保证子类的 <clinit>()
执行前,父类的 <clinit>()
已经执行完毕
public class ClinitExtendsTest {
static class Father {
public static int A = 1;
static {
A = 2;
}
}
static class Son extends Father {
public static int B = A;
}
public static void main(String[] args) {
// 加载Father类,其次加载Son类
System.out.println(Son.B);
}
}
0 getstatic #2 <com/atguigu/ClinitExtendsTest$Son.A : I>
3 putstatic #3 <com/atguigu/ClinitExtendsTest$Son.B : I>
6 return
0 aload_0
1 invokespecial #1 <com/atguigu/ClinitExtendsTest$Father.<init> : ()V>
4 return
虚拟机必须保证一个类的 <clinit>()
方法在多线程下被同步加锁。
public class DeadThreadTest {
public static void main(String[] args) {
Runnable r = () -> {
System.out.println(Thread.currentThread().getName() + "开始");
DeadThread dead = new DeadThread();
System.out.println(Thread.currentThread().getName() + "结束");
};
Thread t1 = new Thread(r, "Thread 1 ");
Thread t2 = new Thread(r, "Thread 2 ");
t1.start();
t2.start();
}
}
class DeadThread {
static {
if (true) {
System.out.println(Thread.currentThread().getName() + "初始化当前类");
}
// while (true) {} // 我的代码中加上这段后报错。
}
}
DeadThread
中的静态代码块中的代码只会执行一次。
Thread 1 开始
Thread 1 初始化当前类
Thread 1 结束
Thread 2 开始
Thread 2 结束
2.3 类加载器的分类
- JVM支持两种类型的类加载器,分别是引导类加载器(Bootstrap Classloader)和自定义类加载器(User-Define ClassLoader)
- 从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。
- 无论类加载器的类型如何划分,在程序中我们最常见的类加载器始终只有3个,如下所示:

这里的四者之间的关系是包含关系。不是上层下层,也不是子父类的继承关系
public class ClassLoaderTest {
public static void main(String[] args) {
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader); 1
ClassLoader extClassLoader = systemClassLoader.getParent();
System.out.println(extClassLoader); 2
ClassLoader bootstrapClassLoader = extClassLoader.getParent();
System.out.println(bootstrapClassLoader); 3
}
}
jdk1.8
- sun.misc.Launcher$AppClassLoader@18b4aac2
- sun.misc.Launcher$ExtClassLoader@18b4aac2
- null
jdk14
- jdk.internal.loader.ClassLoaders$AppClassLoader@3d4eac69
- jdk.internal.loader.ClassLoaders$PlatformClassLoader@7cc355be
- null
2.3.1 虚拟机自带的类加载器
启动类加载器(引导类加载器,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的安装目录的jar/lib/ext
子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。
应用程序类加载器(系统类加载器,AppClassLoader)
- java语言编写,由
sun.misc.LaunchersAppClassLoader
实现 - 派生于
ClassLoader
类 - 父类加载器为扩展类加载器
- 它负责加载环境变量
classpath
或系统属性java.class.path
指定路径下的类库 - 该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载
- 通过
ClassLoader#getSystemclassLoader()
方法可以获取到该类加载器
public class ClassLoaderTest1 {
public static void main(String[] args) {
System.out.println("******启动类加载器************");
URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (URL url : urls) {
System.out.println(url.toExternalForm()); //(1)
}
// 从上面的路径中随意找一个类,查看其类加载器
ClassLoader classLoader = Provider.class.getClassLoader();
System.out.println(classLoader); //(2)
System.out.println("************扩展类加载器************");
String extDirs = System.getProperty("java.ext.dirs");
// Windows下是:";" ,Mac或者Linux下是:":"
for (String path : extDirs.split(":")) {
System.out.println(path); //(3)
}
// 从上面的路径中随意找一个类,查看其类加载器
ClassLoader classLoader1 = CurveDB.class.getClassLoader();
System.out.println(classLoader1); //(4)
}
}
- (1)
- (2)
- (3)
- (4)
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/classes
null
/Users/wangchengwei/Library/Java/Extensions
/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext
/Library/Java/Extensions
/Network/Library/Java/Extensions
/System/Library/Java/Extensions
/usr/lib/java
sun.misc.Launcher$ExtClassLoader@d041cf
完整输出
******启动类加载器************
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/classes
null
************扩展类加载器************
/Users/wangchengwei/Library/Java/Extensions
/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext
/Library/Java/Extensions
/Network/Library/Java/Extensions
/System/Library/Java/Extensions
/usr/lib/java
sun.misc.Launcher$ExtClassLoader@d041cf
2.3.2 用户自定义类加载器
在Java的日常应用程序开发中,类的加载几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,来定制类的加载方式
- 隔离加载类
- 修改类加载的方式
- 扩展加载源
- 防止源码泄漏
用户自定义类加载器实现步骤:
- 开发人员可以通过集成抽象类
java.lang.ClassLoader
类的方式,实现自己的类加载器,以满足一些特殊的需求 - 在JDK1.2之前,在自定义类加载器时,总会去继承
ClassLoader
类并重写loadClass()
方法,从而实现自定义的类加载器,但是在JDK1.2之后已不再建议用户去覆盖loadClass()
方法,而是建议把自定义类的加载逻辑写在findClass()
方法 - 在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承
URLClassLoader
类,这样就可以避免自己取编写findClass()
方法及其获取字节码流的方式,使自定义类加载器编写更加简洁。
自定义类加载器示例
public class CustomClassLoader extends ClassLoader {
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] classBody = this.getClassFromCusomPath(name);
if (classBody == null || classBody.length == 0) {
throw new FileNotFoundException();
} else {
return this.defineClass(name, classBody, 0, classBody.length);
}
} catch (FileNotFoundException e) {
throw new ClassNotFoundException(name, e);
}
}
private byte[] getClassFromCusomPath(String name) {
// 从自定义路径中加载类
// 如果执行路径的字节码文件进行了加密,则需要在此方法进行解密操作。
return null;
}
public static void main(String[] args) {
CustomClassLoader classLoader = new CustomClassLoader();
try {
Class<?> clazz = Class.forName("One", true, classLoader);
Object obj = clazz.newInstance();
System.out.println(obj.getClass().getClassLoader());
} catch (Exception e) {
e.printStackTrace();
}
}
}
ClassLoader类,它是一个抽象类,其后所有的类加载器都继承自ClassLoader(不包括启动类加载器)
方法名称 | 描述 |
---|---|
getParent() | 返回该类加载器的超类加载器 |
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.lang.Class类的实例 |
resolveClass(Class<?> c) | 连接指定的一个java类 |

获取 ClassLoader
的几种途径
方式 | 代码 |
---|---|
方式一:获取当前类的ClassLoader | clazz.getClassLoader() |
方式二:获取当前线程上下文的ClassLoader | Thread.currentThread().getContextClassLoader() |
方式三:获取系统的ClassLoader | ClassLoader.getSystemClassLoader() |
方式四:获取调用者的ClassLoader | DriverManager.getCallerClassLoader() |
public class ClassLoaderTest2 {
public static void main(String[] args) {
try {
// 1
ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
System.out.println(classLoader);
// 2
ClassLoader classLoader1 = Thread.currentThread().getContextClassLoader();
System.out.println(classLoader1);
// 3
ClassLoader classLoader2 = ClassLoader.getSystemClassLoader().getParent();
System.out.println(classLoader2);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
控制台输出
null
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@2f333739
2.4 双亲委派机制
Java 虚拟机对 class 文件采用的是 按需加载 的方式,也就是说当需要使用该类时才会将她的 class 文件加载到内存生成的 class 对象。而且加载某个类的 class 文件时,Java 虚拟机采用的是双亲委派模式,即把请求交由父类处理,它是一种任务委派模式
- 什么是双亲委派机制?
- 说一下双亲委派机制的工作原理。
2.4.1 双亲委派机制的工作原理
- 如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行;
- 如果父类加载器还存在其父加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器;
- 如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己取加载,这就是双亲委派模式。

如下代码,虽然我们自定义了一个java.lang包下的String尝试覆盖核心类库中的String,但是由于双亲委派机制,启动加载器会加载java核心类库的String类(BootStrap启动类加载器只加载包名为java、javax、sun等开头的类),而且并没有执行我们自定义的String类中的静态代码块。
package java.lang;
public class String {
static {
System.out.println("我是自定义的String类的静态代码块");
}
}
public class StringTest {
public static void main(String[] args) {
String str = new String();
System.out.println("hello, atguigu.com");
}
}
输出
hello, atguigu.com
上面的代码可以看出我们自定义的 java.lang.String
类,并没有被加载,因为静态代码块没有执行。但是并不能够直观的感受到。我们将 java.lang.String
类改造下,增加一个 main
方法,然后执行这个 main
方法。如下:
package java.lang;
public class String {
static {
System.out.println("我是自定义的String类的静态代码块");
}
public static void main(String[] args) {
System.out.println(1);
}
}
将会收到如下异常:
错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为:
public static void main(String[] args)
否则 JavaFX 应用程序类必须扩展javafx.application.Application
2.4.2 双亲委派机制举例
当我们加载 jdbc.jar 用于实现数据库连接的时候,首先我们需要知道的是 jdbc.jar 是基于 SPI 接口进行实现的,所以在加载的时候,会进行双亲委派,最终从根加载器中加载 SPI 核心类,然后在加载 SPI 接口类,接着在进行反向委派,通过线程上下文类加载器进行实现类 jdbc.jar 的加载。

2.4.3 双亲委派机制的优势
- 避免类的重复加载
- 保护程序安全,防止核心 API 被随意篡改
- 自定义类:
java.lang.String
- 自定义类:
java.lang.MeDsh
(java.lang
包需要访问权限,阻止我们用包名自定义类)
- 自定义类:
public class ShkStart {
public static void main(String[] args) {
System.out.println("Hello!");
}
}
执行报错
Exception in thread "main" 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:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.depsea.jvm.chapter02.java1.ShkStartTest.main(ShkStartTest.java:25)
2.4.4 沙箱安全机制
自定义 String
类,但是在加载子弟敬意 String
类的时候回率先使用引导类加载器加载,而引导类加载器在加载过程中会先加载 jdk 自带的文件(rt.jar 包中的 java\lang\String.class
), 报错信息说没有 main 方法就是因为加载的是 rt.jar 包中的 String 类。这样可以保证对 Java 核心源代码的保护,这就是沙箱安全机制。
类比举例: 我们在读写 U 盘信息时可以用 360 沙箱,防止 U 盘内的病毒等对沙箱外的系统构成污染
2.4.5 其他
如何判断两个class对象是否相同
在 JVM 中表示两个 class 对象是否为同一个类存在的两个必要条件
- 类的完整类名必须一致,包括包名
- 加载这个类的 ClassLoader(指 ClassLoader 实例对象)必须相同
换句话说,在 JVM 中,即使这两个类对象(class 对象)来源同一个 Class 文件,被同一个虚拟机所加载,但只要加载它们的 ClassLoader 实例对象不同,那么这两个类对象也是不相等的.
理论上来说一个类只能被加载一次,但是也有例外,如果存在两个类加载器 ExternalClassLoader1
和 ExternalClassLoader2
。其结构如下
假如有一个外部的类,如 com.atguigu.Test
,这个类是网络上的一个类。这两个类都去加载这个类,是可以加载成功的。如下代码
ExternalClassLoader1 classLoader1 = new ExternalClassLoader1();
ExternalClassLoader2 classLoader2 = new ExternalClassLoader2();
Class clazz1 = classLoader1.loadClass('com.atguigu.Test');
Class clazz2 = classLoader2.loadClass('com.atguigu.Test');
当 clazz1
和 clazz2
比较的时候,结果是 false
。因为虽然是同一个类,但是使用了不同的类加载器。这一点是一定要注意的,双亲委派机制能够保证一条继承链路中的类加载是唯一的,但是如果存在分支,则并不能保证分支中的类加载是唯一的。如果 ExternalClassLoader2
继承自 ExternalClassLoader1
,那么类加载也是唯一的。
对类加载器的引用
JVM 必须知道一个类型是有启动类加载器加载的还是由用户类加载器加载的。如果一个类型由用户类加载器加载的,那么 JVM 会 将这个类加载器的一个引用作为类型信息的会议部分保存在方法区中。 当解析一个类型到另一个类型的引用的时候,JVM 需要保证两个类型的加载器是相同的。
类的主动使用和被动使用
java程序对类的使用方式分为:主动使用和被动使用
主动使用,分为七种情况
- 创建类的实例
- 访问某各类或接口的静态变量,或者对静态变量赋值
- 调用类的静态方法
- 反射 比如
Class.forName(com.dsh.jvm.xxx)
- 初始化一个类的子类
- Java 虚拟机启动时被标明为启动类的类
- JDK 7 开始提供的动态语言支持:
java.lang.invoke.MethodHandle
实例的解析结果REF_getStatic
、REF_putStatic
、REF_invokeStatic
句柄对应的类没有初始化,则初始化
除了以上七种情况,其他使用 Java 类的方式都被看作是对类的被动使用,都不会导致类的初始化。
区别在于会不会导致类的初始化。如使用 ClassLoader.loadClass()
去加载一个类的时候,这个类是不会初始化的。如下:我们定义一个类 com.atguigu.java1.Passive
。
public class Passive {
static {
System.out.println("执行静态代码块");
}
}
- 使用 ClassLoader 加载
- 使用 Class.forName() 加载
public class PassiveTest1 {
public static void main(String[] args) throws ClassNotFoundException {
ClassLoader classLoader = PassiveTest1.class.getClassLoader();
Class<?> clazz = classLoader.loadClass("com.atguigu.java1.Passive");
}
}
没有任何输出。
public class PassiveTest2 {
public static void main(String[] args) throws ClassNotFoundException {
Class<?> clazz = Class.forName("com.atguigu.java1.Passive");
}
}
输出:
执行静态代码块
使用 ClassLoader
加载的类,只有在最终使用的时候才会进行初始化,而使用 Class.forName
加载的类会立即初始化。如下:对 ClassLoader
加载类的代码进行改造,获取这个类的构造函数,并实例化。
public class PassiveTest1 {
public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException {
ClassLoader classLoader = PassiveTest1.class.getClassLoader();
Class<?> clazz = classLoader.loadClass("com.atguigu.java1.Passive");
Constructor constructor = clazz.getConstructor(); // 这里依然不初始化
constructor.newInstance(); // 这里才初始化
}
}
最后也会输出:
执行静态代码块