Java类加载机制、类加载器

最新推荐文章于 2022-05-02 12:40:40 发布

chaoqun_cn

最新推荐文章于 2022-05-02 12:40:40 发布

阅读量125

点赞数

本文链接：https://blog.csdn.net/qq_38777579/article/details/114260935

版权

关于Java 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Java类加载机制、类加载器

从图说起
类加载机制及流程
类的初始化时机
类加载器
双亲委派模型
ClassLoader和它的子类
双亲委派模型的破坏者-线程上下文类加载器
自定义类加载器

从图说起

这是Java代码执行流程图，从源码到字节码过程由编译器完成，而将字节码（二进制类定义信息）放入JVM运行时数据区需要类装载子系统来完成

类加载机制及流程

JVM将描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的加载机制。
类的生命周期包括：加载、链接（验证、准备、解析）、初始化、使用和卸载，其中加载、链接、初始化，属于类装载的过程。

加载（Loading）：将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构，作为方法区这些数据的访问入口。
验证（Verify）：为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个阶段的验证：
- 1）文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。
- 2）元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
- 3）字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
- 4）符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。
准备（Prepare）：为类中的静态字段分配内存，并设置默认的初始值（数据类型默认的零值，如：0、0L、null、false等）。被final修饰的static字段不会设置，因为final在编译的时候就分配了。注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。
解析（Resolve）：主要将常量池中的符号引用替换为直接引用的过程。符号引用就是一组符号来描述目标，可以是任何字面量；而直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
初始化（Initialization）：执行类的构造器方法init() 【由javac编译器自动收集类中所有类变量的赋值动作和静态代码块中的语句合并来的】若该类具有父类，jvm会保证父类的init先执行，然后在执行子类的init。
由Java虚拟机自带的类加载器所加载的类，在虚拟机的生命周期中，始终不会被卸载。因为Java虚拟机本身会始终引用这些类加载器，而这些类加载器则会始终引用它们所加载的类的Class对象，因此这些Class对象始终是可触及的。由用户自定义的类加载器加载的类是可以被卸载的。
在以下情况的时候，Java虚拟机会结束生命周期： 1). 执行了System.exit()方法 2). 程序正常执行结束 3). 程序在执行过程中遇到了异常或错误而异常终止 4). 由于操作系统出现错误而导致Java虚拟机进程终止。

类的初始化时机

什么情况下需要开始类装载过程的第一个阶段:“加载”。虚拟机规范中并没强行约束，这点可以交给虚拟机的的具体实现自由把握，但是对于初始化阶段虚拟机规范是严格规定了如下几种情况：

