文章目录
Java 代码的运行流程:
类加载的时机处于 Java 解释器 将字节码文件翻译成机器代码的前半部分。
类加载的时机
类的整个生命周期分为七步,如下图:
当然,上述的七步在顺序上并不是严格约定的。加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的,类型的加载过程必须按 照这种顺序按部就班地开始,而解析阶段则不一定:它在某些情况下可以在初始化阶段之后再开始, 这是为了支持Java语言的运行时绑定特性。
初始化阶段使用的是:Lazy 机制。
触发初始化动作的几种情况
- new、getstatic、putstatic或invokestatic这四条字节码指令
- 反射调用
- 当初始化类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
- 当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的那个类),虚拟机会先初始化这个主类。
- 当使用JDK 7新加入的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解 析结果为REF_getStatic、REF_p utStatic、REF_invokeStatic、REF_newInvokeSp ecial四种类型的方法句 柄,并且这个方法句柄对应的类没有进行过初始化,则需要先触发其初始化
- 当一个接口中定义了JDK 8 新加入的默认方法(被default关键字修饰的接口方法)时,如果有 这个接口的实现类发生了初始化,那该接口要在其之前被初始化。
书中被动引用的例子可以很好的解释:Java中实现单例之饿汉静态内部类
类加载的过程
加载:类加载的一小部分工作
- 通过一个类的全限定名来获取定义此类的二进制字节流。
- 将这个
字节流所代表的静态存储结构转化为方法区的运行时数据结构
。 - 在内存中生成一个代表这个类的 java.lang.Class 对象,作为方法区这个类的各种数据的访问入 口。
加载阶段结束后,Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中了
,方法区中的数据存储格式完全由虚拟机实现自行定义,《Java虚拟机规范》未规定此区域的具体 数据结构。类型数据妥善安置在方法区之后,会在Java堆内存中实例化一个java.lang.Class类的对象, 这个对象将作为程序访问方法区中的类型数据的外部接口。
加载阶段与连接阶段的部分动作(如一部分字节码文件格式验证动作)是交叉进行的,加载阶段尚未完成,连接阶段可能已经开始,但这些夹在加载阶段之中进行的动作,仍然属于连接阶段的一部分,这两个阶段的开始时间仍然保持着固定的先后顺序。
验证
这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求
,保证这些信息被当作代码运行后不会危害虚拟机自身的安全。
主要包含:文件格式验证、元数据验证、字节 码验证和符号引用验证。
1. 文件格式验证
该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内
,格式上符 合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的,只有通过了这个阶段的 验证之后,这段字节流才被允许进入Java虚拟机内存的方法区中进行存储,所以后面的三个验证阶段 全部是基于方法区的存储结构上进行的,不会再直接读取、操作字节流
了
2. 元数据验证
对存储在方法区的数据进行语义上检查。比如:
- 这个类是否有父类(除了java.lang.Object之外,所有的类都应当有父类)。
- 这个类的父类是否继承了不允许被继承的类(被final修饰的类)。
- ·如果这个类不是抽象类,是否实现了其父类或接口之中要求实现的所有方法。
- 重载是否有问题。
3. 字节码验证
通过数据流分析和控制流分析,确定 程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型校验完毕以后,这阶段就要 对类的方法体(Class文件中的Code属性)进行校验分析,保证被校验类的方法在运行时不会做出危害 虚拟机安全的行为。如:
- 保证任何跳转指令都不会跳转到方法体以外的字节码指令上。
- 强制类型转换
4. 符号引用验证
符号引用验证可以看作是对类自身以外(常量池中的各种符号 引用)的各类信息进行匹配性校验,通俗来说就是,该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。来看本阶段一般情况下会抛出的: java.lang.IllegalAccessError,java.lang.NoSuchFieldError、java.lang.NoSuchM ethodError等
准备
准备阶段是正式为类中定义的变量(即静态变量,被static修饰的变量)分配内存并设置类变量初始值的阶段。这时候进行内存分配的仅包括类变量,而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次是这里所说的初始值“通常情况”下是数据类型的零值,假设一个类变量的定义为:
public static int value = 123;
上述这样写的话,在准备阶段不会直接设置为123,而是此类数据类型的零值。把value赋值为123的动作要到类的初始化阶段才会被执行。
public static final int value = 123;
但是如果像上述这样子写的话,在准备阶段就会直接设置为123,不会再设置零值。
解析
解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程
符号引用和直接引用的区别:
- 符号引用(Symbolic References):
符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量
,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引 用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同, 但是它们能接受的符号引用必须都是一致的,因为符号引用的字面量形式明确定义在《Java虚拟机规 范》的Class文件格式中。 - 直接引用(Direct References):
直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄
。直接引用是和虚拟机实现的内存布局直接相关的,同一个符号引用在不同虚 拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经在虚拟机的内存中存在。
初始化
按照程序逻辑来初始化类变量和 static 块。
类加载器
Java虚拟机设计团队有意把 类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节 流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”(Class Loader)。
对于 任意一个类,都必须 由加载它的类加载器和这个类本身 一起共同确立 其在Java虚拟机中的唯一性。
双亲委派模型
- 启动类加载器:<JAVA_HOME>\lib,被`-Xbootclasspath``参数所指定的路径,
- 拓展类加载器:<JAVA_HOM E>\lib\ext 目录下,被
java.ext.dirs系统变量
所 指定的路径中所有的类库 - 应用程序类加载器:它负责加载用户类路径 (ClassPath)上所有的类库,一般情况下就是 默认类加载器。
双亲委派模型的工作过程是:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到最顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去完成加载。
- 原因是:Java 中的类随着它的类加载器一起具备了一种带有优先级的层次关系,否则,我们如果自己编写了Object类的话,就会与系统中的类冲突,造成混乱。
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
// 首先,检查请求的类是否已经被加载过了
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器抛出ClassNotFoundException
// 说明父类加载器无法完成加载请求
}
if (c == null) {
// 在父类加载器无法加载时
// 再调用本身的findClass方法来进行类加载
c = findClass(name);
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
双亲委派的破坏
- 自定义加载器
- 模块化
- 线程上下文类加载器 (Thread Context ClassLoader):基础加载器调用用户自定义加载器。