【Java虚拟机系列】- Java虚拟机类加载机制_java虚拟机加载类-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_68383079/article/details/145742706

【JVM系列】- Java虚拟机类加载机制

本章：虚拟机如何加载这些Class，字节码中的信息进入到虚拟机后会发生什么变化

本章说的类既包括类又包括接口

一、类加载机制

JVM的类加载机制指：Java虚拟机把Class文件加载到内存并对其中数据进行校验、解析和初始化，最终形成可被虚拟机直接使用的Java类型数据
Java语言中类型的加载、连接与初始化都是在程序运行期间完成的，故会增加类加载时的性能开销，但是为Java应用提供了高可扩展性和灵活性
Java天生的动态拓展特性就是依赖运行期动态加载和动态连接来实现的，如：
- 编写的面向接口的应用程序等运行时再指定其实现类
- 通过Java预置或自定义类加载器，让本地应用程序运行时从网络获取二进制流作为其代码的一部分

二、类的生命周期

类的整个生命周期将会经历加载、验证、准备、解析、初始化、使用和卸载七个阶段

其中验证、准备、解析三个部分统称为连接

在这里插入图片描述

解析的顺序不一定，也可在初始化之后(Java语言的动态绑定或晚期绑定)
这些阶段的实际执行过程并非严格线性的，而是可能相互交错混合进行，因实际执行过程中，它们可能会被分割或并行进行，一个阶段在执行过程中会调用激活另一阶段的执行，但是每个阶段的开始是严格按照顺序的

三、初始化的时机

对于类加载的时机，由虚拟机自行确定
对于初始化的时机《JVM规范》有统一规定：
- 有且只有6种情况会触发初始化，是对类型的主动引用：
  - 执行到new、getstatic、putstatic或invokestatic字节码指令时，如果类型没有进行过初始化，则需先初始化（如：用new实例化对象、调用静态方法、读取或设置静态字段时）
  - 用java.lang.reflect包的方法对类型进行反射调用，需先对类型初始化
  - 初始化子类时，需先初始化父类
  - 虚拟机启动时，主类（含main()方法那个类）会先初始化
  - 接口中定义了default默认方法时，该接口要在其实现类初始化之前初始化
  - 当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，则这个方法句柄对应的类需先初始化
- 引用类型的方式是被动引用，不会触发初始化：
  - 只有直接定义静态字段的类会被初始化，通过子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化
  - 通过数组定义来引用类，不会触发此类的初始化，会初始化一个由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令newarray触发
  - 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，而是对调用类的常量池的引用，因此不会触发定义常量的类的初始化
接⼝与类初始化的唯一不同：子接⼝在初始化时，并不要求其⽗接⼝全部都完成了初始化，只有在真正使⽤到⽗接⼝的时候(如引⽤接⼝中定义的常量)才会初始化；接口不能用static，但编译器会为接口生成<clinit>()类构造器，用于初始化接口中定义的成员变量

四、类加载具体过程

1. 加载

加载Loading是Class Loading的一部分
Loading过程：JVM➀从类的全限定名找定义类的⼆进制字节流，➁将字节流代表的静态存储结构转化成⽅法区的运⾏时数据结构，➂生成代表类的对象作为类的访问⼊⼝
- ➁获取定义类的二进制字节流的方式有多种：从ZIP压缩包中读取、网络获取、运行时生成、其他文件生成、从数据库读取、从加密文件获取
  - 非数组类的加载：既可由JVM内置的引导类加载器，也可由用户⾃定义类加载器完成，开发⼈员通过定义自己的类加载器去控制字节流的获取方式(重写⼀个类加载器的findClass()或loadClass()⽅法)
  - 数组类的加载：数组类本身不通过类加载器创建，由JVM直接在内存中动态构造出来，但数组类的元素类型仍由类加载器加载
    - 如果数组的组件类型(去一维后剩下的)是引⽤类型，那就递归采⽤本节中加载过程加载，数组将被标识在加载该组件类型的类加载器的类名称空间上
    - 如果组件类型不是引⽤类型，JVM将会把数组标记为与引导类加载器关联
    - 数组类的可访问性与其组件类型的可访问性⼀致，如果组件类型不是引⽤类型，它的数组类的可访问性默认为public，可被所有的类和接⼝访问到
- ➂类或接口数据安置在方法区后，会在Java堆内存中实例化一个java.lang.Class类的对象，作为程序访问方法区中的类型数据的外部接口
方法区中的数据存储格式由虚拟机自行定义
补充：加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）交叉进行，加载阶段尚未完成，连接阶段可能已经开始，这两个阶段的开始时间先后顺序固定

2. 验证

验证为确保Class文件的字节流中信息符合规范，保证不会危害JVM安全，虽然问题代码Java编译器会抛出异常而不编译，但JVM需要的Class文件不一定编译来也可手敲，故JVM需对其检查

2.1. 文件格式验证

验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理
主要目的是保证输入的字节流能正确解析，格式上符合要求，这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证，这段字节流才被允许存到JVM内存的方法区

后面的三个验证阶段全基于方法区的存储结构进行，不会再直接读取、操作字节流

