Java JVM——2.类加载器子系统

时间 2020-12-17

标签 java bootstrap 数组安全网络数据结构多线程工具 spa 栏目 Java 繁體版

原文原文链接

概述

类加载器子系统在Java JVM中的位置

类加载器子系统的具体实现

类加载器子系统的做用

　　① 负责从文件系统或者网络中加载.class文件，Class 文件在文件开头有特定的文件标识。java

　　② ClassLoader只负责Class 文件的加载，至于它是否能够运行，则由Execution Engine决定。bootstrap

　　③ Class 文件加载到JVM中，被称为DNA元数据模板，存放在方法区。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）。数组

　　④ 从Class文件-->JVM-->最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。安全

JVM 的类加载机制

类加载过程

　　JVM 的类加载分为 5 个阶段：加载、验证、准备、解析、初始化。在类初始化完成后就可使用该类的信息了，当这个类再也不被须要时能够从 JVM 中卸载。网络

类加载过程数据结构

加载阶段

　　JVM 读取 Class 文件，经过一个类的全限定名获取定义此类的二进制字节流，将这个字节流所表明的静态存储结构转化为方法区的运行时数据结构。多线程

　　根据 Class 文件的描述在堆中建立一个表明这个类的 java.lang.Class对象，做为方法区这个类的各类数据的访问入口。工具

　　在读取 Class 文件时既能够经过文件的形式读取，也能够经过 jar 包、war 包读取，还能够经过代理自动生成 Class或其余方式读取。ui

验证阶段

　　主要用于确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，保证被加载类的正确性，进一步保障虚拟机自身的安全，只有经过验证的 Class 文件才能被 JVM 加载。spa

　　主要包括四种验证：文件格式验证，元数据验证，字节码验证，符号引用验证。

准备阶段

　　主要工做是在方法区中为类变量分配内存空间并设置类中变量的初始值。初始值指不一样数据类型的默认值，这里须要注意 final 类型的变量和非 final 类型的变量在准备阶段的数据初始化过程不一样。好比一个成员变量的定义以下：

public static int value = 1500;

　　在上述代码中，静态变量 value 在准备阶段的初始值是 0，将 value 设置为 1500 的动做是在对象初始化时完成的，由于 JVM 在编译阶段会将静态变量的初始化操做定义在构造器中。可是，若是将变量 value 声明为 final 类型：

public static final int value = 1500;

　　则 JVM 在编译阶段后会为 final 类型的变量 value 生成其对应的 ConstantValue 属性，虚拟机在准备阶段会根据 ConstantValue 属性将 value 赋值为 1500。

解析阶段

　　JVM 将常量池内的符号引用转换为直接引用的过程。事实上，解析操做每每会伴随着JVM在执行完初始化以后再执行。

　　符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明肯定义在《java虚拟机规范》的class文件格式中。

　　直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

　　解析动做主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等。

初始化阶段

　　主要经过执行类构造器的<clinit>方法为类进行初始化。<clinit>方法是在编译阶段由编译器自动收集类中静态语句块和变量的赋值操做组成的。在准备阶段，类中静态成员变量已经完成了默认初始化，而在初始化阶段，<clinit>方法将对静态成员变量进行显示初始化。

注意：

　　1. JVM 规定，只有在父类的<clinit>方法都执行成功后，子类中的<clinit>方法才能够被执行。所以，JVM中第一个被执行<clinit>方法的类确定是java.lang.Object。

　　2. 在一个类中既没有静态变量赋值操做也没有静态语句块时，编译器不会为该类生成<clinit>方法。

　　3. 静态代码块只能访问到出如今静态代码块以前的变量,定义在它以后的变量,在前面的静态语句块能够赋值,可是不能访问。

　　4. 接口也须要经过<clinit>方法为接口中定义的静态成员变量显示初始化。

　　5. 接口中不能使用静态代码块,但仍然有变量初始化的赋值操做,由于接口与类同样都会生成<clinit>方法。不一样的是,执行接口的<clinit>方法不须要先执行父接口的<clinit>方法，只有当父接口中的静态成员变量被使用到时才会执行父接口的<clinit>方法。

　　6. 虚拟机会保证在多线程环境中一个类的<clinit>方法被正确地加锁同步。当多条线程同时去初始化一个类时，只会有一个线程去执行该类的<clinit>方法,其它线程都被阻塞等待,直到活动线程执行<clinit>方法完毕。其它线程被唤醒后不会再进入<clinit>方法，同一个类加载器下,一个类型只会初始化一次。

在发生如下几种状况时，JVM 不会执行类的初始化流程：

★ 常量在编译时会将其常量值存入使用该常量的类的常量池中，该过程不须要调用常量所在的类，所以不会触发该常量类的初始化。

★ 在子类引用父类的静态字段时，不会触发子类的初始化，只会触发父类的初始化。

★ 定义对象数组，不会触发该类的初始化。

★ 在使用类名获取 Class 对象时不会触发类的初始化。

★ 在使用 Class.forName 加载指定的类时，能够经过 initialize 参数设置是否须要对类进行初始化。