创建类的实例
访问类的静态变量(除常量【被final修辞的静态变量】因为编译器把他们当作值(value)而不是域(field)来对待）
访问类的静态方法
反射如(Class.forName(“xxx”))
当初始化一个类时，发现其父类还未初始化，则触发父类的初始化
虚拟机启动时，main()方法所在类先初始化
以上情况称为称对一个类进行“主动引用”，会触发该类的初始化，常见不会触发初始化的“被动引用”有：1，子类调用父类的静态变量，子类不会被初始化；2，通过数组定义来引用类，不会触发类的初始化；3，访问类的常量，不会初始化类

class SuperClass {
    static {
        System.out.println("superclass init");
    }
    public static int value = 123;
}

class SubClass extends SuperClass {
    public final static int CONST_V = 0;
    static {
        System.out.println("subclass init");
    }
}

public class Main {
    public static void main(String[] args) throws IOException {
        System.out.println(SubClass.value); // 被动引用1
        SubClass[] sa = new SubClass[10];   // 被动引用2
        System.out.println(SubClass.CONST_V);  // 被动引用3
    }
}

类加载器

基本上所有的类加载器都是 java.lang.ClassLoader 类的一个实例。基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即 java.lang.Class 类的一个实例。除此之外， ClassLoader 还负责加载 Java 应用所需的资源，如图像文件和配置文件等。

Java 中的类加载器大致可以分成两类，一类是系统提供的，另外一类则是由 Java 应用开发人员编写的。系统提供的类加载器主要有下面三个：

启动（Bootstrap）类加载器：使用C++语言实现的，是虚拟机自身的一部分，它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中

参数	效果
-Xbootclasspath:	完全取代核心的Java class 搜索路径。不常用，否则要重新写所有Java 核心class
-Xbootclasspath/p:	在核心class搜索路径前面。也就是优先搜索参数指定路径。不常用，避免引起不必要的冲突
- Xbootclasspath/a:	后缀在核心class搜索路径后面。也就是其他路径都搜完了，再搜索参数指定路径，常用

扩展（Extension）类加载器：扩展类加载器是指Sun公司(已被Oracle收购)实现的sun.misc.Launcher$ExtClassLoader类，它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定路径下的类库。
系统（System）类加载器：也称应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。它负责加载系统类路径java -classpath或-D java.class.path指定路径下的类库，也就是我们经常用到的classpath路径，一般情况下该类加载是程序中默认的类加载器，通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。

双亲委派模型

该模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。子类加载器和父类加载器不是以继承（Inheritance）的关系来实现，而是通过组合（Composition）关系来复用父加载器的代码。
双亲委派模型
工作流程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，逐层向上传递，所有的类加载请求都会传给顶层的启动类加载器，只有当父加载器反馈自己无法完成该加载请求（该加载器的搜索范围中没有找到对应的类）时，子加载器才会尝试自己去加载。有种啃老的感觉😜

双亲委派模型优势：

避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次
有效防止核心API库被随意篡改，比如：自定义 String 类，但是AppClassLoader在加载自定义 String 类的时会逐级委派，使用引导类加载器加载，而引导类加载器在加载的过程中会先加载 JDK 自带的文件（rt.jar 包中的 javalangString.class），这样做是不允许，因为java.lang是核心API包，需要访问权限，强制加载将会报出如下异常：

Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang

ClassLoader和它的子类

ClassLoaderj继承图
ClassLoader 中与加载类相关的方法：

方法	说明
getParent()	返回该类加载器的父类加载器。
loadClass(String name, boolean resolve)	加载名称为 name 的类，返回的结果是 java.lang.Class 类的实例，双亲委派模式逻辑实现。
findClass(String name)	查找名称为 name 的类，返回的结果是 java.lang.Class 类的实例。
findLoadedClass(String name)	查找名称为 name 的已经被加载过的类，返回的结果是 java.lang.Class 类的实例。
defineClass(String name, byte[] b, int off, int len)	把字节数组 b 中的内容转换成 Java 类，返回的结果是 java.lang.Class 类的实例。
resolveClass(Class<?> c)	链接指定的 Java 类。

注意：

表示类名称的 name 参数的值是类的二进制名称。需要注意的是内部类的表示，如 com.example.Sample$Inner 表示方式
自定义的类加载逻辑写在findClass() 方法中

protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }

在JVM中，即使这个两个类对象(class对象)来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的，这是因为不同的ClassLoader实例对象都拥有不同的独立的类名称空间，所以加载的class对象也会存在不同的类名空间中

双亲委派模型的破坏者-线程上下文类加载器

在Java应用中存在着很多服务提供者接口（Service Provider Interface，SPI），这些接口允许第三方为它们提供实现，如常见的 SPI 有 JDBC、JNDI等，这些 SPI 的接口属于 Java 核心库，一般存在rt.jar包中，由Bootstrap类加载器加载。而Bootstrap类加载器无法直接加载SPI的实现类，同时由于双亲委派模式的存在，Bootstrap类加载器也无法反向委托AppClassLoader加载器SPI的实现类。在这种情况下，我们就需要一种特殊的类加载器来加载第三方的类库，而线程上下文类加载器（双亲委派模型的破坏者）就是很好的选择。

自定义类加载器

实现自定义类加载器需要继承ClassLoader或者URLClassLoader，继承ClassLoader则需要自己重写findClass()方法并编写加载逻辑，继承URLClassLoader则可以省去编写findClass()方法以及class文件加载转换成字节码流的代码。那么编写自定义类加载器的意义何在呢？

当class文件不在ClassPath路径下，默认系统类加载器无法找到该class文件，在这种情况下我们需要实现一个自定义的ClassLoader来加载特定路径下的class文件生成class对象。
当一个class文件是通过网络传输并且可能会进行相应的加密操作时，需要先对class文件进行相应的解密后再加载到JVM内存中，这种情况下也需要编写自定义的ClassLoader并实现相应的逻辑。
当需要实现热部署功能时(一个class文件通过不同的类加载器产生不同class对象从而实现热部署功能)，需要实现自定义ClassLoader的逻辑。

chaoqun_cn

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Java类加载机制、类加载器

Java类加载机制、类加载器从图说起类加载机制及流程类的初始化时机类加载器双亲委派模型ClassLoader和它的子类双亲委派模型的破坏者-线程上下文类加载器自定义类加载器从图说起这是Java代码执行流程图，从源码到字节码过程由编译器完成，而将字节码（二进制类定义信息）放入JVM运行时数据区需要类装载子系统来完成类加载机制及流程JVM将描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的加载机制。类的生命周期包括
复制链接

扫一扫

专栏目录