类加载子系统
Java虚拟机把描述类的数据从Class文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这个过程被称作虚拟机的类加载机制。与那些在编译时需要进行连接的语言不同,在Java语言里面,类型的加载、连接和初始化过程都是在程序运行期间完成的,这种策略让Java语言进行提前编译会面临额外的困难,也会让类加载时稍微增加一些性能开销,但是却为Java应用提供了极高的扩展性和灵活性,Java天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
类加载器与类的加载过程
类加载子系统作用
- 类加载器子系统负责从文件系统或者网络中加载class文件,class文件在文件开头有特点的文件标识。
- ClassLoader只负责class文件的加载,至于它是否可以运行,择优Execution Engine决定。
- 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外,方法区中还会存放运行时常量池信息,可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)
类加载器ClassLoader角色
- class file 存在于本地硬盘上,可以理解为设计师画在纸上的模板,而最终这个模板在执行的时候要加载到JVM当中来根据整文件实例化出n个一模一样的实例。
- class file 加载到JVM中,被称为DNA元数据模板,放在方法区
- 在.class问价 -> JVM -> 最终成为元数据模板,此过程就要一个运输工具(类装载器 Class Loader)扮演一个快递员的角色。
类的加载过程
一个类型从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期将会经历加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)七个阶段,其中验证、准备、解析三个部分统称为连接(Linking)。
加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的,类型的加载过程必须按照这种顺序按部就班地开始,而解析阶段则不一定:它在某些情况下可以在初始化阶段之后再开始,这是为了支持Java语言的运行时绑定特性(也称为动态绑定或晚期绑定)。这些阶段通常都是互相交叉地混合进行的,会在一个阶段中调用、激活另一个阶段。
阶段一、加载(Loading)
- 通过一个类的全限定类名获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的
java.lang.Class
(Class)对象,作为方法区这个类的各种数据的访问入口
补充:加载.class 文件的方式
- 从本地系统中直接加载
- 通过网络获取,典型场景:web applet
- 从zip压缩包中读取,成为日后的jar、war格式的基础
- 运行时计算生成,使用最多的:动态代理技术
- 由其他文件生成,典型场景 JSP应用
- 从专有数据库中提取.class文件,比较少见
- 从加密文件中获取获取,典型的防Class文件别
阶段二、链接(Linking)
- 验证(Verify):
- 目的在于确保Class文件的字节流中包含信息符合当前虚拟机的要求,保证被加载类的正确性,不会危害虚拟机自身安全。
- 主要包含四种验证,文件格式验证,元数据验证,字节码验证,符号引用验证。
- 准备(Prepare):
- 为类变量分配内存并且设置该类变量的默认初始值,即零值。
- 这里不包含用
final
修饰的static
,因为final
在编译时就会分配了,准备阶段会显式初始化。 - 这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。
- 解析(Resolve):
- 将常量池内的符号引用转换为直接引用的过程。
- 事实上,解析操作往往会伴随着JVM在执行完初始化之后再执行。
- 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
- 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的
CONSTANT_Class_info
、CONSTANRT_FIeldref_info
、CONSTANT_Methodref_info
等。
阶段三、初始化(Initialization)
初始化阶段就是执行类构造器方法<clinit>()
的过程。
此方法不需要定义,是Javac编译器自动收集类中的所有类变量(static修饰的变量,不是成员属性)的赋值动作和静态代码块中的语句合并而来。【换句话说,如果没有类变量,和静态代码块,则不会有<clinit>
】
构造器方法中指令按语句在源文件中出现的顺序执行。
<clinit>()
不同于类的构造器。(关联:构造器是虚拟机视角下的<init>()
)
若该类具有父类,JVM会保证子类的<clinit>()
执行前,父类的<clinit>()
已经执行完毕
虚拟机必须保证一个类的<clinit>()
方法在多线程下被同步加锁。
<init>是对象构造时进行调用的,每次从类实例化对象时都会被调用,而<clinit>是类被加载器加载时调用的,仅会调用一次。
示例:
public class ClassInitTest {
static{
num = 20;
}
private static int num = 1;
public static void main(String[] args) {
System.out.println(ClassInitTest.num);
}
}
// 在 Linking 的 Prepare 过程中将类变量 num 赋值为0,
// 在 initialzation 中将 num 变量赋值为20(Static), 再将 number 变量赋值为 10
如果没有类变量(static修饰的变量)和静态代码块,则不会有<clinit>()
方法。
public class ClassInitTest {
int num = 3;
}
在 Java 中,任何一个类声明后,内部至少存在一个类的构造器,对应Methods
中的init
方法。
- 带有父类的
<clinit>()
方法
public class ClinitTest {
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); // 2
}
}
- 虚拟机执行一个类的加载时,只会调用一次该类的
<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,"线程1");
Thread t2 = new Thread(r,"线程2");
t1.start();
t2.start();
}
}
class DeadThread {
static {
if (true) {
System.out.println(Thread.currentThread().getName()+"初始化当前类");
while (true) {
// 阻塞
}
}
}
}
输出语句只出现一次,证明同一个类即使被多个类使用,也只会加载一次【同步加锁】。
类加载器分类
JVM 支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader
)和自定义类加载器(`User-Defined ClassLoader)
从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生与抽象类ClassLoader
的类加载器都划分为自定义类加载器。
无论类加载器的类型如何划分,在程序中我们最常见到的类加载器始终只有三个:
也就是说,Extension Class Loader
和System Class Loader
也是自定义类加载器。
这里的四者之间的关系是包含关系。不是上层下层,也不是父子类的继承关系。
示例:
public class ClassLoaderTest {
public static void main(String[] args) {
// 获取系统类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader); // sun.misc.Launcher$AppClassLoader@18b4aac2
// 获取其上层:扩展类加载器
ClassLoader extClassLoader = systemClassLoader.getParent();
System.out.println(extClassLoader); // sun.misc.Launcher$ExtClassLoader@1b6d3586
// 获取其上层:获取不到引导类加载器
ClassLoader bootstrapClassLoader = extClassLoader.getParent();
System.out.println(bootstrapClassLoader); // null
// 对于用户自定义类来说:默认使用系统类加载器进行加载
ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
System.out.println(classLoader); // sun.misc.Launcher$AppClassLoader@18b4aac2
// String 类使用引导类加载器进行加载的【 系统核心类都是由引导类加载器进行加载的 】
ClassLoader strClassLoader = String.class.getClassLoader();
System.out.println(strClassLoader); // null
}
}
虚拟机自带的加载器
启动(引导)类加载器(引导类加载器:Bootstrap ClassLoader)
- 这个类加载使用C/C++ 语言来实现,嵌套在JVM内部。
- 它用来加载Java的核心库(
JAVA_HOME/jre/lib/rt.jar
、resource.jar
或sun.boot.class.path
路径下的内容),用于提供JVM自身需要的类。 - 并不继承自
java.lang.ClassLoader
没有父类加载器。 - 加载扩展类和应用程序类加载器,并指定为他们的父类加载器。
- 出于安全考虑,Bootstrap启动类加载器只包含包名为java、javax、sun等开头。
file:/C:/dev/Java/jdk1.8.0_231/jre/lib/resources.jar
file:/C:/dev/Java/jdk1.8.0_231/jre/lib/rt.jar
file:/C:/dev/Java/jdk1.8.0_231/jre/lib/sunrsasign.jar
file:/C:/dev/Java/jdk1.8.0_231/jre/lib/jsse.jar
file:/C:/dev/Java/jdk1.8.0_231/jre/lib/jce.jar
file:/C:/dev/Java/jdk1.8.0_231/jre/lib/charsets.jar
file:/C:/dev/Java/jdk1.8.0_231/jre/lib/jfr.jar
file:/C:/dev/Java/jdk1.8.0_231/jre/classes
扩展类加载器(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.calss.path
指定路径下的类库 - 该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载
- 通过
ClassLoader.getSystemClassLoader()
方法可以获取到该类加载器
示例:
public class ClassLoaderTest1 {
public static void main(String[] args) {
System.out.println("________启动类加载器________");
// 获取BoostrapClassLoader 能够加载api的路径
URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (URL element : urls) {
System.out.println(element.toExternalForm());
}
// 从上面的路径中随意选择一个类,来看看他的类加载器是什么【引导类加载器】
ClassLoader classLoader = Provider.class.getClassLoader();
System.out.println("【引导类加载器】"+classLoader); //null
System.out.println("________扩展类加载器________");
String extDirs = System.getProperty("java.ext.dirs");
for (String path : extDirs.split(";")) {
System.out.println(path);
}
// 从上面的路径中随意选择一个类,来看看他的类加载器是什么【扩展类加载器】
ClassLoader classLoader1 = CurveDB.class.getClassLoader();
System.out.println(classLoader1); // sun.misc.Launcher$ExtClassLoader@12a3a380
}
}
用户自定义类加载器
-
在Java的日常应用程序开发中,类的加载器几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,来制定类的加载方式。
-
为什么要自定义类加载器
- 隔离加载类
- 修改类的加载方式
- 扩展加载源
- 防止源码泄露
-
用户自定义类加载器实现步骤:
- 开发人员可以通过继承抽象类
java.lang.ClassLoader
类的方式,实现自己的类加载器,以满足一些特殊要求。 - 在JDK1.2 之前,在自定义类加载器时,总会去继承
ClassLoader
类并重写loadClass()
方法,从而实现自定义类的加载类,但是在JDK1.2 之后已经不再建议用户去覆盖loadClass()
方法,而是建议把自定义的类加载逻辑写在findClass()
方法中 - 在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承
URLClassLoader
类,这样就可以避免自己去编写findClass()
方法及其获取字节码流的方式,使自定义类加载器编写更加简洁。
关于ClassLoader
ClassLoader
类,它是一个抽象类,其后多有的类加载器都是继承自ClassLoader
(不包含启动类加载器)
方法名称 | 描述 |
---|---|
getParent() | 返回该类加载器的超类加载器 |
loadClass(String name) | 加载名为name的类,返回结果为java.lang.Class类的实例 |
findClass(String name) | 查找名为name的类,返回结果为java.lang.Class类的实例 |
defineClass(String name) | 查找名为name的已经被加载过的类,返回结果为java.lang.Class类的实例 |
defineClass(String name,byte[] b,int off,int len) | 把字节数组b中的内容转换为一个Java类,返回结果为java.lang.Class |
resolveClass(Class<?> c) | 连接指定一个java类 |
sun.misc.Launcher
它是一个java虚拟机的入口应用。
获取ClassLoader的途径
方法一:获取当前类的ClassLoader |
---|
clazz.getClassLoader() |
方法二:获取当前线程上下文的ClassLoader |
Thread.currentThread().getContextClassLoader() |
方法三:获取系统的ClassLoader |
ClassLoader.getSystemClassLoader() |
方法四:获取调用者的ClassLoader |
DriverManager.getCallerClassLoader() |
双亲委派机制
Java虚拟机对class文件采用的是按需加载的方式,也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时,Java虚拟机采用的是双亲委派模式,即把请求交由父类处理,他是一只任务委派模式。
- 工作原理
- 一个如果类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行;
- 如果父类的加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器;
- 如果父类加载器可以完成加载认为,就成功返回,倘若父类加载器无法完成此任务,子加载器才会尝试自己去加载,这就是双亲委派机制模式。
【举个例子】
情况一:引导类加载器
- 小孩拿了个梨。
- 小孩出于礼貌问,妈你吃吗?
- 妈见奶奶在,出于礼貌问,妈你吃吗?
- 奶奶想吃梨,把梨吃掉了。
情况二:系统类加载器
- 小孩拿了个梨。
- 小孩出于礼貌问,妈你吃吗?
- 妈见奶奶在,出于礼貌问,妈你吃吗?
- 奶奶不想吃梨对儿媳说,儿媳你吃吧。
- 妈妈不想吃梨对小孩说,儿子你吃吧。
- 小孩把梨吃了
示例:定义一个java.lang.LoadTest
package java.lang
public class LoadTest {
public static void main(String[] args) {
System.out.println("加载运行我");
}
}
结果:
java.lang.SecurityException: Prohibited package name: java.lang
java.lang
包由引导类加载器负责加载,而引导类出于安全考虑,仅会加载官方java.lang
包中的类,不允许用户自定义类使用该包名。
双亲委派机制的优势
- 避免类的重复加载
- 包含程序安全,防止核心API被篡改
沙箱安全机制
自定义一个java.lang.String
类
public class String {
static {
System.out.println("我是自定义的String类的静态代码块");
}
public static void main(java.lang.String[] args) {
System.out.println("Hello,Sting");
}
}
结果:
错误: 在类 java.lang.String
中找不到 main 方法, 请将 main 方法定义为:
public static void main(String[] args)
否则 JavaFX 应用程序类必须扩展javafx.application.Application
说明:
自定义String类,但是在加载定义String类的时候会率先使用引导类加载器加载,而引导类加载器在加载的过程中会先加载JDK自带的文件(rt.jar包中java\lang\String.class
),报错信息说没有main方法,就是因为加载的是rt.jar包中的String类。这样可以保证对java核心源代码的保护,这就是沙箱安全机制。
其他
在JVM中表示两个class对象是否为同一个类存在两个必要条件:
- 类的完整名必须一致,包含包名。
- 加载这个类的ClassLoader指(ClassLoader实例对象)必须相同。
- 换句话说,在JVM中,即使这两个类对象(class对象)来源同一个Class文件,被同一个虚拟机所加载,但只要加载它们的ClassLoader实例对象不同,那么这两个类对象也是不相等的。
对类加载器的引用
JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候,JVM需要保证这两个类型的加载器是相同的。
类的主动使用和被动使用
- 主动使用,分为七种情况:
- 创建类的实例
- 方位某个类或接口的静态变量,或者对该静态变量赋值
- 调用类的静态方法
- 反射(比如:
Class.forName("fun.letmetellyou.Test")
) - 初始化一个类的子类
- Java虚拟机启动时被标明为启动类的类
- JDK 7 开始提供的动态语言支持:
java.lang.invoke.MethodHandle
实例解析结果REF_getStatic
、REF_putStatic
、REF_invokeStatic
句柄对应的类没有初始化,则初始化。
型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候,JVM需要保证这两个类型的加载器是相同的。