背景
java 文件在运行之前,必须经过编译和类加载两个过程:
- 编译过程:把 .java 文件 编译成 .class 文件
- 类加载过程:把 .class 文件加载到 JVM 内存里,加载完成后就会得到一个 class 对象,我们就可以使用 new 关键字 实例化这个对象
类加载器主要包含三种:
- 启动类加载器(bootstrap classloader):负责将 JAVA_HOME/lib 下面的类库加载到内存中
- 标准拓展类加载器(extension classloader):负责将 JAVA_HOME/lib/ext 或者由系统变量 java.ext.dir 指定位置中的类库加载到内存中
- 应用程序类加载器(application classloader):负责将 系统类路径(CLASSPATH)中指定的类库加载到内存中
除此之外,还有自定义的类加载器,它们之间的关系被称为 类加载器的双亲委派模型。该模型要求除了顶层的启动类加载器之外,其他的类加载器都应该有自己的父类加载器。这种关系一般通过 组合关系 实现,而不是继承。
类加载过程
Class 文件需要加载到虚拟机中才能被运行和使用,系统加载Class 类型的文件主要包含三步:加载->连接->初始化。连接过程又分为 验证-> 准备 -> 解析。
加载
类加载过程的第一步,主要完成下面 3 件事情:
- 通过全类名获取定义此类的二进制字节流
- 将字节流所代表的静态存储结构转换为方法区的运行时的数据结构
- 在内存中生成一个代表该类的 class 对象,作为方法区对这些数据的访问入口。
加载这一步主要是通过类加载器完成的。类加载器有很多种,当我们想要加载一个类的时候,具体是哪个类加载器加载由 双亲委派模型 决定。
每个 Java 类都有一个引用指向加载它的 ClassLoader 。不过,数组类不是通过 ClassLoader 创建的,而是 JVM 在需要的时候自动创建的,数组类通过 getClassLoader() 方法获取 ClassLoader 的时候和该数组的元素类型的 ClassLoader 是一致的。
一个非数组类的加载阶段(加载阶段获取类的二进制字节流的动作)是可控性最强的阶段,这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式(重写一个类加载器的 loadClass() 方法)
加载阶段与连接阶段的部分动作是交叉进行的,加载阶段尚未结束,连接阶段可能就已经开始了。
验证
验证时连接阶段的第一步,这一阶段的目的是确保 Class 文件的字节流中包含的信息符合 《JAVA 虚拟机规范》的全部约束要求,保证这些信息被当做代码运行后不会危害虚拟机自身的安全。
验证阶段这一步在整个类加载过程中耗费的资源还是相对较多的,但是很有必要,可以有效防止恶意代码的执行。
不过验证阶段也不是必须要执行的阶段。如果程序运行的全部代码都已经被反复使用和验证过,在生产环境的实施阶段就可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施,以缩短虚拟机类加载的时间。
验证阶段主要由四个阶段组成:
- 文件格式验证(Class 文件格式检查)
- 元数据验证(字节码语义检查)
- 字节码验证(程序语义检查)
- 符号引用验证(类的正确性检查)
文件格式验证这一阶段基于该类的二进制字节流进行的。主要目的是保证输入的字节流能正确地解析并存储于方法区内,格式上符合描述一个 Java 类型信息的要求。除了这一阶段之外,其余三个验证阶段都是基于方法区的存储结构上进行的,不会再直接读取、操作字节流了。
方法区是属于 JVM 运行时数据区域的一块逻辑区域,是各个线程共享的内存区域。当虚拟机要使用一个类时,它需要读取并解析 Class 文件获取相关信息,再将信息存入到方法区。方法区会存储已被虚拟机加载的 类信息、字段信息、方法信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些内存都将在方法区中分配。对于该阶段有以下几点需要注意:
- 这时候进行内存分配的仅包括类变量(即静态变量,被static 关键字修饰的变量,只与类相关,因此被称为类变量),而不包含实例变量。实例变量会在对象实例化时随着对象一起分配在 Java 堆中。
- 理论上,类变量所使用的内存都应在 方法区 中进行分配。但是在 JDK7 及以后,HotSpot 已经把原本放在永久代的字符串常量池、静态变量等移动到了堆中,这个时候类变量会随着 Class 对象一起存放到 Java 堆中。
- 这里所设置的初始值 通常情况下 是数据类型默认的零值
基本数据类型的零值
解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对 类 或 接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。
初始化
初始化阶段是执行初始化方法 <clinit>() 方法的过程,是类加载的最后一步,这一步 JVM 才开始真正执行类中定义的 Java 程序代码(字节码)。
<clinit>()方法是在编译之后自动生成的。
对于初始化阶段,虚拟机严格规范了有且仅有 6 种情况,必须对类进行初始化(只有主动去使用类才会初始化类)
- 当遇到 new 、getstatic、putstatic 或 invokestatic 这四条字节码指令时,比如 new 一个类,读取一个静态字段,或者调用一个类的静态方法时
- 使用 java.lang.reflect 包的方法对类进行反射调用时 。比如 Class.forname("...")
- 初始化一个类,如果其父类还未初始化,则先触发该父类的初始化
- 当虚拟机启动时,用户需要定义一个要执行的主类(包含 main 方法的类),虚拟机会先初始化这个类
- MethodHandle 和 VarHandle 可以看作是轻量级的反射调用机制,而要想使用这 2 个调用, 就必须先使用 findStaticVarHandle 来初始化要调用的类
- 当一个接口中定义了 JDK8 新加入的默认方法(被default 关键字修饰的接口方法)时,如果有这个接口的实现类发生了初始化,那该接口要在其之前被初始化。
类卸载
该类的 Class 被 GC。
类卸载需要满足 3 个要求:
- 该类的所有实例对象都被 GC,也就是说堆中不存在该类的实例对象
- 该类没有在其他任何地方被引用
- 该类的类加载器的实例已经被 GC
所以,在 JVM生命周期内,由 JVM 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。
JDK 自带的 BootstrapClassLoader
, ExtClassLoader
, AppClassLoader
负责加载 JDK 提供的类,所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的,所以使用我们自定义加载器加载的类是可以被卸载掉的。
著作权归JavaGuide(javaguide.cn)所有 基于MIT协议 原文链接:https://javaguide.cn/java/jvm/class-loading-process.html
双亲委派模型
某个特定类加载器在接到加载类的请求时,首先将加载任务委托给父类加载器,依次递归,如果父类加载器可以完成加载任务,就成功返回;只有父类加载器无法完成加载任务时,才会自己加载。
使用双亲委派模型的好处是:
- 安全性:这种层级关系实际上代表着一种优先级,也就是所有的类加载优先给到 bootstrap classloader,那么对于核心类库中的类就没办法被破坏(比如,如果自己在程序中写了一个 java.lang.Object 类,那么在程序运行的时候就有两个 Object 类。双亲委派模型可以保证加载的是 JRE 里面的那个 Object 类,而不是自定义的 Object 类。因为 AppClassLoader 在加载程序中的 Object 类的时候会委托给 ExrClassLoader ,ExtClassLoader 又会委托给 BootStrapClassLoader 。此时 BootStrapClassLoader 发现自己已经加载过 Object 类了,会直接返回,不会再重新加载 Object 类)
- 这种层级关系的设计可以避免重复加载导致程序混乱,如果父加载器加载过了,子加载器就不会再去加载了。