目录
0. 概述
Java中数据类型分为基本数据类型和引用数据类型,基本数据类型由虚拟机预先定义,引用数据类型需要经过类的加载。
按照JVM规范,从Class文件到加载到内存中的类,到类卸载出内存。它的生命周期包括七个阶段。
1. 类加载子系统的作用
由上图可以看出类加载器工作的主要流程。首先类加载器从文件或者网络中获取到字节码文件(在class文件开头的四个字节, 存放着class文件的魔数, 这个魔数是class文件的标志,他是一个固定的值: 0XCAFEBABE 。 也就是说他是判断一个文件是不是class格式的文件的标准, 如果开头四个字节不是0XCAFEBABE, 那么就说明它不是class文件, 不能被JVM识别),然后会经过三个阶段,分别为加载阶段,连接阶段和初始化阶段。
应该注意的是类加载器只负责class文件的加载而对于是否能够运行,他是不管的。是否能够运行由执行引擎决定。
加载的类信息(DNA元数据模版,jvm会根据这个模版实例化出n个一模一样的实例)存放于“方法区”。方法区中还会存放运行时常量池信息,可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)。
2. 类加载器的角色
Class文件相当于是一个模板,而在执行的时候需要加载到JVM中来根据这个文件实例化出n个一模一样的实例。
Class文件加载到JVM中被称为DNA元数据模板,放在方法区。
Class文件从进入JVM到变成元数据模板需要一个运输工具,这个类加载器就充当这个运输功能。
3. 类加载过程
3.1 显式加载和隐式加载
class文件的显式加载与隐式加载的方式是指JVM加载class文件到内存的方式。
- 显式加载指的是在代码中通过调用ClassLoader加载class对象,如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载class对象。
- 隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象,而是通过虚拟机自动加载到内存中,如在加载某个类的class文件时,该类的class文件中引用了另外一个类的对象,此时额外引用的类将通过JVM自动加载到内存中。
//隐式加载
User user=new User();
//显式加载,并初始化
Class clazz=Class.forName("com.test.java.User");
//显式加载,但不初始化
ClassLoader.getSystemClassLoader().loadClass("com.test.java.Parent");
3.2 类加载步骤
当程序主动使用某个类时,如果该类还未被加载到内存中,则JVM会通过加载、连接、初始化3个步骤来对该类进行初始化。如果没有意外,JVM将会连续完成3个步骤,所以有时也把这3步骤统称为类加载或类初始化。
我们来研究下面一段代码的加载流程
/**
*示例代码
*/
public class HelloLoader {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
用流程图表示一下上述的示例代码:
3.3 加载阶段
就是将JAVA类的字节码文件加载到机器内存,并在内存中构建出Java类的原型——类模板文件。
所谓类模板对象,其实就是Java类在]VM内存中的一个快照,JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中,这样]VM在运行期便能通过类模板而获取Java类中的任意信息,能够对Java类的成员变量进行遍历,也能进行Java方法的调用。反射的机制即基于这一基础。
加载的类在JVM中创建相应的类结构,类结构会存储在方法区(JDKl.8之前:永久代;J0Kl.8及之后:元空间)。
3.3.1 加载流程:
通过类的全限定名获取定义此类的二进制字节流
将这个字节流所代表的静态储存结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.long.Class对象,作为这个类的各种数据的访问入口,类将.class文件加载至元空间后,会在堆中创建一个Java.lang.Class对象,用来封装类位于方法区内的数据结构,该Class对象是在加载类的过程中创建的,每个类都对应有一个Class类型的对象。
Class clazz = Class.forName("java.lang.String");
//获取当前运行时类声明的所有方法
Method[] ms = clazz.getDecla#FF0000Methods();
for (Method m : ms) {
//获取方法的修饰符
String mod = Modifier.toString(m.getModifiers());
System.out.print(mod + "");
//获取方法的返回值类型
String returnType = (m.getReturnType()).getSimpleName();
System.out.print(returnType + "");
//获取方法名
System.out.print(m.getName() + "(");
//获取方法的参数列表
Class<?>[] ps = m.getParameterTypes();
if (ps.length == 0) {
System.out.print(')');
}
for (int i = 0; i < ps.length; i++) {
char end = (i == ps.length - 1) ? ')' : ',';
//获取参教的类型
System.out.print(ps[i].getSimpleName() + end);
}
}
加载Class文件的方式
- 从本地系统中直接加载
- 通过网络获取,典型场景:Web Applet
- 从zip压缩包中读取,成为日后jar、war格式的基础
- 运行时计算生成,使用最多的是:动态代理技术
- 由其他文件生成,典型场景:JSP应用
- 从专有数据库中提取.class文件,比较少见
- 从加密文件中获取,典型的防Class文件被反编译的保护措施
3.3.2 数组类的加载
数组类本身并不是由类加载器负责创建,而是由JVM在运行时根据需要创建的,但是数组元素仍然需要依靠类加载器去创建。
创建数组类(下述简称A)的过程
- 如果数组的元素类型是引用类型,那么就遵循定义的加载过程递归加载和创建数组A的元素类型;
- JVM使用指定的元素类型和数组维度来创建新的数组类。
如果数组的元素类型是引用类型,数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。
3.4 连接阶段
3.4.1 验证环节
保证Class文件的字节流中包含信息符合当前虚拟机的要求,保证类被正确加载,不会危害虚拟机自身的安全。
主要的验证方式:文件格式验证,元数据验证,字节码验证,符号引用验证。
![](https://i-blog.csdnimg.cn/blog_migrate/906a6110514206d6fc318d618034321b.png)
其中格式验证会在加载阶段一起执行。验证通过以后,类加载器才会成功将类的二进制数据信息加载到方法区。格式验证之外的验证操作将会在方法去中进行。
验证的具体操作:
格式验证:是否以魔数0XCAFEBABE开头,主版本和副版本号是否在当前Java虚拟机的支持范围内,数据中每一个项是否都拥有正确的长度等。
语义检查:Java虚拟机会进行字节码的语义检查,但凡在语义上不符合规范的,虚拟机也不会给予验证通过。
字节码验证:Java虚拟机还会进行字节码验证,字节码验证是验证过程是一个复杂的过程。它试图通过对字节码流的分析,判断字节码是否可以被正确地执行。(栈映射帧(StackMapTable)就是在这个阶段,用于检测在特定的字节码处,其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是,100%准确地判断一段字节码是否可以被安全执行是无法实现的,因此,该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查,虚拟机也不会正确装载这个类。但是,如果通过了这个阶段的检查,也不能说明这个类是完全没有问题的。)
符号引用的验证:校验器还将进符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此,在验证阶段,虚拟机就会检查这些类或方法是否是真实存在的,并且当前类有权限访问这些数据,如果一个需要使用类无法在系统中找到,则会抛出NoClassDefFoundError,如果一个方法无法被找到,则会抛出NoSuchMethodError。此阶段在解析环节才会执行。
3.4.2 准备环节
为类变量分配内存并且设置该类变量的默认初始值,不同的类型初始值不同。(Java并不支持boolean类型,对于boolean类型,内部实现是int,由于int的默认值是0,故对应的,boolean的默认值就是false。)
(所以可以变量的声明放在变量的赋值之后,因为在这个阶段JVM中已经有这个变量了,再执行初始化阶段时就按照顺序赋值就行,最终结果是最后执行的赋值语句。但是在声明之前不能使用该变量,否则会导致非法的前向引用)
这里不包含用final修饰的static,因为其在编译的时候就被分配,在准备阶段进行显式的出实话,而不是默认初始化。
不会为实例变量进行初始化,类变量分配在方法去,实例变量分配在堆。
3.4.3 解析环节
将常量池内的类、接口、字段和方法的符号引用转变为直接引用的过程
事实上,解析操作往往会伴随着JVM在执行完初始化之后再执行。
符号引用就是一些字面量的引用,和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中,通过常量池进行了大量的符号引用。但是在程序实际运行时,只有符号引用是不够的,比如当方法被调用时,系统需要明确知道该方法的位置。Java虚拟机为每个类都准备了一张方法表,将其所有的方法都列在表中,当需要调用一个类的方法的时候,只要知道这个方法在方法表中的偏移量就可以直接调用该方法。
3.5 初始化阶段
初始化阶段就是执行类构造器方法<clinit>()的过程。
此方法不需定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
构造器方法中指令按语句在源文件中出现的顺序执行。
<clinit>()不同于类的构造器。(关联:构造器是虚拟机视角下的<init>())
若该类具有父类,JVM会保证子类的<clinit>()执行前,父类的<clinit>()已经执行完毕。
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁。
当类中没有静态变量和静态代码块的话,字节码文件中便不会clinit()方法
任何一个类声明以后,至少存在一个构造器方法,对应的就是init()方法
3.5.1 Static和final的搭配问题
问题:使用static+ final修饰的字段的显式赋值的操作,到底是在哪个阶段进行的赋值?
结论:
在链接阶段的准备环节赋值的情况:
- 对于基本数据类型的字段来说,如果使用static final修饰,则显式赋值(直接赋值常量,而非调用方法通常是在链接阶段的准备环节进行
- 对于String来说,如果使用字面量的方式赋值,使用static final修饰的话,则显式赋值通常是在链接阶段的准备环节进行
- 在初始化阶段<clinit>()中赋值的情况: 排除上述的在准备环节赋值的情况之外的情况。
即:使用static+final修饰,且显示赋值中不涉及到方法或构造器调用的基本数据类到或String类型的显式财值,是在链接阶段的准备环节进行。
public static final int INT_CONSTANT = 10; // 在链接阶段的准备环节赋值
public static final int NUM1 = new Random().nextInt(10); // 在初始化阶段clinit>()中赋值
public static int a = 1; // 在初始化阶段<clinit>()中赋值
public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100); // 在初始化阶段<clinit>()中赋值
public static Integer INTEGER_CONSTANT2 = Integer.valueOf(100); // 在初始化阶段<clinit>()中概值
public static final String s0 = "helloworld0"; // 在链接阶段的准备环节赋值
public static final String s1 = new String("helloworld1"); // 在初始化阶段<clinit>()中赋值
public static String s2 = "hellowrold2"; // 在初始化阶段<clinit>()中赋值
3.5.2 <clinit>()的线程安全性
虚拟机会保证一个类的()方法在多线程环境中被正确地加锁、同步,如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的<clinit>()方法,其他线程都需要阻塞等待,直到活动线程执行<clinit>()方法完毕。
4. 类加载器的分类
JVM支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined ClassLoader)。
JVM中自定义类加载器是指所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。
不管JVM怎么划分我们最常用的只有三个:引导类加载器,扩展类加载器,应用程序类加载器
4.1 虚拟机自带的加载器
启动类加载器(引导类加载器,Bootstrap ClassLoader)
使用C/C++实现,嵌套在JVM内部
用来加载Java的核心库(JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容),用于提供JVM自身需要的类
不继承于Java.long.ClassLoader,没有父加载器
加载扩展类和应用程序类加载器,并指定为他们的父类加载器
出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
如果是启动加载器进行加载的类,在java中获取当前加载器如果返回null
扩展类加载器(Extension ClassLoader)
Java语言编写,由sun.misc.Launcher$ExtClassLoader实现。
派生于ClassLoader类
父类加载器为启动类加载器
从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/1ib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。
应用程序类加载器(系统类加载器,AppClassLoader)
java语言编写,由sun.misc.LaunchersAppClassLoader实现
派生于ClassLoader类
父类加载器为扩展类加载器
它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载
通过ClassLoader#getSystemclassLoader() 方法可以获取到该类加载器
这里所说的加载器中间的父类关系,并不是Java中的继承关系,而是一种包含关系。正是由于子类加载器中包含着父类加载器的引用,所以可以通过子类加载器的方法获取对应的父类加载器。
class ClassLoader{
ClassLoader parent;//父类加载器
public ClassLoader(ClassLoader parent){
this.parent = parent;
}
}
class ParentClassLoader extends ClassLoader{
public ParentClassLoader(ClassLoader parent){
super(parent);
}
}
class ChildClassLoader extends ClassLoader{
public ChildClassLoader(ClassLoader parent){ //parent = new ParentClassLoader();
super(parent);
}
}
4.2 用户自定义的类加载器
在日常的开发中,类几乎是由上述的三类加载器相互配合的使用,但是有时候需要一些特殊的功能,则需要我们自定义类加载器。
自定义类加载器的功能
- 隔离加载类
- 修改类加载方式
- 扩展加载源
- 防止源码泄露
自定义类实现的步骤
- 需要复杂的需求时,建议继承覆盖findClass()方法,把自己的逻辑写在方法内
- 需求不复杂是,可以直接继承URLClassLoader类
5. 获取ClassLoader的方法
//方式一:获取当前ClassLoader
clazz.getClassLoader()
//方式二:获取当前线程上下文的ClassLoader
Thread.currentThread().getContextClassLoader()
//方式三:获取系统的ClassLoader
ClassLoader.getSystemClassLoader()
// 方式四:获取调用者的ClassLoader
DriverManager.getCallerClassLoader()
6. 命名空间
6.1 何为类的一致性
JVM中两个对象是否为同一类存在两个必要条件
- 类的完整类名必须一致,包括包名
- 加载类的ClassLoader必须相同
换句话说就是,在JVM中,即使这两个类对象(class对象)来源同一个Class文件,被同一个虚拟机所加载,但只要加载它们的ClassLoader实例对象不同,那么这两个类对象也是不相等的。
6.2 命名空间
- 每个类加载器都有自己的命名空间,命名空间由该加载器及所有的父加载器所加载的类组成
- 在同一命名空间中,不会出现类的完整名字(包括类的包名)相同的两个类
- 在不同的命名空间中,有可能会出现类的完整名字(包括类的包名)相同的两个类
在大型应用中,我们往往借助这一特性,来运行同一个类的不同版本
7. 对类加载器的引用
JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候,JVM需要保证这两个类型的类加载器是相同的。