2.2. 元数据验证

对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要求

2.3. 字节码验证

整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的
对类的方法体（Class文件中的Code属性）进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为，如果⼀个⽅法体通过了字节码验证，也仍然不能保证它⼀定就是安全的
通过程序去校验程序逻辑是⽆法做到绝对准确的，不可能⽤程序来准确判定⼀段程序是否存在Bug（停机问题Halting Problem：不能通过程序准确地检查出程序是否能在有限的时间之内结束运行）

2.4. 符号引用验证

符号引用验证发生在JVM将符号引用转化为直接引用时，这个转化在连接的解析阶段发生，符号引用验证主要⽬的是确保解析行为能正常执行
符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源

3. 准备

准备阶段是正式为类中定义的变量(即静态变量，被static修饰的变量)分配内存并设置类变量初始值的阶段
注意！！这个阶段只为类变量分配空间，实例变量不分配，准备阶段之后变量初始值是数据类型的零值，在初始化阶段才会按代码赋值，但被final修饰的话会直接被初始化为指定的初始值

在这里插入图片描述

4. 解析

解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程

符号引用和直接引用：
- 符号引用：符号引用以一组符号来描述所引用的目标，该目标不一定是已加载到虚拟机内存当中的内容，符号引用与虚拟机实现的内存布局无关
- 直接引用：直接引用是可直接指向目标的指针、相对偏移量或能间接定位目标的句柄，直接引用与虚拟机实现的内存布局直接相关，有直接引用则引用目标必定在虚拟机内存中存在
虚拟机可以自行决定是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到⼀个符号引用将被使用前再去解析
对方法和字段的访问也会在解析阶段检查它们的可访问性
同⼀个符号引⽤的多次解析⾮常常⻅，除了invokedynamic指令外，虚拟机可以对第⼀次解析的结果进行缓存，在运行时直接引用常量池中的记录，并把常量标识为已解析状态，从而避免重复解析
- jvm需要保证对同⼀个实体多次解析结果的⼀致性
- 对于invokedynamic指令，这个指令的⽬的是⽤于动态语⾔⽀持，它对应的引⽤称为“动态调⽤点限定符”，这⾥“动态”的含义是指必须等到程序实际运⾏到这条指令时，解析动作才能进⾏
- 解析动作主要针对类或接⼝、字段、类⽅法、接⼝⽅法、⽅法类型、⽅法句柄和调⽤点限定符这7类符号引⽤进⾏

5. 初始化

初始化阶段开始JVM才真正开始执行类中编写的Java程序代码，根据程序代码初始化类变量和其他资源，之前阶段除了加载阶段用户应用程序可以自定义类加载器局部参与，其他的都由JVM主导完成

初始化阶段就是执行类构造器()方法的过程，()并不是程序员在Java代码中直接编写的方法，而是Javac编译器的自动生成物

()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器按语句在源文件中顺序收集，静态语句块中只能访问定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问
()方法与类的构造函数（即在虚拟机视角中的实例构造器()方法）不同，它不需要显式地调用父类构造器，Java虚拟机会保证在子类的()方法执行前，父类的()方法已经执行完毕，因此在Java虚拟机中第一个被执行的()方法的类型肯定是java.lang.Object
由于父类的()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值
()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成()方法
接口与类不同的是，执行接口的()方法不需要先执行父接口的()方法，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也一样不会执行接口的()方法
Java虚拟机必须保证一个类的()方法在多线程环境中被正确地加锁同步，如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行完毕()方法。如果在一个类的()方法中有耗时很长的操作，那就可能造成多个进程阻塞
同一个类加载器下，一个类或接口只会被初始化一次

五、类加载器

1. 概述

类加载器Class Loader：实现类的加载动作，该部分代码实现通过一个类的全限定名来获取描述该类的二进制字节流，在Java虚拟机外部实现

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

2. 双亲委派模型

站在JVM的角度来看，只存在两种不同的类加载器：一种是启动类加载器，由使用C++实现，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，由Java语言实现，独立存在于虚拟机外部，都继承自抽象类java.lang.ClassLoade

三层类加载器：
- 启动类加载器（Bootstrap Class Loader）：
  - 加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的类库
  - 负责加载 Java 核心类库（如 java.lang、java.util 等）
  - 启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，直接使用null代替即可
- 扩展类加载器（Extension Class Loader）：
  - Java系统类库的扩展机制
  - 负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库
- 应用程序类加载器（Application Class Loader）/系统类加载器：
  - 负责加载用户类路径/应用程序路径（ClassPath）上所有的类库
  - 如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

在这里插入图片描述

