JVM之类加载器、加载过程及双亲委派机制

JVM之类加载器、加载过程及双亲委派机制

Java 虚拟机的启动是通过引导类加载器（bootstrap class loader）创建一个初始类（initial class）来完成的，这个类是由虚拟机的具体实现指定的。

1|2虚拟机的执行

一个运行中的 Java 虚拟机有着一个清晰的任务：执行 Java 程序。

程序开始执行时他才运行，程序结束时他就停止。

执行一个所谓的 Java 程序的时候，真真正正在执行的是一个叫做 Java 虚拟机的进程。

1|3虚拟机的退出

有如下的几种情况：

程序正常执行结束

程序在执行过程中遇到了异常或错误而异常终止

由于操作系统出现错误而导致 Java 虛拟机进程终止

某线程调用 Runtime 类或 System 类的 exit 方法，或 Runtime 类的 halt 方法，并且 Java 安全管理器也允许这次 exit 或 halt 操作。

除此之外，JNI ( Java Native Interface) 规范描述了用 JNI Invocation API 来加载或卸载 Java 虛拟机时，Java虛拟机的退出情况。

2|0类加载器子系统的作用

类加载器子系统负责从文件系统或者网络中加载 class 文件，class文件的开头有特定的文件标识（CA FE BA BE）

ClassLoader 只负责 class 文件的加载，至于它是否可以运行，则由 Execution Engine 决定

加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是 class 文件中常量池部分的内存映射）

3|0类加载器 ClassLoader 的作用

.class 文件 → JVM → 最终成为元数据模板，在这一过程中，ClassLoader 充当了运输工具，扮演了一个快递员的角色

4|0类的加载过程

4|1加载（Loading）

1、通过一个类的全限定类名获取定义此类的二进制字节流

2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

3、在内存中生成一个代表这个类的java.lang.Class对象，作为方法区里这个类的各种数据的访问入口

4|2链接（Linking）

验证

确保 class 文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全

包括四种验证方式：文件格式验证、元数据验证、字节码验证、符号引用验证

准备

为类变量分配内存并且设置该类变量的默认初始值，即零值。

这里不包含用 final 修饰的静态常量 ,因为 final 在编译的时候就会分配了，准备阶段会显式初始化

这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java 堆中。

解析

将常量池内的符号引用转换为直接引用的过程。

事实上，解析操作往往会伴随着 JVM 在执行完初始化之后再执行。

符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机

规范》的 Class 文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位

到目标的句柄。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT Methodref_info等。

4|3初始化（Initialization）

初始化阶段就是执行类构造器方法 () 的过程。

此方法不需定义，是 javac 编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。

构造器方法中指令按语句在源文件中出现的顺序执行。

() 不同于类的构造器。(关联: 构造器是虚拟机视角下的 () )

若该类具有父类，JVM 会保证子类的 () 执行前，父类的 () 已经执行完毕。

虚拟机必须保证一个类的 () 方法在多线程下被同步加锁。

5|0类加载器的分类

JVM 支持两种类型的类加载器：引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。

这里说的自定义类加载器并不是指由开发人员自定义的类加载器，在 Java 虚拟机规范中，将所有派生于抽象类ClassLoader 的所有类加载器都称为自定义类加载器。所以，无论类加载器的类型如何划分，在程序中，我们最常见的类加载器始终只有 3 个，如下图所示：

这四者之间是包含的关系，不是上下层，也不是子父类继承关系

启动类加载器（引导类加载器，Bootstrap ClassLoader）

这个类加载器使用 C/C++ 编写，嵌套在 JVM 内部

它用来加载 Java 核心类库 ( JAVA_HOME/jre/lib/rt.jar、resources.jar、sun.boot.class.path 路径下的内容)，用于提供 Java 自身需要的类

并不继承 ClassLoader，没有父加载器

加载扩展类和应用程序类加载器，并指定为它们的父加载器

出于安全考虑，bootstrap 启动类加载器只加载包名为 java、javax、sun 开头的类

扩展类加载器（Extension ClassLoader）

Java 语言编写，由 sun.misc.Launcher$ExtClassLoader 实现

派生于 ClassLoader 类

父类加载器为启动类加载器

从 java.ext.dirs 系统属性所指定的目录中加载类库，或从 JDK 的安装目录的 jre/lib/ext 子目录(扩展目录)下加载类库。如果用户创建的 JAR 放在此目录下，也会自动由扩展类加载器加载。

应用程序类加载器（系统类加载器，App ClassLoader）

Java 语言编写，由 sun.misc.Launcher$AppClassLoader 实现

父类加载器为扩展类加载器

它负责加载环境变量 classpath 或系统属性 java.class.path 指定路径下的类库

该类加载器是程序中默认的类加载器，一般来说，Java 应用的类都是由它来完成加载

通过 ClassLoader.getSystemClassLoader() 方法可以获取到该类加载器

用户自定义类加载器

在 Java 的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。

6|0获取 ClassLoader 的途径

方式 代码

获取当前类的 ClassLoader clazz.getClassLoader()

获取当前线程上下文的 ClassLoader Thread.currentThread().getContextClassLoader()

获取系统的 ClassLoader ClassLoader.getSystemClassLoader()

获取调用者的 ClassLoader DriverManager.getCallerClassLoader()

7|0双亲委派机制

Java 虚拟机对 class 文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成 class 对象。而且加载某个类的 class 文件时，Java 虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式。

7|1工作原理

1、如果一个类加载器收到类加载请求，它不会自己先加载，而是委托给父类的加载器去执行

2、如果父类加载器还存在父类加载器，则进一步委托，直到到达最顶层的类加载器

3、如果父类加载器可以完成类的加载任务，就成功返回，如果不能完成再回退到子类加载器判断

7|2作用

1、避免类的重复加载

比如A、B类都需要加载 String 类，如果不用委托而是自己加载自己的，则会在内存中生成两份字节码。

2、保护程序安全，防止核心 API 被随意篡改

比如我们在自定义一个 java.lang.String 类，执行 main 方法的时候会报错，因为 String 是 java.lang 包下的类，应该由启动类加载器加载。

/ 错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为: public static void main(String[] args) 否则 JavaFX 应用程序类必须扩展javafx.application.Application / public class String { public static void main(String[] args) { System.out.println("hello string"); } }

如果在 java.lang 包中定义 Jdk 中不存在的类呢？依然会报错

/ 异常：java.lang.SecurityException: Prohibited package name: java.lang / public class Other { public static void main(String[] args) { System.out.println("hello other"); } }

EOF

本文作者：JLSong

本文链接：

https://www.cnblogs.com/songjilong/p/12834729.html