【JVM】2、类加载器与类的加载过程

JVM架构

JVM架构：
英文版

中文版

类加载子系统

类加载子系统部分如下图：

类加载器子系统作用

• 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识（coffebabe 魔数）。
  字节码文件是物理磁盘上的文件
• ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine（执行引擎）决定。
• 加载的类信息存放于一块称为方法区的内存空间。
  除了类的信息外，方法区中还会存放运行时常量池（常量池在运行的时候加载到内存里就叫做运行时常量池）信息，可能还包括字符串字面量和数字常量。

类加载器扮演的就是搬运工的角色：

• class file存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
• class file加载到JVM中，被称为DNA元数据模板，放在方法区。
• 在.class文件–>JVM–>最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader）
  

类的加载过程

• 类加载过程概述
  • 执行 main() 方法（静态方法）就需要先加载承载类 HelloLoader
  • 加载成功，则进行链接、初始化等操作，完成后调用 HelloLoader 类中的静态方法 main
    加载成功在内存中就会有一个Class对象。
  • 加载失败则抛出异常
    字节码文件如果不是合法的字节码文件，就会在加载的过程中抛出异常。

• 类的加载过程分为以下几个阶段：
  • 加载
  • 链接（Linking）
  • 初始化

加载阶段

加载阶段流程

• 通过一个类的全限定名（全类名）获取定义此类的二进制字节流
• 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
  这个方法区的实现方式在jdk8已经换成了元空间
• 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

加载.class文件的方式

• 从本地系统中直接加载
• 通过网络获取，典型场景：Web Applet
• 从zip压缩包中读取，成为日后jar、war格式的基础
• 运行时计算生成，使用最多的是：动态代理技术
• 由其他文件生成，典型场景：JSP应用从专有数据库中提取.class文件，比较少见
• 从加密文件中获取，典型的防Class文件被反编译的保护措施

链接阶段

链接分为三个子阶段：验证 --> 准备 --> 解析

验证

• 验证
  所有能够被java虚拟机所识别的字节码文件的有效起始都是CAFEBABE(魔数)
  

准备

• 准备

  • 为类变量（static修饰的变量）分配内存并且设置该类变量的默认初始值，即零值
    下面这个a在现在的prepare阶段它的值是0

  • final修饰的static即常量不会在这个阶段被设置，因为final在编译的时候就会分配好了默认值，准备阶段会显式初始化
    常量在编译的时候就确定了会存一个值，所以在prepare阶段就直接把这个值赋了

  • 这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中
    因为这里还没有开始造对象，到具体方法造对象的时候才会

解析

• 解析
  解析是将常量池内的符号引用转换为直接引用的过程。事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
  解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等。
  • 符号引用
    我们一个类在加载的过程中会加载非常多的类，加载的这些类不会都装在这个类的字节码文件中，这时候就会用符号引用 引用相关的结构
    符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。
    下图就是常量池的符号引用
    
  • 直接引用
    直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄

初始化阶段

