当前位置：首页 > article >正文

JVM 虚拟机的编译器、类加载过程、类加载器有哪些？

article 2024/11/13 9:28:51

JVM 虚拟机的编译器

编译器可以分为：前端编译器、JIT 编译器、AOT编译器。

前端编译器：源代码 --> 字节码

在Java语言中，JDK安装目录中的javac就是编译器。它负责将Java源代码编译为字节码。因为处于编译的前期，javac也叫做前端编译器。

JIT 编译器：字节码 --> 机器码

即时编译器（Just-In-Time Compiler，JIT）

Java源代码转化为字节码之后，要运行它，有两种选择：

使用 Java 解释器，执行字节码。
使用 JIT（Just-In-Time Compiler）编译器 将字节码转化为机器码。

JIT 编译器在程序运行时，对频繁执行的字节码进行即时编译，将其转换为本地机器码，从而提高程序的执行效率。

HotSpot 虚拟机的两个即时编译器

在 HotSpot 虚拟机内置了两个即时编译器，分别称为 Client Compiler 和 Server Compiler。这两种不同的编译器衍生出两种不同的编译模式，我们分别称之为：C1 编译模式，C2 编译模式。

C1 编译模式会将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑。
C2 编译模式，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

AOT 编译器：源代码 --> 机器码

提前编译器（Ahead-of-Time Compiler，AOT）

AOT 编译器的基本思想是：在程序执行前生成 Java 方法的本地代码，以便在程序运行时直接使用本地代码。

HotSpot 虚拟机的三种运行模式

注意，对于 HotSpot 虚拟机来说，其一共有三种运行模式可选，分别是：

混合模式（Mixed Mode）。即 C1 和 C2 两种模式混合起来使用，这是默认的运行模式。如果你想单独使用 C1 模式或 C2 模式，使用 -client 或 -server 打开即可。
解释模式（Interpreted Mode）。即所有代码都解释执行，使用 -Xint 参数可以打开这个模式。
编译模式（Compiled Mode）。此模式优先采用编译，但是无法编译时也会解释执行，使用 -Xcomp 打开这种模式。

在命令行中输入 java -version 可以看到，我机器上的虚拟机使用 Mixed Mode 运行模式。

JVM 虚拟机类加载过程

Java 中的类加载过程分为：加载（Loading）、链接（Linking）、初始化（Initialization）。
在这里插入图片描述

加载（Loading）：阶段的目的是将类的.class文件加载到JVM中。在这个阶段，JVM 会根据类的全限定名来获取定义该类的二进制字节流，并将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
链接（Linking）：又分为验证（Verification）、准备（Prepartion）、解析（Resolution）。
1. 验证：校验类的正确性，包括：
  1. 文件格式验证：验证字节流是否符合Class文件格式的规范。比如，是否以0xCAFEBABE开头。
  2. 元数据验证：对字节码描述进行语义分析，是否遵循Java规范。比如一个类是否继承了多个类。
  3. 字节码验证：比如验证指令代码序列是否能够正常工作。
  4. 符号引用验证：确保解析动作能够正确执行。
2. 准备：给类中定义的变量（被static修饰的静态变量）分配内存，并设置初始值。
3. 解析：虚拟机将常量池内的符号引用替换为直接引用。（解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行）
初始化（Initialization）：初始化阶段是执行初始化方法 <clinit>()方法的过程，是类加载的最后一步，这一步 JVM 才开始真正执行类中定义的 Java 程序代码(字节码)。

对于初始化阶段，有些情况必须立即初始化（如下）。其他情况，则是进行懒加载（首次用到的时候才初始化）
1. 遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，会立即初始化。
2. 使用反射机制时，立即初始化。
3. 初始化一个类时，其父类没初始化，则会立即初始化父类。
卸载（Unloading）：对象被垃圾回收。

类加载器

类加载器主要作用于 JVM 虚拟机类加载过程中的加载阶段。

如何比较两个类是否“相等”

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性。所以：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

双亲委派机制

站在JAVA虚拟机的角度来讲，只存在两种不同的类加载器：

一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；
另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。

每一个类都有一个对应它的类加载器。系统中的 ClassLoader 在协同工作的时候会默认使用 双亲委派模型。其工作过程为：

当一个类加载器收到了类加载的请求，不会自己去加载这个类，而是委派给父类加载器完成。
只有当父类加载器无法完成这个加载请求时（它搜索范围中没找到对应的类信息），子加载器才会尝试自己去完成加载。

在这里插入图片描述

父类加载器

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。

三层类加载器

双亲委派机制中的主要的三层类加载器，他们分别是：启动类加载器、扩展类加载器、应用程序类加载器。

BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由 C++实现，负责加载 %JAVA_HOME%/lib目录下的 jar 包和类，或者被 -Xbootclasspath参数指定的路径中的所有类。
ExtensionClassLoader(扩展类加载器) ：主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类，或被 java.ext.dirs 系统变量所指定的路径下的 jar 包。
AppClassLoader(应用程序类加载器) ：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。

双亲委派机制的好处

双亲委派模型保证了 Java 程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类）。

如何破坏双亲委派机制

答：有如下几种方法：

通过自定义类加载器，重写loadClass()方法，可以改变这种默认的加载顺序，从而破坏双亲委派机制。

比如，可以先尝试从自己指定的路径去加载类，如果找不到再调用父类的loadClass方法。
线程上下文类加载器：当 JVM 需要加载类且当前类加载器无法完成时，会尝试使用线程上下文类加载器，从而绕过双亲委派机制从特定类加载器加载类。

线程上下文类加载器

在双亲委托模型下，类的加载是由下至上的，即下层的类加载器会委托上层进行加载。

但对于SPI来说，有些接口是Java核心库所提供的，而Java核心库是由启动类加载器来加载的，而这些接口的实现却来自不同的Jar包（厂商提供JDBC的实现有Oracle，MySQL等), Java的启动类加载器不会加载其他来源的jar包，这样传统的双亲委托模型就无法满足SPI的要求。而通过给当前线程设置上下文类加载器，就可以由设置的上下文类加载器来实现对于接口实现类的加载。

SPI（Service Provider Interface）即服务提供者接口。

SPI 是一种用于实现框架扩展和插件化的机制。它定义了一组接口，允许第三方为这些接口提供具体的实现。
例如，Java 的数据库连接（JDBC）就是一个典型的 SPI 应用。JDBC 定义了一组用于与数据库进行交互的接口，而不同的数据库厂商提供了各自的实现。

查看全文

http://www.kler.cn/a/311565.html