JVM 类加载机制详解
JVM 类加载机制详解
在 Java 虚拟机(JVM)中,类加载机制是一个非常重要的组成部分,它负责将类的字节码文件加载到内存中,并进行一系列的处理,最终使类能够被虚拟机使用。本文将详细介绍 JVM 类加载机制的相关内容。
一、类加载的概念
在 JVM 虚拟机实现规范中,通过 ClassLoader
类加载器把 *.class
字节码文件(文件流)加载到内存,并对字节码文件内容进行验证、准备、解析和初始化,最终形成可以被虚拟机直接使用的 java.lang.Class
对象,这个过程被称作类加载。类是在运行期间第一次使用时,被类加载器动态加载至 JVM。JVM 不会一次性加载所有类,因为这样会占用很多内存。
二、类的生命周期
类的生命周期包括以下 7 个阶段:
- 加载(Loading):通过类的完全限定名称获取定义该类的
*.class
字节码文件的二进制字节流,将其转换为运行时存储结构,并在内存中生成代表该类的Class
对象。 - 验证(Verification):确保
*.class
字节码文件中包含的信息符合当前虚拟机的要求,且不会危害虚拟机的安全,包括文件格式验证、元数据验证、字节码验证和符号引用验证。 - 准备(Preparation):为类变量分配内存并设置初始值(一般为 0 值,常量除外),实例变量不在此阶段分配内存。
- 解析(Resolution):将常量池的符号引用替换为直接引用。
- 初始化(Initialization):真正开始执行类中定义的 Java 程序代码,是虚拟机执行类构造器
<clinit>()
方法的过程。 - 使用(Using):程序对类进行实例化、调用其方法等操作。
- 卸载(Unloading):当类不再被使用时,由垃圾回收器进行卸载。
结束类生命周期的几种场景:
- 执行
System.exit()
方法。 - 程序正常执行结束。
- 程序执行中遇到了异常或错误而异常终止。
- 操作系统出现错误或强制结束程序而导致 JVM 虚拟机进程终止。
三、类加载过程
(一)加载
在加载阶段,JVM 主要完成以下 3 件事:
- 获取字节流:通过类的完全限定名称获取定义该类的
*.class
字节码文件的二进制字节流。转换存储结构:将该字节流表示的静态存储结构转换为 Metaspace 元空间区的运行时存储结构。 - 生成 Class 对象:在内存中生成一个代表该类的
Class
对象,作为元空间区中该类各种数据的访问入口。
*.class
字节码文件的加载方式有多种:
-
本地文件系统直接读取。
// 例如,可以从本地文件系统直接读取 FileInputStream fis = new FileInputStream("MyClass.class"); byte[] byteArray = new byte[fis.available()]; fis.read(byteArray); fis.close(); // 也可以从网络中通过服务器响应读取,如 Web Applet 技术 // 还可以从 JAR、EAR、WAR 等压缩文件中读取等
-
从网络中通过服务器响应读取,例如 Web Applet 技术。
-
从 JAR、EAR、WAR 等压缩文件中读取。
-
运行时通过动态代理技术生成字节码文件,例如在
java.lang.reflect.Proxy
使用ProxyGenerator.generateProxyClass
的代理类的二进制字节流。 -
由其他文件或容器生成,例如由 tomcat 将
*.jsp
文件翻译成*.java
文件后,编译生成对应的*.class
字节码文件。
在加载阶段完成之后,*.class
字节码文件的类信息数据就会存储在元空间,同时在 JVM 虚拟机堆区生成一个该类的 Class
对象。
(二)验证
验证阶段主要确保 *.class
字节码文件中包含的信息符合当前虚拟机的要求,并不会危害虚拟机的安全。验证阶段会完成下面四个阶段的检验:
-
文件格式验证:验证字节流是否符合
*.class
字节码文件格式的规范,且能被当前版本的虚拟机处理。// 检查是否以魔数 0xCAFEBABE 开头 if (byteArray[0]!= 0xCA || byteArray[1]!= 0xFE || byteArray[2]!= 0xBA || byteArray[3]!= 0xBE) { throw new ClassFormatError("Invalid magic number in class file"); } // 检查主、次版本号是否在当前虚拟机处理范围之内 int majorVersion = (byteArray[4] << 8) | byteArray[5]; int minorVersion = (byteArray[6] << 8) | byteArray[7]; if (majorVersion > JVM_SUPPORTED_MAJOR_VERSION || (majorVersion == JVM_SUPPORTED_MAJOR_VERSION && minorVersion > JVM_SUPPORTED_MINOR_VERSION)) { throw new UnsupportedClassVersionError("Unsupported class file version"); } // 检查常量池的常量中是否有不被支持的常量类型(检查常量 tag 标志)等其他验证内容 //...
-
元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合 Java 语言规范的要求。
// 检查这个类是否有父类(除了 java.lang.Object 之外,所有的类都应当有父类) if (className!= "java.lang.Object" &&!classHasSuperclass(byteArray)) { throw new ClassFormatError("Class has no superclass"); } // 检查这个类的父类是否继承了不允许被继承的类(被 final 修饰的类)等其他验证内容 //...
-
字节码验证:通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的。
// 保证跳转指令不会跳转到方法体以外的字节码指令上 for (int i = 0; i < bytecodeLength; i++) { int opcode = byteArray[i] & 0xFF; if (opcode == JUMP_OPCODE) { int targetOffset = ((byteArray[i + 1] << 8) | byteArray[i + 2]) & 0xFFFF; if (targetOffset < 0 || targetOffset >= bytecodeLength) { throw new BytecodeVerificationError("Invalid jump target"); } } // 检查其他字节码验证规则,如类型转换的有效性、操作数栈与指令的配合等 //... }
-
符号引用验证:发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在连接的第三个阶段 —— 解析阶段中发生,确保解析动作能正常执行。
// 检查符号引用中通过字符串描述的全限定名是否能找到对应的类 String classNameFromSymbol = getClassNameFromSymbolReference(byteArray); try { Class.forName(classNameFromSymbol); } catch (ClassNotFoundException e) { throw new SymbolReferenceVerificationError("Class not found in symbol reference"); } // 检查在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段等验证内容 //...
为什么需要验证呢?Java 语言本身是相对安全的语言,但
*.class
字节码文件并不一定要求用 Java 源码编译而来,可以使用任何途径,甚至可用十六进制编译器直接编写来产生*.class
字节码文件。类的加载是 JVM 针对*.class
字节码文件的读取加载机制,所以虚拟机如果不检查输入的字节流,可能会因为载入了有害的字节流而导致系统崩溃,所以验证是虚拟机对自身保护的一项重要工作。另外,通过类加载机制的验证环节,可以增强解释器的运行期执行性能,因为解释器在运行期间无需再对每条执行指令进行检查。
(三)准备
类变量是被 static
修饰的变量,准备阶段为类变量分配内存并设置初始值,使用的是元空间区的内存。实例变量不会在这阶段分配内存,它会在对象实例化时,随着对象一起被分配在堆中。初始值一般为 0 值。
// 例如,下面的类变量 value 被初始化为 0 而不是 123
public static int value = 123;
// 如果类变量是常量,那么它将初始化为表达式所定义的值而不是 0
public static final int CONSTANT_VALUE = 123;
(四)解析
将常量池的符号引用替换为直接引用。
(五)初始化
初始化阶段才真正开始执行类中定义的 Java 程序代码。初始化阶段是虚拟机执行类构造器 <clinit>()
方法的过程。在准备阶段,类变量已经赋过一次系统要求的初始值,而在初始化阶段,根据程序员通过程序制定的主观计划去初始化类变量和其它资源。
<clinit>()
是由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的,编译器收集的顺序由语句在源文件中出现的顺序决定。所以,静态语句块只能访问到定义在它之前的类变量,定义在它之后的类变量只能赋值,不能访问。
// 例如以下代码中静态变量 i 只能赋值,不能访问,因为 i 定义在静态代码块的后面
static {
// 这里不能访问 i,会报错
// System.out.println(i);
}
static int i = 10;
<clinit>
线程安全,虚拟机会保证一个类的 <clinit>()
方法在多线程环境下被正确的加锁和同步,如果多个线程同时初始化一个类,只会有一个线程执行这个类的 <clinit>()
方法,其它线程都会阻塞等待,直到活动线程执行 <clinit>()
方法完毕。如果在一个类的 <clinit>()
方法中有耗时的操作,就可能造成多个线程阻塞,在实际过程中,该阻塞非常隐蔽,几乎不会被察觉。
四、类加载的时机
(一)主动引用
虚拟机规范中并没有强制约束何时进行加载,但是规范严格规定了只有下列六种情况必须对类进行加载:
-
当遇到
new
、getstatic
、putstatic
或invokestatic
这 4 条字节码指令时,比如new
一个对象,读取一个静态字段(未被final
修饰)、或调用一个类的静态方法时。// 当 jvm 执行 new 指令时会加载类,即当程序创建一个类的实例对象 MyClass obj = new MyClass(); // 当 jvm 执行 getstatic 指令时会加载类,即程序访问类的静态变量(不是静态常量,常量会被加载到运行时常量池) int staticValue = MyClass.staticVariable; // 当 jvm 执行 putstatic 指令时会加载类,即程序给类的静态变量赋值 MyClass.staticVariable = 10; // 当 jvm 执行 invokestatic 指令时会加载类,即程序调用类的静态方法 MyClass.staticMethod();
-
使用
java.lang.reflect
包的方法对类进行反射调用时如Class.forName("...")
,或newInstance()
等等。如果类没初始化,需要触发类的加载。try { Class<?> clazz = Class.forName("MyClass"); Object instance = clazz.newInstance(); } catch (ClassNotFoundException | InstantiationException | IllegalAccessException e) { e.printStackTrace(); }
-
加载一个类,如果其父类还未加载,则先触发该父类的加载。
class ChildClass extends ParentClass {} // 当加载 ChildClass 时,如果 ParentClass 未加载,会先加载 ParentClass
-
当虚拟机启动时,用户需要定义一个要执行的主类(包含
main()
方法的类),虚拟机会先加载这个类。 -
当一个接口中定义了 JDK8 新加入的默认方法(被
default
关键字修饰的接口方法)时,如果有这个接口的实现类发生了加载,则该接口要在实现类之前被加载。
(二)被动引用
除主动引用之外,所有引用类的方式都不会触发加载,称为被动引用。
被动引用的常见例子包括:
-
通过子类引用父类的静态字段,不会导致子类加载。
class ParentClass { public static int staticField = 10; } class ChildClass extends ParentClass {} // 这里不会加载 ChildClass,只会加载 ParentClass int value = ChildClass.staticField;
-
通过数组定义来引用类,不会触发此类的加载。该过程会对数组类进行加载,数组类是一个由虚拟机自动生成的、直接继承自
Object
的子类,其中包含了数组的属性和方法。MyClass[] array = new MyClass[10]; // 这里只会加载数组类,不会加载 MyClass
-
常量在编译阶段会存入调用类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发定义常量的类的加载。
class ConstantClass { public static final int CONSTANT = 10; } class OtherClass { public static void main(String[] args) { int value = ConstantClass.CONSTANT; // 这里不会加载 ConstantClass } }
五、类加载器
(一)什么是类加载器
在类加载过程的加载阶段,通过类的完全限定名,获取描述类的二进制流的实现类,被称为 “类加载器”。
(二)类加载器分类
从 JVM 虚拟机的角度来讲,只存在以下两种不同的类加载器:
- 启动类加载器(Bootstrap ClassLoader):使用 C++ 实现,是虚拟机的一部分。它负责将存放在
<JRE_HOME>\lib
目录中的,或者被-Xbootclasspath
参数所指定的路径中的,并且是虚拟机识别的(仅按照文件名识别,如rt.jar
,名字不符合的类库即使放在lib
目录中也不会被加载)类库加载到虚拟机内存中。例如java.util.*
,java.io.*
,java.lang.*
类等常用基础库都是由启动类加载器加载。启动类加载器无法被 Java 程序直接引用。 - 其它类的加载器:使用 Java 实现,独立于虚拟机,继承自抽象类
java.lang.ClassLoader
。
从 Java 开发人员的角度看,类加载器可以划分得更细致一些:
- 扩展类加载器(Extension ClassLoader):该类加载器是由
ExtClassLoader
(sun.misc.Launcher$ExtClassLoader
)实现,负责将<JRE_HOME>/lib/ext
或者被java.ext.dir
系统变量所指定路径中的所有类库加载到内存中,例如swing
系列、内置的js
引擎、xml
解析器等以javax
开头的扩展类库都是由扩展类加载器加载,开发者可以直接使用扩展类加载器。 - 应用程序类加载器(Application ClassLoader):该类加载器是由
AppClassLoader
(sun.misc.Launcher$AppClassLoader
)实现。由于这个类加载器是ClassLoader
中的getSystemClassLoader()
方法的返回值,因此也被称为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库,比如我们自己编写的自定义类或第三方jar
包。开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。
(三)什么情况下需要自定义类加载器?
- 隔离加载类。在某些框架内进行中间件与应用的模块之间进行隔离,把类加载到不同的环境。
- 修改类加载方式。
- 扩展加载源。比如从数据库、网络、电视机顶盒进行类加载。
- 防止源码泄漏。比如编译时字节码进行加密,需要通过自定义类加载器对字节码进行解密还原。
六、双亲委派模型
应用程序是由三种类加载器互相配合,从而实现类加载,除此之外还可以加入自己定义的类加载器。类加载器之间的层次关系,称为双亲委派模型(Parents Delegation Model)。该模型要求除了顶层的启动类加载器外,其它的类加载器都要有自己的父类加载器。这里的父子关系一般通过组合关系(Composition)来实现,而不是继承关系(Inheritance)。
(一)双亲委派工作机制
一个类加载器首先将类加载请求转发到父类加载器,只有当父类加载器无法完成时才尝试自己加载。
(二)双亲委派的作用
- 每个类只会加载一次,解决了各个类加载器加载基础类的统一问题(基础类库由上层的加载器进行加载)。
- 防止恶意破坏的类加载,内存中不会出现多份同样的字节码的系统类,保证 Java 程序安全稳定运行。
例如:
java.lang.Object
存放在rt.jar
中,如果编写另外一个java.lang.Object
并放到ClassPath
中,程序可以 - 启动类加载器(Bootstrap ClassLoader):使用 C++ 实现,是虚拟机的一部分。它负责将存放在