• 初始化

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

  类构造器方法< clinit >()

  • <clinit>()不需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
    也就是代码中没有类变量的赋值动作和静态代码块的话就不会有<clinit>()方法
    例子：

    • 无<clinit>()方法
      没有static 即类变量的赋值动作和静态代码块
      

    • 有 <clinit>()方法
      

    • 类构造器方法中的指令按语句在源文件中出现的顺序执行
      number是先在静态代码块赋值为20，然后后面赋值为10，所以最后的输出结果为10. 这里能先赋值再定义的原因是因为上面linking的prepare阶段已经把number置为0了。
      但是虽然如此还是不能在定义之前调用它，只能赋值。
      

  • 若该类具有父类，JVM会保证子类的/()执行前，父类的/()已经执行完毕
  • 虚拟机必须保证一个类的()方法在多线程下被同步加锁
    一个类往内存中加载的时候只需要加载一次就可以了，加载完就会放到方法区（JDK8在元空间中）。也就是虚拟机执行类的加载的时候，只会调用一次/()方法，保证这个类只加载一次。
    由于一个类只能加载一次，那么当有多个线程的时候，就要加锁，保证只有一个线程能进去。
    代码演示：
    我们的两个线程都要去new DeadThread()，而DeadThread类只能被加载一次
    具体：

    • 两个线程同时去加载 DeadThread 类，而 DeadThread 类中静态代码块中有一处死循环

    • 先加载 DeadThread 类的线程抢到了同步锁，然后在类的静态代码块中执行死循环，而另一个线程在等待同步锁的释放

    • 所以无论哪个线程先执行 DeadThread 类的加载，另外一个类也不会继续执行

      			 public class DeadThreadTest {
      		    public static void main(String[] args) {
      		        Runnable r = () -> {
      		            System.out.println(Thread.currentThread().getName() + "开始");
      		            DeadThread dead = new DeadThread();
      		            System.out.println(Thread.currentThread().getName() + "结束");
      		        };
      		
      		        Thread t1 = new Thread(r, "线程1");
      		        Thread t2 = new Thread(r, "线程2");
      		
      		        t1.start();
      		        t2.start();
      		    }
      		}
      		
      		class DeadThread {
      		    static {
      		        if (true) {
      		            System.out.println(Thread.currentThread().getName() + "初始化当前类");
      		            while (true) {
      		
      		            }
      		        }
      		    }
      		}
      

      

  类的构造器< init >()

  构造器是虚拟机视角下的<init>()
  

类加载器的分类

在虚拟机的角度上看，只有两种不同的类加载器。一种是c++实现的，另一种是java 实现的，独立于jvm 全部继承java.lang.ClassLoader.
在java开发人员的角度上看，是保持着三层类加载器，双亲委派模型架构。
注意这里是上下级关系，而不是继承关系。

JVM支持两种类型的类加载器（虚拟机的角度） ：

• 引导类加载器（Bootstrap ClassLoader）
• 自定义类加载器（User-Defined ClassLoader）
  所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
  Extension Class Loader（扩展类加载器）和System Class Loader（系统类加载器）都属于自定义类加载器，因为都间接性的继承了ClassLoader
  
  
  通过java代码获取三种类加载器：
• 获取系统类加载器
  我们直接通过ClassLoader.getSystemClassLoader()来获取系统类加载器就可以获取到，然后当我们获取我们的类的加载器时ClassLoaderTest.class.getClassLoader()，发现得到的地址和系统类加载器的地址是一样的。
  因此，对于用户自定义类来说：默认使用系统类加载器进行加载
• 获取扩展类加载器
  我们是通过系统类加载器的systemClassLoader.getParent()来获取扩展类加载器的。
• 获取引导类加载器
  通过扩展类加载器的extClassLoader.getParent()获取引导类加载器是获取不到的，返回值是null。
  这并不代表引导类加载器不存在，因为引导类加载器右 C/C++ 语言，我们获取不到
  当我们获取String的加载器时发现也是null，说明String类使用引导类加载器进行加载的。—> Java的核心类库都是使用引导类加载器进行加载的。

public class ClassLoaderTest {
    public static void main(String[] args) {

        //获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);//sun.misc.Launcher$AppClassLoader@18b4aac2

        //获取其上层：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);//sun.misc.Launcher$ExtClassLoader@1540e19d

        //获取其上层：获取不到引导类加载器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader);//null

        //对于用户自定义类来说：默认使用系统类加载器进行加载
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(classLoader);//sun.misc.Launcher$AppClassLoader@18b4aac2

        //String类使用引导类加载器进行加载的。---> Java的核心类库都是使用引导类加载器进行加载的。
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1);//null

    }
}

虚拟机自带的加载器

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

启动类加载器是虚拟机自带的加载器

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

• 它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
  出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

  通过代码获取启动类加载器能够加载的路径
  
  

• 并不继承自java.lang.ClassLoader，没有父（上级）加载器

• 加载扩展类和应用程序类加载器，并作为他们的父类（上级）加载器
  扩展类和应用程序类加载器也是对象，也需要加载，所以就用启动类加载器来加载他们

扩展类加载器（Extension ClassLoader）