★ 在使用 ClassLoader 默认的 loadClass 方法加载类时不会触发该类的初始化。

类加载器

　　JVM 提供了 3 种类加载器，分别是启动类加载器、扩展类加载器和应用程序类加载器，还有一种是用户自定义类加载器。

如图所示：

JVM 类加载器

① 启动类加载器：

这个类加载使用C/C++语言实现的，嵌套在JVM内部。

它用来加载Java的核心库（JAVAHOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身须要的类。

并不继承自ava.lang.ClassLoader，没有父加载器。

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

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

② 扩展类加载器：

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

派生于ClassLoader类。

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

从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/1ib/ext子目录（扩展目录）下加载类库。若是用户建立的JAR放在此目录下，也会自动由扩展类加载器加载。

③ 应用程序类加载器（系统类加载器）：

java语言编写，由sun.misc.LaunchersAppClassLoader实现。

派生于ClassLoader类。

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

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

该类加载是程序中默认的类加载器，通常来讲，Java应用的类都是由它来完成加载。

经过classLoader#getSystemclassLoader() 方法能够获取到该类加载器。

④ 自定义的类加载器：

　　在Java的平常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，但在必要时，咱们还须要自定义类加载器，来定制类的加载方式。咱们能够经过继承 java.lang.ClassLoader 实现自定义的类加载器。

为何要自定义类加载器？

✔ 隔离加载类

✔ 修改类加载的方式

✔ 扩展加载源

✔ 防止源码泄漏

两种类加载器获取的差别：

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

　　规定全部派生于抽象类 ClassLoader的类加载器都被划分为自定义类加载器，ClassLoader是一个抽象类，其后全部的类加载器都继承自ClassLoader（不包括启动类加载器），因此启动类加载器为一类，其他的类加载器为另外一类。

咱们看一段代码，获取它们的类加载器：

public class ClassLoaderTest { public static void main(String[] args) { // 1.获取：系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader(); System.out.println(systemClassLoader); // 2.获取其上层的：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent(); System.out.println(extClassLoader); // 3.试图获取：根加载器（启动类加载器）
        ClassLoader bootstrapClassLoader = extClassLoader.getParent(); System.out.println(bootstrapClassLoader); // 4.获取：自定义加载器
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader(); System.out.println(classLoader); // 5.获取：String类型的加载器
        ClassLoader classLoader1 = String.class.getClassLoader(); System.out.println(classLoader1); } }

运行结果：

　　咱们能够看到，目前用户代码所使用的加载器为系统类加载器，其上是扩展类加载器，两者是同属一类加载，均可以用代码直接获取。可是，根加载器（启动类加载器）没法直接经过代码获取。同时，咱们经过获取String类型的加载器，发现是null，那么说明String类型是经过根加载器进行加载的，也就是说Java的核心类库都是使用根加载器进行加载的。

双亲委派机制

工做原理

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

　　双亲委派机制指一个类在收到类加载请求后不会尝试本身加载这个类，而是把该类加载请求向上委派给其父类去完成，其父类在接收到该类加载请求后又会将其委派给本身的父类，以此类推，这样全部的类加载请求都被向上委派到启动类加载器中。若父类加载器在接收到类加载请求后发现本身也没法加载该类（一般缘由是该类的 Class 文件在父类的类加载路径中不存在），则父类会将该信息反馈给子类并向下委派子类加载器加载该类，直到该类被成功加载，若找不到该类，则 JVM 会抛出 ClassNotFoud 异常。

双亲委派过程

沙箱安全机制

　　自定义String类，但在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程当中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main方法，就是由于加载的是rt.jar包中的string类，并非自定义的String类。这样能够保证对java核心源代码的保护，这就是沙箱安全机制。

双亲委派机制的优势

★ 避免类的重复加载

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

☆ 自定义类：java.lang.String（报错：阻止建立 java.lang开头的类）

☆ 自定义类：java.lang.ShkStart（报错：阻止建立 java.lang开头的类）

如何判断两个Class对象是否相等

在JVM中表示两个class对象是否为同一个类存在两个必要条件：

☛ 类的完整类名必须一致，包括包名。

☛ 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同。

　　换句话说，在JVM中，即便两个类对象（Class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不一样，那么这两个类对象就是不相等的。

　　JVM必须知道一个类是由启动加载器加载的仍是由用户类加载器加载的。若是一个类是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用做为类型信息的一部分保存在方法区中，当解析一个类到另外一个类的引用时，JVM须要保证这两个类的类加载器是相同的。

类的主动使用和被动使用

　　Java程序对类的使用方式分为：主动使用和被动使用。

主动使用，有七种状况：

建立类的实例
访问某个类或接口的静态变量，或者对该静态变量赋值
调用类的静态方法
反射（好比：Class.forName（"com.atguigu.Test"））
初始化一个类的子类
Java虚拟机启动时被标明为启动类的类
JDK7开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化

除了以上七种状况，其余使用Java类的方式都被看做是对类的被动使用，都不会致使类的初始化。