双亲委派模型：
- 各种类加载器之间的层次关系被称为类加载器的“双亲委派模型
- 双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器
- 这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现，而通常使用组合（Composition）关系来复用父加载器的代码
- 双亲委派模型的工作过程：类加载器收到类加载的请求后，会把这个请求委派给父类加载器去完成，所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载
- 很好地解决了各个类加载器协作时基础类型的⼀致性问题（越基础的类由越上层的加载器进行加载），Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系（如Object类在程序的各种类加载器环境中都能够保证是同一个类，因都是启动类加载器加载）
双亲委派机制的好处：
- 类的唯一性：通过这种机制，Java 保证了核心类库（例如 java.lang.*）不会被多次加载，不管是由哪个类加载器加载的类，只要是核心类库中的类，都由 Bootstrap ClassLoader 加载，从而避免同一个类在不同加载器之间重复加载的问题
- 安全性：通过优先让上层类加载器进行加载，可以避免子加载器加载到不可信的类，确保了系统类的优先级。在没有双亲委派机制的情况下，如果每个类加载器都直接加载它所需要的类，可能会出现“类覆盖”的问题。防止类的覆盖和污染，例如，一个自定义类加载器加载了一个自定义的 java.lang.String 类，如果没有双亲委派机制的约束，那么该自定义的 String 类可能会覆盖 JVM 核心的 String 类，导致不可预测的行为

3. 破坏双亲委派模型

双亲委派模型并不是强制性约束条件，而是一种推荐的类加载器实现方式；直到Java模块化出现，双亲委派模型出现过3次较大规模“被破坏”情况：

第⼀次破坏：类加载器早于双亲委派模型被引入，为兼容，设计者们在java.lang.ClassLoader中添加⼀个新的protected⽅法findClass()，并引导用户编写类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码
第⼆次破坏：为了解决基础类型调⽤回⽤户代码的情况（JNDI服务），引入线程上下文类加载器Thread Context ClassLoader
- 这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器
- JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情
- Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JBI等
第三次破坏：由于用户对程序动态性的追求而导致，如代码热替换、模块热部署
- OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块Bundle都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换
- 在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，OSGi将按照特定顺序进行类搜索

六、Java模块化系统

1. 概述

模块化的关键目标——可配置的封装隔离机制

模块将代码分解为更小、更独立的部分。这种方式引入了更严格的访问控制和依赖管理，可以提高代码的可维护性和可重用性。模块系统在Java 9中引入，称为Java Platform Module System (JPMS)，也被称为Project Jigsaw

模块的定义：一个Java模块是一组相关的包和资源的集合。每个模块都有一个模块描述符文件 module-info.java
模块描述符 (module-info.java)：位于模块的根目录中，描述了模块的主要信息：
- 模块的名称 (module <module-name>)
- 该模块依赖的其他模块 (requires)
- 该模块导出的包 (exports)
- 开放的包，即其他模块可反射访问模块的列表
- 提供的服务列表和使用的服务列表 (provides 和 uses)
Java虚拟机对类加载架构也做出了相应的变动调整，才使模块化系统得以顺利地运作
可配置的封装隔离机制解决了JDK 9之前基于类路径ClassPath来查找依赖的可靠性问题
- 启用模块化进行封装，模块就可以声明对其他模块的显式依赖，这样Java虚拟机就能够在启动时验证应用程序开发阶段设定好的依赖关系是否完备，有缺失直接启动失败，避免了由于类型依赖而引发的运行时异常
可配置的封装隔离机制还解决了原来类路径上跨JAR文件的public类型的可访问性问题
- 模块提供了更精细的可访问性控制，必须明确声明其中哪一些public的类型可以被其他哪一些模块访问

2. 模块的兼容性

JDK 9及以后的Java版本使用模块来封装Java SE的标准类库

某个类库是模块还是JAR包，只取决于它在哪种路径上
- 只要是放在类路径上的JAR文件，无论其中是否包含模块化信息（是否包含了module-info.class文件），它都会被当作传统的JAR包来对待
- 只要放在模块路径上的JAR文件，即使没有使用JMOD后缀，甚至说其中并不包含module-info.class文件，它也仍然会被当作一个模块来对待
保证使用传统类路径依赖的Java程序在模块化系统上兼容(向后兼容性)的规则：
- JAR文件在类路径的访问规则：所有类路径下的JAR文件及其他资源文件，都被视为自动打包在一个匿名模块（Unnamed Module）里，这个匿名模块几乎没有任何隔离，可以看到和使用类路径上所有的包、JDK系统模块中所有的导出包，以及模块路径上所有模块中导出的包
- 模块在模块路径的访问规则：模块路径下的具名模块（Named Module）只能访问到它依赖定义中列明依赖的模块和包，匿名模块里所有的内容对具名模块来说都是不可见的，即具名模块看不见传统JAR包的内容
- JAR文件在模块路径的访问规则：如果把一个传统的、不包含模块定义的JAR文件放置到模块路径中，它就会变成一个自动模块（Automatic Module）。尽管不包含module-info.class，但自动模块将默认依赖于整个模块路径中的所有模块，因此可以访问到所有模块导出的包，自动模块也默认导出自己所有的包

3. 模块化下的类加载器

为了兼容模块化，类加载器做了如下变动：

是扩展类加载器（Extension Class Loader）被平台类加载器（Platform Class Loader）取代
平台类加载器和应用程序类加载器都不再派生自java.net.URLClassLoader，现在启动类加载器、平台类加载器、应⽤程序类加载器全都继承于jdk.internal.loader.BuiltinClassLoader

在这里插入图片描述