扩展类加载器是虚拟机自带的加载器

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

• 派生于ClassLoader类

• 父类（上级）加载器为启动类加载器
  也就是通过getParent得到的是启动类加载器，注意这个不是继承关系！

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

  通过代码获取扩展类加载器能够加载的类的路径：

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

• Java语言编写，由sun.misc.LaunchersAppClassLoader实现
• 派生于ClassLoader类
• 父类（上级）加载器为扩展类加载器
  也就是通过getParent得到的是扩展类加载器，注意这个不是继承关系！
• 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
• 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
• 通过classLoader.getSystemclassLoader()方法可以获取到该类加载器

用户自定义类加载器

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

• 为什么需要自定义类加载器？
  • 隔离加载类
    防止类冲突
  • 修改类加载的方式
  • 扩展加载源
  • 防止源码泄漏
    为防止字节码文件被加密和篡改，可以对字节码文件进行加密，自己要运行时还原成内存中的类需要解密，这时就需要自定义类加载器去进行解密操作
• 如何自定义类加载器？
  • 方式一：继承抽象类java.lang.ClassLoader类的方式，实现findclass()方法
  • 方式二：继承URLClassLoader类
    在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findclass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

ClassLoader类

• ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）
  这些方法都不是抽象的
  

• ClassLoader类的继承关系
  sun.misc.Launcher 它是一个java虚拟机的入口应用
  

获取ClassLoader 途径

代码示例：

public class ClassLoaderTest2 {
    public static void main(String[] args) {
        try {
            
            //1.Class.forName().getClassLoader()
            ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
            System.out.println(classLoader); // String 类由启动类加载器加载，我们无法获取

            //2.Thread.currentThread().getContextClassLoader()
            ClassLoader classLoader1 = Thread.currentThread().getContextClassLoader();
            System.out.println(classLoader1);

            //3.ClassLoader.getSystemClassLoader().getParent()
            ClassLoader classLoader2 = ClassLoader.getSystemClassLoader();
            System.out.println(classLoader2);

        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

// 输出
null
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2

双亲委派机制

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

• 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
• 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
• 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。
• 父类加载器一层一层往下分配任务，如果子类加载器能加载，则加载此类，如果将加载任务分配至系统类加载器也无法加载此类，则抛出异常
  
  例子1：

例子2：
当我们加载jdbc.jar 用于实现数据库连接的时候

• 首先我们需要知道的是 jdbc.jar是基于SPI接口进行实现的
• 所以在加载的时候，会进行双亲委派，最终从根加载器中加载 SPI核心类，然后再加载SPI接口类
• 接着在进行反向委托，通过线程上下文类加载器进行实现类 jdbc.jar的加载。
  

双亲委派机制的优势

• 避免类的重复加载
• 保护程序安全，防止核心API被随意篡改
  • 自定义类：java.lang.String
    当我们自己写一个java.lang.String，并在这个String类里写一个main方法，运行时会报错。
    原因：我们现在想执行main方法，main方法所在类要被加载，这时就要用双亲委派机制一层层向上委托，当委派到BootStrapClassLoader的时候，他加载了String以后会执行main方法，核心API里的那个String是没有main方法的，所以就报错了。也就是他根本就没有加载我们自定义的这个String类。
    
  • 自定义类：java.lang.ShkStart（报错：阻止创建 java.lang开头的类）
    委托到引导类加载器后，引导类加载器一看是java.lang开头的，就要加载，出于保护机制，java.lang 包下不允许我们自定义类
    

沙箱安全机制

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

JVM表示两个class对象为同一个类的必要条件

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

1. 类的完整类名必须一致，包括包名
2. 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同

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

对类加载器的引用

1. JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的
2. 如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中
3. 当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的

类的主动使用和被动使用

Java程序对类的使用方式分为：主动使用和被动使用。
主动使用和被动使用的区别在于，被动使用都不会导致类的初始化，即不会执行初始化阶段（不会调用 clinit() 方法和 init() 方法）

主动使用，又分为七种情况：

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

除了以上七种情况，其他使用Java类的方式都被看作是对类的被动使用