一.Class文件结构

1.概述

1.1 字节码文件的跨平台性

所有的JVM全部遵守Java虚拟机规范:Java SE Specifications，也就是说所有的JV环境都是一样的，这样一来字节码文件可以在各种JVM上运行。

1.2 Java的前端编译器

想要让一个Java程序正确地运行在JVM中，Java源码就必须要被编译为符合JVM规范的字节码。
前端编译器的主要任务就是负责将符合Java语法规范的Java代码转换为符合JVM规范的字节码文件。javac是一种能够将Java源码编译为字节码的前端编译器。
Javac编译器在将Java源码编译为一个有放的字节码文件过程中经历了4个步骤，分别是词法解析、语法解析、语义解析以及生成字节码。

 前端编译器vs后端编译器

Java源代码的编译结果是字节码，那么肯定需要有一种编译器能够将Java源码编译为字节码，承担这个重要责任的就是配置在path环境变量中的javac编译器。javac是一种能够将Java源码编译为字节码的前端编译器。

HotSpot VM并没有强制要求前端编译器只能使用javac来编译字节码，其实只要编译结果符合JVM规范都可以被JVM所识别即可。在Java的前端编译器领域，除了javac之外，还有一种被大家经常用到的前端编译器,那就是内置在Eclipse中的ECJ(EclipseCompiler for Java)编译器。和Javac的全量式编译不同，EC是一种增量式编译器。

在Eclipse中，当开发人员编写完代码后，使用“Ctrl+S”快捷键时，ECJ编译器所采取的编译方案是把未编译部分的源码逐行进行编译，而非每次都全量编译。因此ECJ的编译效率会比javac更加迅速和高效，当然编译质量和javac相比大致还是一样的。ECJ不仅是Eclipse的默认内置前端编译器，在Tomcat中同样也是使用ECJ编译器来编译jsp文件。由于ECJ编译器是采用GPLv2的开源协议进行源代码公开，所以，大家可以登录eclipse官网下载ECJ编译器的源码进行二次开发。

默认情况下，IntelliJ IDEA 使用javac编译器。(还可以自己设置为AspectJ编译器ajc)
前端编译器并不会直接涉及编译优化等方面的技术，而是将这些具体优化细节移交给HotSpot的JIT编译器负责。

复习:AOT(静态提前编译器，Ahead Of Time Compiler)

1.3 透过字节码指令看代码细节

大厂面试题
类文件结构有几个部分?│
知道字节码吗?字节码都有哪些? Integer x = 5;int y = 5;比较x == y都经过哪些步骤?

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

        Integer x = 5;
        int y = 5;
        System.out.println(x == y);//true

        Integer i1 = 10;
        Integer i2 = 10;
        System.out.println(i1 == i2);//true

        Integer i3 = 128;
        Integer i4 = 128;
        System.out.println(i3 == i4);//false

    }
}

上述代码分析
System.out.println(x == y);//true 返回true是因为x自动拆箱成int类型，两个都是基本数据类型直接比较值是否相等。

System.out.println(i1 == i2);//true 返回true是因为Integer类型对-128到127之间的数字做了缓存。

System.out.println(i3 == i4);//false 超出了缓存
在Integer类加载到内存中时，会执行其内部类IntegerCache中静态代码块进行初始化，把 [-128,127]之间的数包装成Integer类并把其对应的引用存入到cache数组中，这样在方法区中开辟空间存放这些静态Integer变量，同时静态cache数组也存放在这里，供线程享用，这也称静态缓存。当用Integer声明初始化变量时，会先判断所赋值的大小是否在-128到127之间，若在，则利用静态缓存中的空间并且返回对应cache数组中对应引用，存放到运行栈中，而不再重新开辟内存。

public class StringTest {
    public static void main(String[] args) {
        String str = new String("hello") + new String("world");
        String str1 = "helloworld";
        System.out.println(str == str1); //false
        String str2 = new String("helloworld");
        System.out.println(str == str2); //false
    }
 }

当拼接两个变量时，+其实底层是StringBuilder的append方法，最终调用了StringBuilder.toString方法，new了一个新字符串来返回
而str1 最保存到了字符串常量池，new String(“helloworld”)也是构建了一个新的字符串，所以两个都是false

/*
成员变量（非静态的）的赋值过程： ① 默认初始化 - ② 显式初始化 /代码块中初始化 - ③ 构造器中初始化 - ④ 有了对象之后，可以“对象.属性”或"对象.方法"
 的方式对成员变量进行赋值。
 */
class Father {
    int x = 10;

    public Father() {
        this.print();
        x = 20;
    }
    public void print() {
        System.out.println("Father.x = " + x);
    }
}

class Son extends Father {
    int x = 30;
//    float x = 30.1F;
    public Son() {
        this.print();
        x = 40;
    }
    public void print() {
        System.out.println("Son.x = " + x);
    }
}

public class SonTest {
    public static void main(String[] args) {
        Father f = new Son();
        System.out.println(f.x);
    }
}

执行结果其实并不尽如人意，是吧？？？

Son.x = 0
Son.x = 30
20

new Son()的时候会先去调用父类的构造方法，而父类的构造方法中调用了this.print()，此处的this指的是当前的调用对象，谁调谁就是this,所以this.print()调用的子类的print方法，因为此时子类属性还未进行显式初始化，只是进行了默认初始化，所以是0。然后执行x = 20;将父类的属性x的值由10改为了20。然后执行子类的构造方法，调用this.print();此时子类属性已经完成了显式初始化，所以x是30。最后打印f.x的值，因为属性并不具有多态性，方法才具有多态性，所以是20。

2. 虚拟机的基石:Class文件

字节码文件里是什么?
源代码经过编译器编译之后便会生成一个或多个字节码文件，字节码是一种二进制的类文件，
它的内容是JVM的指令，而不像C、C++编译直接生成机器码。

什么是字节码指令(byte code)?
Java虚拟机的指令由一个字节长度的、代表着某种特定操作含义的操作码（opcode）以及跟随其后的零至多个代表此操作所需参数
的操作数（ operand）所构成。虚拟机中许多指令并不包含操作数，只有一个操作码。

字节码指令:操作码（操作数)
比如astore_3只有操作码，astore 4 既有操作码也有操作数。因为astore_0到astore_3比较常用，所以提供了现成的操作码。

  

3. Class文件结构

官方文档位置:
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html

. class类的本质
任何一个Class文件都对应着唯一一个类或接口的定义信息，但反过来说，Class文件实际上它并不一定以磁盘文件的形式存在。Class 文件是一组以8位字节为基础单位的二进制流。

. class文件格式
class的结构不像XML等描述语言，由于它没有任何分隔符号。所以在其中的数据项，无论是字节顺序还是数量，都是被严格限定的，哪个字节代表什么含义，长度是多少，先后顺序如何，都不允许改变。

Class文件格式采用一种类似于C语言结构体的方式进行数据存储，这种结构中只有两种数据类型:无符号数和表。
无符号数属于基本的数据类型，以u1、u2、u4、u8 来分别代表1个字节、2个字节、4个字节和8个字节的无符号数，无符号数可以用来描述数字、索引引用、数量值或者按照 UTF-8编码构成字符串值。
表是由多个无符号数或者其他表作为数据项构成的复合数据类型，所有表都习惯性地以“_info”结尾。表用于描述有层次
关系的复合结构的数据，整个class 文件本质上就是一张表。由于表没有固定长度，所以通常会在其前面加上个数说明

换句话说，充分理解了每一个字节码文件的细节，自己也可以反编译出Java源文件来。

class文件的结构并不是一成不变的，随着Java虚拟机的不断发展，总是不可避免地会对Class文件结构做出一些调整，但是其基本结构和框架是非常稳定的。

3.1 魔数

Class文件的标志Magic Number（魔数)
每个Class 文件开头的4个字节的无符号整数称为魔数（Magic Number)

它的唯一作用是确定这个文件是否为一个能被虚拟机接受的有效合法的Class文件。即:魔数是Class文件的标识符。
魔数值固定为OxCAFEBABE。不会改变。

如果一个Class文件不以0xCAFEBABE开头，虚拟机在进行文件校验的时候就会直接抛出以下错误:
Error: A JNI error has occurred,please check your installation and try again
Exception in thread “main” java.lang.ClassFormatError: Incompatible magic value 1885430635 in classfile StringTest

使用魔数而不是扩展名来进行识别主要是基于安全方面的考虑，因为文件扩展名可以随意地改动。

3.2 Class文件版本号

紧接着魔数的4个字节存储的是Class 文件的版本号。同样也是4个字节。第5个和第6个字节所代表的含义就是编译的副版本号minor_version，而第7个和第8个字节就是编译的主版本号major_version。
它们共同构成了class文件的格式版本号。譬如某个Class 文件的主版本号为M，副版本号为 m，那么这个Class 文件的格式版本号就确定为M.m。

版本号和Java编译器的对应关系如下表:

Java 的版本号是从45开始的，JDK 1.1之后的每个JDK大版本发布主版本号向上加1。
不同版本的Java编译器编译的Class文件对应的版本是不一样的。目前，高版本的Java虚拟机可以执行由低版本编译器生成的Class文件,但是低版本的Java虚拟机不能执行由高版本编译器生成的Class文件。

否则JVM会抛出java.lang.UnsupportedClassVersionError异常。(向下兼容)

在实际应用中，由于开发环境和生产环境的不同，可能会导致该问题的发生。因此需要我们在开发时，特别注意开发编译的
DK版本和生产环境中的JDK版本是否一致。
虚拟机J版本为1.k (k >= 2)时，对应的class文件格式版本号的范围为45.0 - 44+k.0(含两端）。

高版本的虚拟机可以执行低版本的字节码文件，反之不可以。

3.3 常量池

常量池:存放所有常量
常量池是Class文件中内容最为丰富的区域。常量池对于Class文件中的字段和方法解析也有着至关重要的作用。随着Java虚拟机的不断发展，常量池的内容也日渐丰富。可以说，常量池是整个Class文件的基石。

在版本号之后，紧跟着的是常量池的数量，以及若干个常量池表项。
常量池中常量的数量是不固定的，所以在常量池的入口需要放置一项u2类型的无符号数，代表常量池容量计数值（
constant_pool_count）。与Java中语言习惯不一样的是，这个容量计数是从1而不是0开始的。

常量池表
constant_pool (常量池)
constant_pool是一种表结构，以1～ constant_pool_count - 1为索引。表明了后面有多少个常量项。·常量池主要存放两大类常量:字面量（Literal）和符号引用(Symbolic References)
它包含了class文件结构及其子结构中引用的所有字符串常量、类或接口名、字段名和其他常量。常量池中的每一项都具备相同
的特征。第1个字节作为类型标记，用于确定该项的格式，这个字节称为tag byte (标记字节、标签字节）。

 

 
3.4 访问标识

3.5 类索引、父类索引、接口索引集合

 

3.6 字段表集合

 
3.7 方法表集合

3.8 属性表集合

 

 
4. 使用javap指令解析Class文件

 

javap -v -p test.class 可以看到最全的信息，-v是看不到私有字段和私有方法的。

public class JavapTest {
    private int num;
    boolean flag;
    protected char gender;
    public String info;

    public static final int COUNTS = 1;
    static{
        String url = "www.atguigu.com";
    }
    {
        info = "java";
    }
    public JavapTest(){

    }
    private JavapTest(boolean flag){
        this.flag = flag;
    }
    private void methodPrivate(){

    }
    int getNum(int i){
        return num + i;
    }
    protected char showGender(){
        return gender;
    }
    public void showInfo(){
        int i = 10;
        System.out.println(info + i);
    }
}


Classfile /C:/Users/songhk/Desktop/2/JavapTest.class    //字节码文件所属的路径
  Last modified 2020-9-7; size 1358 bytes        //最后修改时间，字节码文件的大小
  MD5 checksum 526b4a845e4d98180438e4c5781b7e88         //MD5散列值
  Compiled from "JavapTest.java"            //源文件的名称
public class com.atguigu.java1.JavapTest
  minor version: 0                    //副版本
  major version: 52                    //主版本
  flags: ACC_PUBLIC, ACC_SUPER                //访问标识
Constant pool:                        //常量池
   #1 = Methodref          #16.#46        // java/lang/Object."<init>":()V
   #2 = String             #47            // java
   #3 = Fieldref           #15.#48        // com/atguigu/java1/JavapTest.info:Ljava/lang/String;
   #4 = Fieldref           #15.#49        // com/atguigu/java1/JavapTest.flag:Z
   #5 = Fieldref           #15.#50        // com/atguigu/java1/JavapTest.num:I
   #6 = Fieldref           #15.#51        // com/atguigu/java1/JavapTest.gender:C
   #7 = Fieldref           #52.#53        // java/lang/System.out:Ljava/io/PrintStream;
   #8 = Class              #54            // java/lang/StringBuilder
   #9 = Methodref          #8.#46         // java/lang/StringBuilder."<init>":()V
  #10 = Methodref          #8.#55         // java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
  #11 = Methodref          #8.#56         // java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
  #12 = Methodref          #8.#57         // java/lang/StringBuilder.toString:()Ljava/lang/String;
  #13 = Methodref          #58.#59        // java/io/PrintStream.println:(Ljava/lang/String;)V
  #14 = String             #60            // www.atguigu.com
  #15 = Class              #61            // com/atguigu/java1/JavapTest
  #16 = Class              #62            // java/lang/Object
  #17 = Utf8               num
  #18 = Utf8               I
  #19 = Utf8               flag
  #20 = Utf8               Z
  #21 = Utf8               gender
  #22 = Utf8               C
  #23 = Utf8               info
  #24 = Utf8               Ljava/lang/String;
  #25 = Utf8               COUNTS
  #26 = Utf8               ConstantValue
  #27 = Integer            1
  #28 = Utf8               <init>
  #29 = Utf8               ()V
  #30 = Utf8               Code
  #31 = Utf8               LineNumberTable
  #32 = Utf8               LocalVariableTable
  #33 = Utf8               this
  #34 = Utf8               Lcom/atguigu/java1/JavapTest;
  #35 = Utf8               (Z)V
  #36 = Utf8               methodPrivate
  #37 = Utf8               getNum
  #38 = Utf8               (I)I
  #39 = Utf8               i
  #40 = Utf8               showGender
  #41 = Utf8               ()C
  #42 = Utf8               showInfo
  #43 = Utf8               <clinit>
  #44 = Utf8               SourceFile
  #45 = Utf8               JavapTest.java
  #46 = NameAndType        #28:#29        // "<init>":()V
  #47 = Utf8               java
  #48 = NameAndType        #23:#24        // info:Ljava/lang/String;
  #49 = NameAndType        #19:#20        // flag:Z
  #50 = NameAndType        #17:#18        // num:I
  #51 = NameAndType        #21:#22        // gender:C
  #52 = Class              #63            // java/lang/System
  #53 = NameAndType        #64:#65        // out:Ljava/io/PrintStream;
  #54 = Utf8               java/lang/StringBuilder
  #55 = NameAndType        #66:#67        // append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
  #56 = NameAndType        #66:#68        // append:(I)Ljava/lang/StringBuilder;
  #57 = NameAndType        #69:#70        // toString:()Ljava/lang/String;
  #58 = Class              #71            // java/io/PrintStream
  #59 = NameAndType        #72:#73        // println:(Ljava/lang/String;)V
  #60 = Utf8               www.atguigu.com
  #61 = Utf8               com/atguigu/java1/JavapTest
  #62 = Utf8               java/lang/Object
  #63 = Utf8               java/lang/System
  #64 = Utf8               out
  #65 = Utf8               Ljava/io/PrintStream;
  #66 = Utf8               append
  #67 = Utf8               (Ljava/lang/String;)Ljava/lang/StringBuilder;
  #68 = Utf8               (I)Ljava/lang/StringBuilder;
  #69 = Utf8               toString
  #70 = Utf8               ()Ljava/lang/String;
  #71 = Utf8               java/io/PrintStream
  #72 = Utf8               println
  #73 = Utf8               (Ljava/lang/String;)V
#######################################字段表集合的信息################################################
{                        
  private int num;                //字段名
    descriptor: I                //字段描述符：字段的类型
    flags: ACC_PRIVATE                //字段的访问标识

  boolean flag;
    descriptor: Z
    flags:

  protected char gender;
    descriptor: C
    flags: ACC_PROTECTED

  public java.lang.String info;
    descriptor: Ljava/lang/String;
    flags: ACC_PUBLIC

  public static final int COUNTS;
    descriptor: I
    flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
    ConstantValue: int 1                //常量字段的属性：ConstantValue

#######################################方法表集合的信息################################################
  public com.atguigu.java1.JavapTest();                //构造器1的信息        
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: aload_0
         5: ldc           #2                  // String java
         7: putfield      #3                  // Field info:Ljava/lang/String;
        10: return
      LineNumberTable:
        line 20: 0
        line 18: 4
        line 22: 10
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      11     0  this   Lcom/atguigu/java1/JavapTest;

  private com.atguigu.java1.JavapTest(boolean);            //构造器2的信息    
    descriptor: (Z)V
    flags: ACC_PRIVATE
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: aload_0
         5: ldc           #2                  // String java
         7: putfield      #3                  // Field info:Ljava/lang/String;
        10: aload_0
        11: iload_1
        12: putfield      #4                  // Field flag:Z
        15: return
      LineNumberTable:
        line 23: 0
        line 18: 4
        line 24: 10
        line 25: 15
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      16     0  this   Lcom/atguigu/java1/JavapTest;
            0      16     1  flag   Z

  private void methodPrivate();
    descriptor: ()V
    flags: ACC_PRIVATE
    Code:
      stack=0, locals=1, args_size=1
         0: return
      LineNumberTable:
        line 28: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       1     0  this   Lcom/atguigu/java1/JavapTest;

  int getNum(int);
    descriptor: (I)I
    flags:
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: getfield      #5                  // Field num:I
         4: iload_1
         5: iadd
         6: ireturn
      LineNumberTable:
        line 30: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       7     0  this   Lcom/atguigu/java1/JavapTest;
            0       7     1     i   I

  protected char showGender();
    descriptor: ()C
    flags: ACC_PROTECTED
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: getfield      #6                  // Field gender:C
         4: ireturn
      LineNumberTable:
        line 33: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lcom/atguigu/java1/JavapTest;

  public void showInfo();                
    descriptor: ()V                //方法描述符：方法的形参列表 、 返回值类型
    flags: ACC_PUBLIC                //方法的访问标识
    Code:                    //方法的Code属性
      stack=3, locals=2, args_size=1        //stack:操作数栈的最大深度   locals:局部变量表的长度  args_size：方法接收参数的个数
   //偏移量 操作码     操作数    
     0: bipush        10
         2: istore_1
         3: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
         6: new           #8                  // class java/lang/StringBuilder
         9: dup
        10: invokespecial #9                  // Method java/lang/StringBuilder."<init>":()V
        13: aload_0
        14: getfield      #3                  // Field info:Ljava/lang/String;
        17: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        20: iload_1
        21: invokevirtual #11                 // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
        24: invokevirtual #12                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        27: invokevirtual #13                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        30: return
      //行号表：指名字节码指令的偏移量与java源程序中代码的行号的一一对应关系
      LineNumberTable:
        line 36: 0
        line 37: 3
        line 38: 30
      //局部变量表：描述内部局部变量的相关信息
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      31     0  this   Lcom/atguigu/java1/JavapTest;
            3      28     1     i   I

  static {};
    descriptor: ()V
    flags: ACC_STATIC
    Code:
      stack=1, locals=1, args_size=0
         0: ldc           #14                 // String www.atguigu.com
         2: astore_0
         3: return
      LineNumberTable:
        line 15: 0
        line 16: 3
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
}
SourceFile: "JavapTest.java"            //附加属性：指名当前字节码文件对应的源程序文件名

二.字节码指令集与解析举例

1.概述

执行模型

字节码与数据类型

指令分析

iload_0占1个字节。iload 0 占3个字节。
因为操作码数量有限，只有256个，所以只把常用的0-3设置成了操作码。

2. 加载与存储指令

2.1 复习操作数栈与局部变量表

2.2 局部变量压栈指令

局部变量压栈指令将给定的局部变量表中的数据压入操作数栈。
这类指令大体可以分为:

> xload_<n>(x为i、1、f、d、a，n为0到3> 
> xload (x为i、1、f、d、a)
说明:在这里，x的取值表示数据类型。
指令xload_n表示将第n个局部变量压入操作数栈，比如iload_1、fload_0、aload_0等指令。其中aload_n表示将一个对象引用压栈。
指令xload通过指定参数的形式，把局部变量压入操作数栈，当使用这个命令时，表示局部变量的数量可能超过了4个，比如指令iload、fload等。

2.3 常量入栈指令

常量入栈指令的功能是将常数压入操作数栈

根据数据类型和入栈内容的不同，又可以分为const系列、push系列和ldc指令。
指令const系列:用于对特定的常量入栈，入栈的常量隐含在指令本身里。指令有: iconst_ (i从-1到5)、lconst_(1从0到1)、fconst_(f从0到2)、dconst_(d从0到1)、aconst_null。
比如，
iconst_m1将-1压入操作数栈;iconst_x (x为0到5）将x压入栈:
lconst_0、lconst_1分别将长整数9和1压入栈;
fconstl 0、fconst_1、fconst_2分别将浮点数0、1、2压入栈;dconst_0和dconst_1分别将double型o和1压入栈。
aconst_null将null压入操作数栈;
从指令的命名上不难找出规律，指令助记符的第一个字符总是喜欢表示数据类型，i表示整数，1表示长整数，f表示浮点数，d表示双精度浮点，习惯上用a表示对象引用。如果指令隐含操作的参数，会以下划线形式给出。

指令push系列:主要包括bipush和sipush。它们的区别在于接收数据类型的不同，bipush接收8位整数作为参数，sipush接收16位整数，它们都将参数压入栈。

指令ldc系列:如果以上指令都不能满足需求，那么可以使用万能的ldc指令，它可以接收一个8位的参数，该参数指向常量池中的int、float或者String的索引，将指定的内容压入堆栈。

类似的还有ldc_w，它接收两个8位参数，能支持的索引范围大于ldc。
如果要压入的元素是long或者double类型的,使用ldc2_w指令，使用方式都是类似的。

 
2.4 出栈装入局部变量表指令

出栈装入局部变量表指令用于将操作数栈中栈顶元素弹出后，装入局部变量表的指定位置，用于给局部变量赋值。

这类指令主要以store的形式存在，比如xstore (x为i、l、f、d、a)、 xstore_n (x 为i、1、f、d、a， n为0至3）
其中，指令istore_n将从操作数栈中弹出一个整数，并把它赋值给局部变量索引n位置。
指令xstore由于没有隐含参数信息，故需要提供一个byte类型的参数类指定目标局部变量表的位置。

说明:
一般说来，类似像store这样的命令需要带一个参数，用来指明将弹出的元素放在局部变量表的第几个位置。但是，为了尽可能压缩指令大小，使用专门的istore_1指令表示将弹出的元素放置在局部变量表第1个位置。类似的还有
istore_0、istore_2、istore_3,它们分别表示从操作数栈顶弹出一个元素，存放在局部变量表第0、2、3个位置。
由于局部变量表前几个位置总是非常常用，因此这种做法虽然增加了指令数量，但是可以大大压缩生成的字节码的体积。如果局部变量表很大，需要存储的槽位大于3,那么可以使用istore指令，外加一个参数，用来表示需要存放的槽位位置。

 
3. 算术指令

1）作用:
算术指令用于对两个操作数栈上的值进行某种特定运算，并把结果重新压入操作数栈
2）分类:
大体上算术指令可以分为两种:对整型数据进行运算的指令与对浮点类型数据进行运算的指令。
3）byte、short、char和boolean类型说明
在每一大类中，都有针对Java虚拟机具体数据类型的专用算术指令。但没有直接支持byte、short、char和boolean类型的算术指令，对于这些数据的运算，都使用int类型的指令来处理。此外，在处理boolean、byte、short和char类型的数组时，也会转换为使用对应的int类型的字节码指令来处理。

 
4）运算时的溢出
数据运算可能会导致溢出，例如两个很大的正整数相加，结果可能是一个负数。其实Java虚拟机规范并无明确规定过整
型数据溢出的具体结果，仅规定了在处理整型数据时，只有除法指令以及求余指令中当出现除数为o时会导致虚拟机抛出异常ArithmeticException。
5）运算模式
向最接近数舍入模式:JVM要求在进仃浮点数T昇的，所有色界结木培近览代牛件择最低有效位为零的;
舍入为可被表示的最接近的精确值，如果有两种可表示的形式与该值一样接近，将优先选择最低有效位为零的;
向零舍入模式:将浮点数转换为整数时，采用该模式，该模式将在目标数值类型中选择一个最接近但是不大于原值
的数字作为最精确的舍入结果;
6）NaN值使用
当一个操作产生溢出时，将会使用有符号的无穷大表示，如果某个操作结果没有明确的数学定义的话，将会使用NaN值来表示。而且所有使用NaN值作为操作数的算术操作，结果都会返回 NaN;

i=i+10与i+=10的区别

 

i++与++i的问题

对于不涉及赋值操作的i++和++i并无区别，字节码一模一样

涉及赋值操作的i++和++i

验证java基础所学的++在前，先++后赋值；++在后，先赋值，后++。

根据字节码理解

iinc (注意该指令只针对 int 类型的数据,其它类型的数据自增不使用 iinc 指令,使用的与常数 1 相加的操作,iinc 是在局部变量表上直接做自增的操作,并不是在操作数栈上做自增的操作)

先把10压入操作数栈，然后把10放入局部变量表1的位置，然后把局部变量表1的位置的元素加载到操作数栈，然后对局部变量表1的位置的元素加一，然后把操作数栈中的元素保存到局部变量表2的位置。

先把20压入操作数栈，然后把20放入局部变量表3的位置，然后对局部变量表3的位置的元素加一，然后把局部变量表3的位置的元素加载到操作数栈，然后把操作数栈中的元素保存到局部变量表4的位置。

 为啥打印出来是10？局部变量表中变为了11，但随后又被覆盖了成了10。

比较指令

 
4、类型转换指令

类型转换指令说明
类型转换指令可以将两种不同的数值类型进行相互转换。
这些转换操作一般用于实现用户代码中的显式类型转换操作，或者用来处理字节码指令集中数据类型相关指令无法与数据类型一一对应的问题。

4.1 宽化类型转换（widening Numeric Conversions）

4.1.1 转换规则

Java虚拟机直接支持以下数值的宽化类型转换（widening numeric conversion,小范围类型向大范围类型的安全转换）。也就是说，并不需要指令执行，包括:
从int类型到long、float或者double类型。对应的指令为: i2l、i2f、i2d
从long类型到float、double类型。对应的指令为:l2f、l2d
从float类型到double类型。对应的指令为:f2d
简化为: int --> long -->float --> double

4.1.2 精度损失问题

宽化类型转换是不会因为超过目标类型最大值而丢失信息的，例如，从int转换到 long，或者从int转换到double，都不会丢失任何信息，转换前后的值是精确相等的。
从int、long类型数值转换到float，或者long类型数值转换到double时，将可能发生精度丢失—―可能丢失掉几个最低有效位上的值，转换后的浮点数值是根据IEEE754最接近舍入模式所得到的正确整数值。
尽管宽化类型转换实际上是可能发生精度丢失的，但是这种转换永远不会导致Java虚拟机抛出运行时异常。

//举例：精度损失的问题
@Test
public void upCast2(){
  int i = 123123123;
  float f = i;
  System.out.println(f);//123123120

  long l = 123123123123L;
  l = 123123123123123123L;
  double d = l;
  System.out.println(d);//123123123123123120
}

4.1.3 补充说明

从byte、char和short类型到int类型的宽化类型转换实际上是不存在的。对于byte类型转为int ,虚拟机并没有做实质性的转化处理，只是简单地通过操作数栈交换了两个数据。而将byte转为long时，使用的是i2l,可以看到在内部byte在这里已经等同于int类型处理，类似的还有short类型，这种处理方式有两个特点:
一方面可以减少实际的数据类型，如果为short和byte都准备一套指令，那么指令的数量就会大增，而虚拟机目前的设计上，只愿意使用一个字节表示指令，因此指令总数不能超过256个，为了节省指令资源，将short和byte当做int处理也在情理之中。
另一方面，由于局部变量表中的槽位固定为32位，无论是byte或者short存入局部变量表，都会占用32位空间。从这个角度说，也没有必要特意区分这几种数据类型。

4.2 窄化类型转换（Narrowing Numeric Conversion）
 

4.2.1 转换规则

Java虚拟机也直接支持以下窄化类型转换:
从int类型至byte、short或者char类型。对应的指令有: i2b、 i2c、i2s
从long类型到int类型。对应的指令有:l2i
从float类型到int或者long类型。对应的指令有:f2i、f2l
从double类型到int、long或者float类型。对应的指令有: d2i、d21、d2f

4.2. 2精度损失问题

窄化类型转换可能会导致转换结果具备不同的正负号、不同的数量级，因此，转换过程很可能会导致数值丢失精度。
尽管数据类型窄化转换可能会发生上限溢出、下限溢出和精度丢失等情况，但是Java虚拟机规范中明确规定数值类型的窄化转换指令永远不可能导致虚拟机抛出运行时异常

4.2.3 补充说明

当将一个浮点值窄化转换为整数类型T (T限于int或long类型之一）的时候，将遵循以下转换规则:
如果浮点值是NaN，那转换结果就是int或long类型的0。
如果浮点值不是无穷大的话，浮点值使用IEEE754的向零舍入模式取整，获得整数值v，如果v在目标类型T(int或long)的表示范围之内，那转换结果就是v。否则，将根据v的符号，转换为T所能表示的最大或者最小正数

当将一个double类型窄化转换为float类型时，将遵循以下转换规则:
通过向最接近数舍入模式舍入一个可以使用float类型表示的数字。最后结果根据下面这3条规则判断:

如果转换结果的绝对值太小而无法使用float来表示，将返回 float类型的正负零。
如果转换结果的绝对值太大而无法使用 float来表示，将返回 float类型的正负无穷大。
对于double类型的NaN值将按规定转换为 float类型的NaN值。

5. 方法调用与返回指令

Java是面向对象的程序设计语言，虚拟机平台从字节码层面就对面向对象做了深层次的支持。有一系列指令专门用于对象操作，可进一步细分为创建指令、字段访问指令、数组操作指令、类型检查指令

5.1 创建指令

虽然类实例和数组都是对象，但Java虚拟机对类实例和数组的创建与操作使用了不同的字节码指令:
1）创建类实例的指令:
创建类实例的指令: new
它接收一个操作数，为指向常量池的索引，表示要创建的类型，执行完成后，将对象的引用压入栈。
2）创建数组的指令:
创建数组的指令:newarray、anewarray、multianewarray。
newarray:创建基本类型数组
anewarray:创建引用类型数组
multinewarray:创建多维数组
上述创建指令可以用于创建对象或者数组，由于对象和数组在Java中的广泛使用，这些指令的使用频率也非常高。

5.2 字段访问指令

对象创建后，就可以通过对象访问指令获取对象实例或数组实例中的字段或者数组元素。
访问类字段(static字段，或者称为类变量）的指令: getstatic. putstat
访问类实例字段（非static字段，或者称为实例变量）的指令:getfield、 putfield

举例:
以getstatic指令为例，它含有一个操作数，为指向常量池的Fieldref索引，它的作用就是获取Fieldref指定的对象或者值，并将其压入操作数栈。
public void sayHello(){
system.out.println( “hello” );
}
对应的字节码指令:

图示:
注意：get是入栈，而put是出栈

 
5.3 数组操作指令

数组操作指令主要有: xastore和xaload指令。

具体为:
把一个数组元素加载到操作数栈的指令: baload、caload、saload、iaload、laload、faload、daload、aaload
将一个操作数栈的值存储到数组元素中的指令: bastore、castore、sastore、iastore、lastore、fastore、dastore、aastore

取数组长度的指令:arraylength
该指令弹出栈顶的数组元素，获取数组的长度，将长度压入栈。

 说明
指令xaload表示将数组的元素压栈，比如saload、caload分别表示压入short数组和char数组。指令
xaload在执行时，要求操作数中栈顶元素为数组索引i,栈顶顺位第2个元素为数组引用a,该指令会弹出栈顶这两个元素，并将a[i]重新压入堆栈。
xastore则专门针对数组操作，以iastore为例，它用于给一个int数组的给定索引赋值。在iastore执行前，操作数栈顶需要以此准备3个元素:值、索引、数组引用，iastore会弹出这3个值，并将值赋给数组中指定索引的位置。

 

5.4 类型检查指针

类型检查指令
检查类实例或数组类型的指令:instanceof、checkcast。
指令checkcast用于检查类型强制转换是否可以进行。如果可以进行，那么checkcast指令不会改变操作数栈，否则它会抛出ClasscastException异常。
指令instanceof用来判断给定对象是否是某一个类的实例，它会将判断结果压入操作数栈。

6.方法调用与返回指令

6.1 方法调用指令

方法调用指令:

invokevirtual、invokeinterface、invokespecial、invokestatic 、 invokedynamic

以下5条指令用于方法调用:
invokevirtual指令用于调用对象的实例方法，根据对象的实际类型进行分派（虚方法分派），支持多态。这也是Java语言中最常见的方法分派方式。

invokeinterface指令用于调用接口方法，它会在运行时搜索由特定对象所实现的这个接口方法，并找出适合的方法进行调用。

invokespecial指令用于调用一些需要特殊处理的实例方法，包括实例初始化方法（构造器）、私有方法和父类方法。这些方法都是静态类型绑定的，不会在调用时进行动态派发。

invokestatic指令用于调用命名类中的类方法（static方法）。这是静态绑定的。

invokedynamic:调用动态绑定的方法，这个是DK 1.7后新加入的指令。用于在运行时动态解析出调用点限定符所引用的方法，并执行该方法。

前面4条调用指令的分派逻辑都固化在 java 虚拟机内部，而invokedynamic指令的分派逻辑是由用户所设定的引导方法决定的。

6.1.1 invokespecial

静态分派：方法都不能被重写（父类方法也是确定的）

 

6.1.2 invokestatic

静态分派

6.1.3 invokeinterface

/**
 * @author shkstart
 * @create 2020-09-10 17:26
 * 补充：方法调用指令的补充说明
 */
public class InterfaceMethodTest {
    public static void main(String[] args) {
        AA aa = new BB();
        aa.method2();
        AA.method1();
    }
}

interface AA{
    public static void method1(){}
    public default void method2(){}
}

class BB implements AA{
}

6.2 方法返回指令

方法调用结束前，需要进行返回。方法返回指令是根据返回值的类型区分的。
包括ineturn（当返回值是 boolean、byte、char、short和int类型时使用）、lreturn、freturn、dreturn和aretdrn
另外还有一条return 指令供声明为 void的方法、实例初始化方法以及类和接口的类初始化方法使用。

举例
通过ineturn指令,将当前函数操作数栈的顶层元素弹出，并将这个元素压入调用者函数的操作数栈中（因为调用者非常关心函数的返回值），所有在当前函数操作数栈中的其他元素都会被丢弃。
如界当前返回的是synchronized方法，那么还会执行一个隐含的monitorexit指令，
退出临界区。
最后，会丢弃当前方法的整个帧，恢复调用者的帧，并将控制权转交给调用者。
返回指令类型看方法的返回值类型。

7. 操作数栈管理指令

如同操作一个普通数据结构中的堆栈那样，JVM提供的操作数栈管理指令，可以用于直接操作操作数栈的指令。
这类指令包括如下内容:
将一个或两个元素从栈顶弹出，并且直接废弃:pop，pop2;
复制栈顶一个或两个数值并将复制值或双份的复制值重新压入栈顶:dup，dup2，dup_x1,dup2_x1, dup_x2，dup2_x2;
将栈最顶端的两个Slot数值位置交换:swap。Java虚拟机没有提供交换两个64位数据类型（long、double）数值的指令。·指令nop,是一个非常特殊的指令，它的字节码为0x00。和汇编语言中的nop一样，它表示什么都不做。这条指令一般可用于调试、占位等。
这些指令属于通用型，对栈的压入或者弹出无需指明数据类型。

说明:
不带_x的指令是复制栈顶数据并压入栈顶。包括两个指令，dup和dup2
dup的系数代表要复制的slot个数。
dup开头的指令用于复制1个Slot的数据。例如1个int或1个reference类型数据dup2开头的指令用于复制2个Slot的数据。例如1个long，或2个int，或1个int+1个float类型数据
带_x的指令是复制栈顶数据并插入栈顶以下的某个位置。共有4个指令, dup_x1,dup2_x1,dup_x2,dup2_x2。对于带_x的复制插入指令，只要将指令的dup和x的系数相加，结果即为需要插入的位置。
因此dup_x1插入位置:1+1=2，即栈顶2个slot下面dup_x2插入位置:1+2=3，即栈顶3个slot下面dup2_x1插入位置:2+1=3，即栈顶3个slot下面. dup2_x2插入位置:2+2=4，即栈顶4个S1ot下面
pop:,将栈顶的1个Slot数值出栈。例如1个short类型数值
popz将栈顶的2个Slot数值出栈。例如1个double类型数值，或者2个int类型数值

new:创建对象
dup:复制对象引用
invokespecial：调用对象的初始化方法
astore_1:将对象引用保存到局部变量表下标为1的位置
aload_1:将局部变量表下标为1 的数据加载到操作数栈
invokevirtual：调用对象的toString方法
astore_2:将info对象引用保存到局部变量表下标为2的位置
return:结束方法

8. 控制转移指令

程序流程离不开条件控制，为了支持条件跳转，虚拟机提供了大量字节码指令，大体上可以分为
1)比较指令、2)条件跳转指令、3)比较条件跳转指令、4)多条件分支跳转指令、5)无条件跳转指令等。

数值类型的数据，才可以谈大小!(bytelshort\char\int; long\float \double)
boolean、引用数据类型不能比较大小。

8.1 条件跳转指令

条件跳转指令通常和比较指令结合使用。在条件跳转指令执行前，一般可以先用比较指令进行栈顶元素的准备，然后进行条件跳转。
条件跳转指令有: ifeq， iflt, ifle， ifne，ifgt，ifge，ifnull,ifnonnull。这些指令都接收两个字节的操作数，用于计算跳转的位置(16位符号整数作为当前位置的offset)。
它们的统一含义为:弹出栈顶元素，测试它是否满足某一条件，如果满足条件，则跳转到给定位置。

注意:
1）与前面运算规则一致:
对于boolean、byte、char、short类型的条件分支比较操作，都是使用int类型的比较指令完成
对于long、float、double类型的条件分支比较操作，则会先执行相应类型的比较运算指令，运算指令会返回一个整型值到操作数栈中，随后再执行int类型的条件分支比较操作来完成整个分支跳转
2）由于各类型的比较最终都会转为 int类型的比较操作，所以Java虚拟机提供的int类型的条件分支指令是最为丰富和强大的。

8.2 比较条件跳转指令

比较条件跳转指令
比较条件跳转指令类似于比较指令和条件跳转指令的结合体，它将比较和跳转两个步骤合二为一。
这类指令有: if_icmpeq、if_icmpne、if_icmplt、if_icmpgt、if_icmple、if_icmpge、if_acmpeq和if_acmpne.。其中指令助记符加上“if_”后，以字符“i”开头的指令针对int型整数操作(也包括short和byte类型)，以字符“a”开头的指令表示对象引用的比较。
这些指令都接收两个字节的操作数作为参数，用于计算跳转的位置。同时在执行指令时，栈顶需要准备两个元素进行比较。指令执行完成后，栈顶的这两个元素被清空，且没有任何数据入栈。如果预设条件成立，则执行跳转，否则，继续执行下一条语句。

 

8.3 多条件分支跳转

多条件分支跳转指令是专为switch-case语句设计的，主要有tableswitch和lookupswitch。

从助记符上看，两者都是switch语句的实现，它们的区别:
tableswitch要求多个条件分支值是连续的，它内部只存放起始值和终止值，以及若干个跳转偏移量，通过给定的操作数index，可以立即定位到跳转偏移量位置，因此效率比较高。|
指令lookupswitch内部存放着各个离散的case-offset对，每次执行都要搜索全部的case-offset对，找到匹配的case值，并根据对应的offset计算跳转地址，因此效率较低。

指令tableswitch的示意图如下图所示。由于tableswitch的case值是连续的，因此只需要记录最低值和最高值，以及每项对应的offset偏移量，根据给定的index值通过简单的计算即可直接定位到offset。

指令lookupswitch处理的是离散的case值，但是出于效率考虑，将case-offset对按照case 值大小排序，给定index时，需要查找与index相等的case,获得其offset,如果找不到则跳转到default。指令lookupswitch 如下图所示。

8.4 无条件跳转指令

目前主要的无条件跳转指令为goto。指令goto接收两个字节的操作数，共同组成一个带符号的整数，用于指定指令的偏移量，指令执行的目的就是跳转到偏移量给定的位置处。
如果指令偏移量太大，超过双字节的带符号整数的范围，则可以使用指令goto_w,它和goto有相同的作用，但是它接收4个字节的操作数，可以表示更大的地址范围。
指令jsr、jsr_w、 ret虽然也是无条件跳转的，但主要用于try-finally语句，且已经被虚拟机逐渐废弃，故不在这里介绍这两个指令。

for循环与while循环的字节码比较  

 do while的字节码

 
9. 异常处理指令

9.1 抛出异常指令:

(1) athrow指令
在Java程序中显示抛出异常的操作（throw语句）都是由athrow指令来实现。
除了使用throw语句显示抛出异常情况之外，JVM规范还规定了许多运仃的开吊云住只i他JaVa应抽出指令应刚到开In"N自动抛出。例如，在之前介绍的整数运算时，当除数为零时，虚拟机会在 idiv或ldiv指令中抛出ArithmeticException异常。
2) 注意
正常情况下，操作数栈的压入弹出都是一条条指令完成的。唯一的例外情况是在抛异常时，Java虚拟机会清除操作数栈上的所有内容，而后将异常实例压入调用者操作数栈上。

异常及异常的处理:
过程一:异常对象的生成过程 —> throw(手动/自动)—>指令: athrow
过程二:异常的处理:抓抛模型。try-catch-finally—>使用异常表

 

9.2 异常处理与异常表

1）处理异常:
在Java虚拟机中，处理异常（catch语句）不是由字节码指令来实现的（早期使用jsr、ret指令），而是采用异常表来完成的。
2）异常表
如果一个方法定义了一个try-catch 或者try-finally的异常处理，就会创建一个异常表。它包含了每个异常处理或者finally块的信息。异常表保存了每个异常处理信息。比如:
起始位置
结束位置
程序计数器记录的代码处理的偏移地址
被捕获的异常类在常量池中的索引

当一个异常被抛出时，JVN会在当前的方法里寻找一个匹配的处理，如果没有找到，这个方法会强制结束并弹出当前栈帧，并且异常会重新抛给上层调用的方法(在调用方法栈帧)。如果在所有栈帧弹出前仍然没有找到合适的异常处理，这个线程将终止。如果这个异常在最后一个非守护线程里抛出，将会导致JVM自己终止，比如这个线程是个main线程。
不管什么时候抛出异常，如果异常处理最终匹配了所有异常类型，代码就会继续执行。在这种情况下，如果方法结束后没有
抛出异常，仍然执行finally块，在return前，它直接跳到finally块来完成目标

try catch：

try finally：

10. 同步指令

10.1 方法级别的同步

java虚拟机支持两种同步结构:方法级的同步和方法内部一段指令序列的同步，这两种同步都是使用monitor来支持的。

方法级的同步:是隐式的，即无须通过字节码指令来控制，它实现在方法调用和返回操作之中。虚拟机可以从方法常量池的方法表结构中的 ACC_SYNCHRONIZED 访问标志得知一个方法是否声明为同步方法;
当调用方法时，调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否设置。
如果设置了，执行线程将先持有同步锁，然后执行方法。最后在方法完成（无论是正常完成还是非正常完成）时释放同步锁。
在方法执行期间，执行线程持有了同步锁，其他任何线程都无法再获得同一个锁.
如果一个同步方法执行期间抛出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的锁将在异常抛到同步方法之外时自动释放。

同步方法与非同步方法的字节码都是一样的，区别在于访问标识。

这段代码和普通的无同步操作的代码没有什么不同，没有使用monitorenter和monitorexit进行同步区控制。这是因为，对于同步方法而言，当虚拟机通过方法的访问标示符判断是一个同步方法时，会自动在方法调用前进行加锁，当同步方法执行完毕后，不管方法是正常结束还是有异常抛出，均会由虚拟机释放这个锁。因此，对于同步方法而言，monitorenter和monitorexit指令是隐式存在的，并未直接出现在字节码中。

10.2 方法内指定指令序列的同步

同步一段指令集序列:通常是由java中的synchronized语句块来表示的。jvm的指令集有monitorenter和monitorexit两条指令来支持synchronized关键字的语义。
当一个线程进入同步代码块时，它使用monitorenter指令请求进入。如果当前对象的监视器计数器为0,则它会被准许进入，若为1,则判断持有当前监视器的线程是否为自己，如果是，则进入，否则进行等待，直到对象的监视器计数器为0,才会被允许进入同步块。
当线程退出同步块时，需要使用monitorexit声明退出。在Java虚拟机中，任何对象都有一个监视器与之相关联，用来判断对象是否被锁定，当监视器被持有后，对象处于锁定状态。
指令monitorenter和monitorexit在执行时，都需要在操作数栈顶压入对象,之后monitorenter和monitorexit的锁定和释放都是针对这个对象的监视器进行的。

下图展示了监视器如何保护临界区代码不同时被多个线程访问，只有当线程4离开临界区后，线程1、2、3才有可能进入。

三.类的加载过程（类的生命周期）详解

 

1. 概述

在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载。

按照Java虚拟机规范，从class文件到加载到内存中的类，到类卸载出内存为止，它的整个生命周期包括如下7个阶段:
其中，验证、准备、解析3个部分统称为链接（Linking）

 

 

大厂面试题
描述一下JVM加载Class文件的原理机制?一面:类加载过程
类加载的时机
java类加载过程?
简述java类加载机制?
JVM中类加载机制，类加载过程?
JVM类加载机制
Java类加载过程
描述一下jvm加载class文件的原理机制
什么是类的加载?
哪些情况会触发类的加载?
讲一下VM加载一个类的过程JVM的类加载机制是什么?

2.Loading(加载)阶段

2.1 加载完成的操作

加载的理解
所谓加载，简而言之就是将Java类的字节码文件加载到机器内存中，并在内存中构建出Java类的原型――类模板对象。所谓类模板对象，其实就是Java类在JVM内存中的一个快照，JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中，这样JVM在运行期便能通过类模板而获取Java类中的任意信息，能够对Java类的成员变量进行遍历，也能进行Java方法的调用。
反射的机制即基于这一基础。如果JVM没有将Java类的声明信息存储起来，则JVM在运行期也无法反射。

加载完成的操作
加载阶段，简言之，查找并加载类的二进制数据，生成Class的实例。在加载类时，Java虚拟机必须完成以下3件事情:
通过类的全名，获取类的二进制数据流。
解析类的二进制数据流为方法区内的数据结构（Java类模型)
创建java.lang.Class类的实例，表示该类型。作为方法区这个类的各种数据的访问入口

2.2 二进制流的获取方式

对于类的二进制数据流，虚拟机可以通过多种途径产生或获得。(只要所读取的字节码符合JVM规范即可)虚拟机可能通过文件系统读入一个class后缀的文件（最常见)
读入jar、zip等归档数据包，提取类文件。
事先存放在数据库中的类的二进制数据
使用类似于HTTP之类的协议通过网络进行加载在运行时生成一段Class的二进制信息等
在获取到类的二进制信息后，Java虚拟机就会处理这些数据，并最终转为一个java.lang.Class的实例。
如果输入数据不是classFile的结构，则会抛出ClassFormatError。

2.3 类模型与Class实例的位置

类模型的位置

加载的类在JVM中创建相应的类结构，类结构会存储在方法区(JDK1.8之前:永久代;JDK1.8及之后:元空间)。

Class实例的位置
将.class文件加载至元空间后，会在堆中创建一个Java.lang.Class对象，用来封装类位于方法区内的数据结构，该Class对象是在加载类的过程中创建的，每个类都对应有一个class类型的对象。

外部可以通过访问代表0rder类的Class对象来获取Order的类数据结构。

class类的构造方法是私有的，只有JVM能够创建。
java.lang.class实例是访问类型元数据的接口，也是实现反射的关键数据入口。
通class类提供的接口，可以获得目标类所关联的.class文件中具体的数据结构:方法、字段等信息。

/**
 * @author shkstart
 * @create 2020-09-11 17:39
 * 过程一：加载阶段
 *
 * 通过Class类，获得了java.lang.String类的所有方法信息，并打印方法访问标识符、描述符
 */
public class LoadingTest {
public static void main(String[] args) {
  try {
      Class clazz = Class.forName("java.lang.String");
      //获取当前运行时类声明的所有方法
      Method[] ms = clazz.getDeclaredMethods();
      for (Method m : ms) {
          //获取方法的修饰符
          String mod = Modifier.toString(m.getModifiers());
          System.out.print(mod + " ");
          //获取方法的返回值类型
          String returnType = m.getReturnType().getSimpleName();
          System.out.print(returnType + " ");
          //获取方法名
          System.out.print(m.getName() + "(");
          //获取方法的参数列表
          Class<?>[] ps = m.getParameterTypes();
          if (ps.length == 0) System.out.print(')');
          for (int i = 0; i < ps.length; i++) {
              char end = (i == ps.length - 1) ? ')' : ',';
              //获取参数的类型
              System.out.print(ps[i].getSimpleName() + end);
          }
          System.out.println();
      }
  } catch (ClassNotFoundException e) {
      e.printStackTrace();
  }
}
}

2.4 数组类的加载

创建数组类的情况稍微有些特殊，因为数组类本身并不是由类加载器负责创建，而是由JVM在运行时根据需要而直接创建的，但数组的元素类型仍然需要依靠类加载器去创建。创建数组类（下述简称A）的过程:

1)如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型;
2)JVM使用指定的元素类型和数组维度来创建新的数组类。

如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。

3. Linking(链接)阶段

3.1 链接阶段之Verification(验证)

当类加载到系统后，就开始链接操作，验证是链接操作的第一步。
它的目的是保证加载的字节码是合法、合理并符合规范的。
验证的步骤比较复杂，实际要验证的项目也很繁多，大体上Java虚拟机需要做以下检查，如图所示。

 

整体说明:
验证的内容则涵盖了类数据信息的格式验证、语义检查、字节码验证，以及符号引用验证等。
其中格式验证会和加载阶段一起执行。验证通过之后，类加载器才会成功将类的二进制数据信息加载到方法区中。
格式验证之外的验证操作将会在方法区中进行。
链接阶段的验证虽然拖慢了加载速度，但是它避免了在字节码运行时还需要进行各种检查。(磨刀不误砍柴工)

具体说明:

1.格式验证:是否以魔数0xCAFEBABE开头，主版本和副版本号是否在当前Java虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等。

2.Java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给予验证通过。比如:·是否所有的类都有父类的存在(在Java里，除了0bject外，其他类都应该有父类，是否一些被定义为final的方法或者类被重写或继承了，
非抽象类是否实现了所有抽象方法或者接口方法，是否存在不兼容的方法(比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度; abstract情况下的方法，就不能是final的了)。

3.Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如:
在字节码的执行过程中，是否会跳转到一条不存在的指令
函数的调用是否传递了正确类型的参数
变量的赋值是不是给了正确的数据类型等

栈映射帧(StackMapTable)就是在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是，100%准确地判断一段字节码是否可以被安全执行是无法实现的，因此，该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的。

在前面3次检查中，已经排除了文件格式错误、语义错误以及字节码的不正确性。但是依然不能确保类是没有问题的。

4.校验器还将进行符号引用的验证。
Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据,如果一个需要使用类无法在系统中找到，则会抛出NoClassDefFoundError,如果一个方法无法被找到，则会抛出NoSuchMethodError。
此阶段在解析环节才会执行。

3.2 链接阶段之Preparation(准备)

准备阶段(Preparation)，简言之，为类的静态变量分配内存，并将其初始化为默认值。
当一个类验证通过时，虚拟机就会进入准备阶段。在这个阶段，虚拟机就会为这个类分配相应的内存空间，并设置默认初始值。Java虚拟机为各类型变量默认的初始值如表所示。

 

注意:Java并不支持boolean类型，对于boolean类型，内部实现是int,由于int的默认值是0,故对应的，boolean的默认值就是false。

这里不包含基本数据类型的字段用static final修饰的情况，因为final在编译的时候就会分配了，准备阶段会显式赋值。
注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。
在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。
 

3.3 链接阶段之Resolution(解析)

在准备阶段完成后，就进入了解析阶段。
解析阶段(Resolution)，简言之，将类、接口、字段和方法的符号引用转为直接引用。

具体描述:
符号引用就是一些字面量的引用，和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中，通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用是不够的，比如当如下println()方法被调用时，系统需要明确知道该方法的位置。
举例:
输出操作System.out.println()对应的字节码:
invokevirtual #24<java/io/PrintStream.println>

以方法为例，Java虚拟机为每个类都准备了一张方法表，将其所有的方法都列在表中。
当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作，符号引用就可以转变为目标方法在类中方法表中的位置，从而使得方法被成功调用。

小结:
所谓解析就是将符号引用转为直接引用，也就是得到类、字段、方法在内存中的指针或者偏移量。因此，可以说，如果直接引用存在，那么可以肯定系统中存在该类、方法或者字段。但只存在符号引用，不能确定系统中一定存在该结构。
不过Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpot VM中，加载、验证、准备和初始化会按照顺序有条不紊地执行，但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行。

 

字符串的复习
最后，再来看一下CONSTANT_String的解析。由于字符串在程序开发中有着重要的作用，因此，读者有必要了解一下String在Java虚拟机中的处理。当在Java代码中直接使用字符串常量时，就会在类中出现CONSTANT_String,它表示字符串常量，并且会引用一个CONSTANT_UTF8的常量项。在Java虚拟机内部运行中的常量池中，会维护一张字符串拘留表(intern)，它会保存所有出现过的字符串常量，并且没有重复项。只要以CONSTANT_String形式出现的字符串也都会在这张表中。使用String .intern()方法可以得到一个字符串在拘留表中的引用，因为该表中没有重复项，所以任何字面相同的字符串的String.intern（)方法返回总是相等的。

4. Initialization（初始化）阶段

初始化阶段，简言之，为类的静态变量赋予正确的初始值。

具体描述
类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码。(即:到了初始化阶段，才真正开始执行类中定义的 Java程序代码。)
初始化阶段的重要工作是执行类的初始化方法:<clinit>()方法。
该方法仅能由Java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是由字节码指令所组成。
它是由类静态成员的赋值语句以及static语句块合并产生的。

说明
在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的总是在子类之前被调用。也就是说，父类的static块优先级高于子类。
口诀：由父及子，静态先行。
Java编译器并不会为所有的类都产生<clinit>()初始化方法。哪些类在编译为字节码后，字节码文件中将不会包含<clinit>()方法?

一个类中并没有声明任何的类变量，也没有静态代码块时
一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时
一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式

4.1 static 和 final 搭配的问题

最终结论：使用static + final修饰，且显示赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显式赋值，是在链接阶段的准备环节进行。

 

/**
 * @author shkstart
 * @create 2020-09-14 18:55
 *
 * 说明：使用static + final修饰的字段的显式赋值的操作，到底是在哪个阶段进行的赋值？
 * 情况1：在链接阶段的准备环节赋值
 * 情况2：在初始化阶段<clinit>()中赋值
 *
 * 结论：
 * 在链接阶段的准备环节赋值的情况：
 * 1. 对于基本数据类型的字段来说，如果使用static final修饰，则显式赋值(直接赋值常量，而非调用方法）通常是在链接阶段的准备环节进行
 * 2. 对于String来说，如果使用字面量的方式赋值，使用static final修饰的话，则显式赋值通常是在链接阶段的准备环节进行
 *
 * 在初始化阶段<clinit>()中赋值的情况：
 * 排除上述的在准备环节赋值的情况之外的情况。
 *
 * 最终结论：使用static + final修饰，且显示赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显式赋值，是在链接阶段的准备环节进行。
 */
public class InitializationTest2 {
    public static int a = 1;//在初始化阶段<clinit>()中赋值
    public static final int INT_CONSTANT = 10;//在链接阶段的准备环节赋值

    public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100);//在初始化阶段<clinit>()中赋值
    public static Integer INTEGER_CONSTANT2 = Integer.valueOf(1000);//在初始化阶段<clinit>()中赋值

    public static final String s0 = "helloworld0";//在链接阶段的准备环节赋值
    public static final String s1 = new String("helloworld1");//在初始化阶段<clinit>()中赋值

    public static String s2 = "helloworld2";

    public static final int NUM1 = new Random().nextInt(10);//在初始化阶段<clinit>()中赋值
}

4.2 <clinit>()的线程安全性

对于<clinit>()方法的调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性。
虚拟机会保证一个类的()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行()方法完毕。
正是因为函数()带锁线程安全的，因此，如果在一个类的()方法中有耗时很长的操作，就可能造成多个线程阻塞，引发死锁。并且这种死锁是很难发现的，因为看起来它们并没有可用的锁信息。

如果之前的线程成功加载了类，则等在队列中的线程就没有机会再执行<clinit>()方法了。那么，当需要使用这个类时，虚拟机会直接返回给它已经准备好的信息。

4.3 类的初始化情况：主动使用vs被动使用

Java程序对类的使用分为两种:主动使用和被动使用。

主动使用:
Class只有在必须要首次使用的时候才会被装载，Java虚拟机不会无条件地装载Class类型。Java虚拟机规定，一个类或接口在初次使用前，必须要进行初始化。这里指的“使用”，是指主动使用，主动使用只有下列几种情况:
(即:如果出现如下的情况，则会对类进行初始化操作。而初始化操作之前的加载、验证、准备已经完成。)
1)当创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化。
2)当调用类的静态方法时，即当使用了字节码invokestatic指令。
3)当使用类、接口的静态字段时(final修饰特殊考虑)， 比如，使用getstatic或者putstatic指令。 (对应访问变量、赋值变量操作)
4)当使用java.lang. reflect包中的方法反射类的方法时。比如: Class. forName(" com. atguigu. java. Test")
5)当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
6)如果一个接口定义了default方法， 那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化。
7)当虚拟机启动时，用户需要指定一个要执行的主类(包含main()方法的那个类)，虚拟机会先初始化这个主类。
8)当初次调用MethodHandle 实例时，初始化该MethodHandle 指向的方法所在的类。 (涉及解析REF_ getStatic、 REF_ putStatic、 REF _invokeStatic方法句柄对应的类)

针对5补充说明:
当Java虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则并不适用于接口。>在初始化一个类时，并不会先初始化它所实现的接口
在初始化一个接口时，并不会先初始化它的父接口
因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。

针对7说明:
JVN启动的时候通过引导类加载器加载一个初始类。这个类在调用public static void main(String[])方法之前被链接和初始化。这个方法的执行将依次导致所需的类的加载，链接和初始化。

被动使用:
除了以上的情况属于主动使用，其他的情况均属于被动使用。被动使用不会引起类的初始化。
也就是说:并不是在代码中出现的类，就一定会被加载或者初始化。如果不符合主动使用的条件，类就不会初始化。
1)当访问一个静态字段时，只有真正声明这个字段的类才会被初始化。当通过子类引用父类的静态空量，不会导致子类初始化
2)通过数组定义类引用，不会触发此类的初始化
3)引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了
4)调用ClassLoader类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化。

5. 类的Using(使用)

任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类型成功经历过这3个步骤之后，便“万事俱备，只欠东风”，就等着开发者使用了。
开发人员可以在程序中访问和调用它的静态类成员信息（比如:静态字段、静态方法），或者使用new关键字为其创建对象实例。

6. 类的Unloading（卸载）

6.1 类、类的加载器、类的实例之间的引用关系

在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。
一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。

6.2 类的生命周期

当Sample类被加载、链接和初始化后，它的生命周期就开始了。当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区内的数据也会被卸载，从而结束Sample类的生命周期。
一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。

loader1变量和obj变量间接应用代表Sample类的Class对象，而objClass变量则直接引用它。

如果程序运行过程中，将上图左侧三个引用变量都置为null，此时Sample对象结束生命周期，MyClassLoader对象结束生命周期，代表Sample类的Class对象也结束生命周期，Sample类在方法区内的二进制数据被卸载。
当再次有需要时，会检查Sample类的Class对象是否存在，如果存在会直接使用，不再重新加载;如果不存在Sample类会被重新加载，在Java虚拟机的堆区会生成一个新的代表Sample类的Class实例(可以通过哈希码查看是否是同一个实例)。

6.3 方法区的垃圾回收

方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不再使用的类型。

HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。
判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件:
该类所有的实例都已经被回收。也就是Java堆中不存在该类及其任何派生子类的实例。
加载该类的类加载器已经被回收。这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、3SP的重加载等，否则通常是很难达成的。
该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。

6.4 类的卸载

1）启动类加载器加载的类型在整个运行期间是不可能被卸载的(jvm和jls规范)
2）被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到unreachable的可能性极小。
(3）被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中(比如:很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能)，被加载的类型在运行期间也是几乎不太可能被卸载的(至少卸载的时间是不确定的)。
综合以上三点，一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。
同时我们可以看的出来，开发者在开发代码时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能。

 

四.类的加载器

1. 概述

 

类加载器是JVM执行类加载机制的前提。

ClassLoader的作用:
ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进仃加软的，ClassLOader负责将Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader去改变类的链接和初始化行为。至于它是否可以运行，则由Execution Engine决定。

  

类加载器最早出现在Java1.0版本中，那个时候只是单纯地为了满足Java Applet应用而被研发出来。但如今类加载器却在oSGi、字节码加解密领域大放异彩。这主要归功于Java虚拟机的设计者们当初在设计类加载器的时候，并没有考虑将它绑定在JVM内部，这样做的好处就是能够更加灵活和动态地执行类加载操作。

1.1 大厂面试题

深入分析classLoader，双亲委派机制类加载器的双亲委派模型是什么?
双亲委派机制及使用原因
都有哪些类加载器，这些类加载器都加载哪些文件?手写一个类加载器Demo
Class的forName(“java .lang.String”)和Class的getClassLoader()的loadClass(“java.lang.String”)有什么区别?
什么是双亲委派模型?类加载器有哪些?
双亲委派模型介绍一下
简单说说你了解的类加载器
讲一下双亲委派模型，以及其优点
什么是类加载器，类加载器有哪些?
类加载器的双亲委派模型是什么?双亲委派机制可以打破吗?为什么

1.2 类加载的分类

类的加载分类:显式加载vs隐式加载
class文件的显式加载与隐式加载的方式是指JVM加载class文件到内存的方式。

显式加载指的 是在代码中通过调用ClassLoader加载class对象，
如直接使用Class.forName( name)或this. getClass(). getClassLoader(). loadClass()加载class对象。
隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象，而是通过虚拟机自动加载到内存中，如在
加载某个类的class文件时，该类的class 文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载
到内存中。

在日常开发以上两种方式一般会混合使用。

1.3 类加载器的必要性

一般情况下，Java开发人员并不需要在程序中显式地使用类加载器，但是了解类加载器的加载机制却显得至关重要。从以下几个方面说:
避免在开发中遇到 java.lang.ClassNotFoundException异常或java.lang.NoClassDefFoundError异常时，手足无措。只有了解类加载器的加载机制才能够在出现异常的时候快速地根据错误异常日志定位问题和解决问题
需要支持类的动态加载或需要对编译后的字节码文件进行加解密操作时，就需要与类加载器打交道了。
开发人员可以在程序中编写自定义类加载器来重新定义类的加载规则，以便实现一些自定义的处理逻辑。

1.4 命名空间

1)何为类的唯一性?
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器，都拥有一个独立的类名称空间:比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等。

2)命名空间
每个类加载器都有自己的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成·在同一命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类
在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类

在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本。

1.5 类加载机制的基本特征

通常类加载机制有三个基本特征:

双亲委派模型。但不是所有类加载都遵守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如DK内部的ServiceProvider/ServiceLoader机制，用户可以在标准API框架上，提供自己的实现，JDK也需要提供些默认的参考实现。例如，Java中JNDI、JDBC、文件系统、Cipher等很多方面，都是利用的这种机制，这种情况就不会用双亲委派模型去加载，而是利用所谓的上下文加载器。
可见性，子类加载器可以访问父加载器加载的类型，但是反过来是不允许的。不然因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑。
单一性，由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载。但是注意，类加载器“邻居”间，同一类型仍然可以被加载多次，因为互相并不可见。

2. 类的加载器分类

2.1 引导类加载器

JVM支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。
从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分，在程序中我们最常见的类加载器结构主要是如下情况:

 

除了顶层的启动类加载器外，其余的类加载器都应当有自己的“父类”加载器。
不同类加载器看似是继承(Inheritance）关系，实际上是包含关系。在下层加载器中，包含着上层加载器的引用

 

 

 

 

启动类加载器（引导类加载器，Bootstrap classLoader)
这个类加载使用C/C++语言实现的，嵌套在VM内部。
它用来加载Java的核心库（JAVA_HONE/jre/lib/rt.jar或sun.boot.class.path路径下的内容）。用于提供JVM自身需要的类。
并不继承自java.lang.classLoader，没有父加载器。
出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类，加载扩展类和应用程序类加载器，并指定为他们的父类加载器。

使用-XX:+TraceClassLoading参数得到。
启动类加载器使用C++编写的?Yes !
C/C++:指针函数&函数指针、C++支持多继承、更加高效
Java:由C++演变而来，(C非)–版，单继承

2.2 扩展类加载器

扩展类加载器（Extension ClassLoader）
Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。
继承于classLoader类
父类加载器为启动类加载器
从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。

 

public class ClassLoaderTest {
    public static void main(String[] args) {
        System.out.println("**********启动类加载器**************");
        //获取BootstrapClassLoader能够加载的api的路径
        URL[] urLs = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL element : urLs) {
            System.out.println(element.toExternalForm());
        }
        //从上面的路径中随意选择一个类,来看看他的类加载器是什么:引导类加载器
        ClassLoader classLoader = java.security.Provider.class.getClassLoader();
        System.out.println(classLoader);//null

        System.out.println("***********扩展类加载器*************");
        String extDirs = System.getProperty("java.ext.dirs");
        for (String path : extDirs.split(";")) {
            System.out.println(path);
        }
//
//        //从上面的路径中随意选择一个类,来看看他的类加载器是什么:扩展类加载器
        ClassLoader classLoader1 = sun.security.ec.CurveDB.class.getClassLoader();
        System.out.println(classLoader1);//sun.misc.Launcher$ExtClassLoader@1540e19d

    }
}

BootstrapClassLoader能够加载的api的路径：

 

扩展类加载器能够加载的api的路径

 

2.3 系统类加载器

应用程序类加载器（系统类加载器，AppClassLoader)
java语言编写，由sun.misc.Launcher$AppClassLoader实现·继承于classLoader类
父类加载器为扩展类加载器
它负责加载环境变量classpath或系统属性 java.class.path指定路径下的类库
应用程序中的类加载器默认是系统类加载器。
它是用户自定义类加载器的默认父加载器
通过classLoader的getSystemClassLoader()方法可以获取到该类加载器

 

2.4 用户自定义类加载器

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

体现Java语言强大生命力和巨大魅力的关键因素之一便是,Java开发者可以自定义类加载器来实现类库的动态加载，加载源可以是本地的JAR包，也可以是网络上的远程资源。

通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGT组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现。

同时，自定义加载器能够实现应用隔离，例如Tomcat，Spring等中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C++程序要好太多想不修改C/C++程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想。

自定义类加载器通常需要继承于classLoader。

3. 测试不同的类的加载器

每个class对象都会包含一个定义它的classLoader的一个引用。

获取ClassLoader的途径

获得当前类的ClassLoader clazz.getclassLoader()
获得当前线程上下文的ClassLoader Thread.currentThread().getContextclassLoader()
获得系统的ClassLoader ClassLoader.getSystemClassLoader()

说明:
站在程序的角度看，引导类加载器与另外两种类加载器（系统类加载器和扩展类加载器）并不是同一个层次意义上的加载器，引导类加载器是使用C++语言编写而成的，而另外两种类加载器则是使用Java语言编写而成的。由于引导类加载器压根儿就不是一个Java类，因此在Java程序中只能打印出空值。

数组类的Class对象，不是由类加载器去创建的，而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说，是通过class.getclassLoader()返回的，与数组当中元素类型的类加载器是一样的;如果数组当中的元素类型是基本数据类型，数组类是没有类加载器的。

public class ClassLoaderTest1 {
    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

        //###########################
        try {
            ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
            System.out.println(classLoader);
            //自定义的类默认使用系统类加载器
            ClassLoader classLoader1 = Class.forName("com.atguigu.java.ClassLoaderTest1").getClassLoader();
            System.out.println(classLoader1);

            //关于数组类型的加载:使用的类的加载器与数组元素的类的加载器相同
            String[] arrStr = new String[10];
            System.out.println(arrStr.getClass().getClassLoader());//null:表示使用的是引导类加载器

            ClassLoaderTest1[] arr1 = new ClassLoaderTest1[10];
            System.out.println(arr1.getClass().getClassLoader());//sun.misc.Launcher$AppClassLoader@18b4aac2

            int[] arr2 = new int[10];
            System.out.println(arr2.getClass().getClassLoader());//null:不需要类的加载器


            System.out.println(Thread.currentThread().getContextClassLoader());
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

4. ClassLoader源码解析

ClassLoader与现有类加载器的关系：

 

除了以上虚拟机自带的加载器外，用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

4.1 ClassLoader的主要方法

抽象类ClassLoader的主要方法:(内部没有抽象方法)：

public final classLoader getParent()
返回该类加载器的超类加载器

public class<?> loadclass(string name) throws ClassNotFoundException
加载名称为name的类，返回结果为java.lang.Class类的实例。如果找不到类，则返回ClassNotFoundException异常。该方法中的逻辑就是双亲委派模式的实现。

protected class<?> findclass(String name) throws ClassNotFoundException
查找二进制名称为name的类，返回结果为java.lang.Class类的实例。这是一个受保护的方法，JVM鼓励我们重写此方法，需要自定义加载器遵循双亲委托机制，该方法会在检查完父类加载器之后被loadClass()方法调用。

在JDK1.2之前，在自定义类加载时，总会去继承ClassLoader类并重写loadClass方法，从而实现自定义的类加载类。但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findClass()方法中，从前面的分析可知，findClass()方法是在loadClass()方法中被调用的，当loadClass()方法中父加载器加载失败后，则会调用自己的findClass()方法来完成类加载，这样就可以保证自定义的类加载器也符合双亲委托模式。

需要注意的是ClassLoader类中并没有实现findClass()方法的具体代码逻辑，取而代之的是抛出ClassNotFoundException异常，同时应该知道的是findClass方法通常是和defineClass方法一起使用的。一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的FindClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass()方法生成类的Class对象。

protected final Class?> defineclass(String name, byte[] b, int off， int len)
根据给定的字节数组b转换为Class的实例，off和len参数表示实际Class信息在byte数组中的位置和长度，其中byte数组b是ClassLoader从外部获取的。这是受保护的方法，只有在自定义ClassLoader子类中可以使用。
defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象(ClassLoader中己实现该方法逻辑)，通过这个方法不仅能够通过class文件实例化class对象，也可以通过其他方式实例化class对象，如通过网络接收一个类的字节码，然后转换为byte字节流创建对应的Class对象。

defineClass()方法通常与findClass()方法一起使用，一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass()方法生成类的Class对象。

protected final void resolveclass(class<?>c)
链接指定的一个Java类。使用该方法可以使用类的Class对象创建完成的同时也被解析。前面我们说链接阶段主要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。

protected final class<?> fihdLoadedclass(String name)
查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例。这个方法是final方法，无法被修改。

private final classLoader parent;
它也是一个ClassLoader的实例，这个字段所表示的ClassLoader也称为这个ClassLoader的双亲。在类加载的过程中,classLoader可能会将某些请求交予自己的双亲处理。

4.2 SecureClassLoader 与URLClassLoader

SecureClassLoader扩展了ClassLoader，新增了几个与使用相关的代码源(对代码源的位置及其证书的验证)和权限定义类验证(主要指对class源码的访问权限)的方法，一般我们不会直接跟这个类打交道，更多是与它的子类URLClassLoader有所关联。

前面说过，ClassLoader是一个抽象类，很多方法是空的没有实现，比如 findClass()、findResource()等。而URLClassLoader这个实现类为这些方法提供了具体的实现。并新增了URLClassPath类协助取得Class字节码流等功能。在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

 

4.3 ExtClassLoader 与AppClassLoader

 了解完URLClassLoader后接着看看剩余的两个类加载器，即拓展类加载器ExtClassLoader和系统类加载器AppClassLoader，这两个类都继承自URLClassLoader，是sun.misc.Launcher的静态内部类。

sun.misc.Launcher主要被系统用于启动主应用程序，ExtClassLoader和AppClassLoader都是由lsun.misc.Launcher创建的，其类主要类结构如下:

 我们发现ExtClassLoader并没有重写loadClass()方法，这足矣说明其遵循双亲委派模式，而AppClassLoader重载了loadClass()方法，但最终调用的还是父类loadClass()方法，因此依然遵守双亲委派模式。

4.4 Class.forName()与ClassLoader. loadclass()

Class.forName():是一个静态方法,最常用的是Class.forName(String className);根据传入的类的全限定名返回一个Class对象。该方法在将Class 文件加载到内存的同时,会执行类的初始化。如:Class.forName( “com.atguigu.java.Hellowor1” );

ClassLoader.loadClass():这是一个实例方法,需要一个ClassLoader对象来调用该方法。该方法将Class 文件加载到内存时,并不会执行类的初始化,直到这个类第一次使用时才进行初始化。该方法因为需要得到一个ClassLoader对象,所以可以根据需要指定使用哪个类加载器。如:ClassLoader cl=… .; cl.loadClass( “com.atguigu.java.Helloworld” );

5. 双亲委派模型

5.1 定义与本质

类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。

1）定义
如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。

2）本质
规定了类加载的顺序是:引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

5.2 优势与劣势

5.2.1 双亲委派机制优势

避免类的重复加载，确保一个类的全局唯一性。
Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子classLoader再加载一次。
保护程序安全，防止核心API被随意篡改。

5.2.2 代码支持

双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)接口中体现。该接口的逻辑如下:
1)先在当前加载器的缓存中查找有无目标类，如果有，直接返回。
2)判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name，false)接口进行加载。
3)反之，如果当前加载器的父类加载器为空，则调用findBootstrapClassOrNull(name)接口，让引导类加载器进行加载。
4)如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载。
该接口最终会调用java.lang.classLoader接口的defineClass系列的native接口加载目标Java类
双亲委派的模型就隐藏在这第2和第3步中。

5.2.3 举例

假设当前加载的是java.lang.Object这个类，很显然，该类属于JDK中核心得不能再核心的一个类，因此一定只能由引导类加载器进行加载。当JVM准备加载javaJang.0bject时，JVM默认会使用系统类加载器去加载，按照上面4步加载的逻辑，在第1步从系统类的缓存中肯定查找不到该类，于是进入第2步。由于从系统类加载器的父加载器是扩展类加载器，于是扩展类加载器继续从第1步开始重复。由于扩展类加载器的缓存中也一定查找不到该类，因此进入第2步。扩展类的父加载器是null,因此系统调用findClass(String)，最终通过引导类加载器进行加载。

5.2.4 思考

如果在自定义的类加载器中重写java.lang.classLoader.loadClass(string)或
java.lang.ClassLoader.loadClass(String, boolean)方法,抹去其中的双亲委派机制,仅保留上面这4步中的第1步与第4步，那么是不是就能够加载核心类库了呢?
这也不行! 因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器抑或扩展类加载器，最终都必须调用java.lang.ClassLoader.defineClass(String， byte[], int, int,
ProtectionDomain)方法，而该方法会执行preDefineClass()接口，该接口中提供了对JDK核心类库的保护。

5.2.5 双亲委托模式的弊端

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

5.2.6 结论

由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

5.3 破坏双亲委派机制

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。

在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。 

第一次破坏双亲委派机制:
双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前：即JDK 1面世以前的“远古”时代。

由于双亲委派模型在JDK1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。

上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

第二次破坏双亲委派机制:线程上下文类加载器
双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢?

这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK1.3时加入到rt.jar的)，肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI)的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办?(SPI:在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI)

为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计:线程上下文类加载器（Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和BI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。

 

默认上下文加载器就是应用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用类加载器中的类。

第三次破坏双亲委派机制:
双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如:代码热替换（Hot Swap）、模块热部署（Hot Deployment）等IBM公司主导的SR-291(即oSGi R4.2）实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。

当收到类加载请求时，OSGi将按照下面的顺序进行类搜索:
1）将以java.*开头的类，委派给父类加载器加载。
2）否则，将委派列表名单内的类，委派给父类加载器加载。
3）否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。
4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载
6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载
7）否则，类查找失败。
说明:只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的

小结:
这里，我们使用了“被破坏”这个词来形容上述不符合双亲委派模型原则的行为，但这里“被破坏”并不一定是带有贬义的。只要有明确的目的和充分的理由，突破旧有原则无疑是一种创新。

正如OSGi中的类加载器的设计不符合传统的双亲委派的类加载器架构，且业界对其为了实现热部署而带来的额外的高复杂度还存在不少争议，对这方面有了解的技术人员基本还是能达成一个共识，认为OSGi中对类加载器的运用是值得学习的，完全弄懂了OSGi的实现，就算是掌握了类加载器的精粹。

5.4 热替换的实现

热替换是指在程序的运行过程中，不停止服务，只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断，修改必须立即表现正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的，比如: PHP，只要替换了PHP源文件，这种改动就会立即生效，而无需重启web服务器。

但对Java来说，热替换并非天生就支持，如果一个类已经加载到系统中，通过修改类文件，并无法让系统再来加载并重定义这个类。因此，在Java中实现这一功能的一个可行的方法就是灵活运用ClassLoader。

注意:由不同ClassLoader加载的同名类属于不同的类型，不能相互转换和兼容。即两个不同的ClassLoader加载同一个类，在虚拟机内部，会认为这2个类是完全不同的。根据这个特点，可以用来模拟热替换的实现，基本思路如下图所示:

 

6. 沙箱安全机制

沙箱安全机制·保证程序安全
保护ava原生的JDK代码
Java安全模型的核心就是Java沙箱(sandbox)。什么是沙箱?沙箱是一个限制程序运行的环境。
沙箱机制就是将Java代码限定在虚拟机（JVM)特定的运行范围中，并且严格限制代码对本地系统资源访问。通过这样的措施来保证对代码的有限隔离，防止对本地系统造成破坏。
沙箱主要限制系统资源访问，那系统资源包括什么? CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。

所有的Java程序运行都可以指定沙箱，可以定制安全策略。

在Java1.2版本中，再次改进了安全机制，增加了代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。如下图所示JDK1.2安全模型:

 

7. 自定义类的加载器

7.1 概述

1）为什么要自定义类加载器?

隔离加载类：
在某些框架内进行中间任与应用的模块隔离，把类加载到不同的环境。比如:阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如:Tomcat这类Web应用服务器，内部自定义了好几种类加载器，用于隔离同一个web应用服务器上的不同应用程序。

修改类加载的方式：
类的加载模型并非强制，除Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载。

扩展加载源：
比如从数据库、网络、甚至是电视机机顶盒进行加载。

防止源码泄漏：
Java代码容易被编译和篡改，可以进行编译加密。那么类加载也需要自定义，还原加密的字节码。

2）常见的场景
实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面的集大成者是Java EE和OSGI、JPMS等框架。

应用需要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统。

或者是需要自己操纵字节码，动态修改或者生成类型。

3）注意:
在一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。但是，如果涉及Java类型转换，则加载器反而容易产生不美好的事情。在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能进行类型转换，否则转换时会发生异常。

7.2 实现方式

用户通过定制自己的类加载器，这样可以重新定义类的加载规则，以便实现一些自定义的处理逻辑。
1）实现方式
Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。·在自定义ClassLoader 的子类时候，我们常见的会有两种做法:
方式一:重写loadclass()方法
方式二:重写findClass()方法

2）对比
这两种方法本质上差不多，毕竟loadClass()也会调用findClass()，但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。建议的做法是只在findClass()里重写自定义类的加载方法，根据参数指定类的名字，返回对应的Class对象的引用。
loadClass()这个方法是实现双亲委派模型逻辑的地方，擅自修改这个方法会导致模型被破坏，容易造成问题。因此我们最好是在双亲委派模型框架内进行小范围的改动，不破坏原有的稳定结构。同时，也避免了自己重写loadClass()方法的过程中必须写双亲委托的重复代码，从代码的复用性来看，不直接修改这个方法始终是比较好的选择。
当编写好自定义类加载器后，便可以在程序中调用loadClass(）方法来实现类加载操作。

3）说明
其父类加载器是系统类加载器
JVN中的所有类加载都会使用java.lang.ClassLoader.loadClass(String)接口(自定义类加载器并重写
java.lang.ClassLoader.loadClass(String)接口的除外)，连JDK的核心类库也不能例外。

public class MyClassLoaderTest {
    public static void main(String[] args) {
        MyClassLoader loader = new MyClassLoader("d:/");

        try {
            Class clazz = loader.loadClass("Demo1");
            System.out.println("加载此类的类的加载器为：" + clazz.getClassLoader().getClass().getName());

            System.out.println("加载当前Demo1类的类的加载器的父类加载器为：" + clazz.getClassLoader().getParent().getClass().getName());
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

public class MyClassLoader extends ClassLoader {
    private String byteCodePath;

    public MyClassLoader(String byteCodePath) {
        this.byteCodePath = byteCodePath;
    }

    public MyClassLoader(ClassLoader parent, String byteCodePath) {
        super(parent);
        this.byteCodePath = byteCodePath;
    }

    @Override
    protected Class<?> findClass(String className) throws ClassNotFoundException {
        BufferedInputStream bis = null;
        ByteArrayOutputStream baos = null;
        try {
            //获取字节码文件的完整路径
            String fileName = byteCodePath + className + ".class";
            //获取一个输入流
            bis = new BufferedInputStream(new FileInputStream(fileName));
            //获取一个输出流
            baos = new ByteArrayOutputStream();
            //具体读入数据并写出的过程
            int len;
            byte[] data = new byte[1024];
            while ((len = bis.read(data)) != -1) {
                baos.write(data, 0, len);
            }
            //获取内存中的完整的字节数组的数据
            byte[] byteCodes = baos.toByteArray();
            //调用defineClass()，将字节数组的数据转换为Class的实例。
            Class clazz = defineClass(null, byteCodes, 0, byteCodes.length);
            return clazz;
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            try {
                if (baos != null)
                    baos.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
            try {
                if (bis != null)
                    bis.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

        return null;


    }
}

8. Java9新特性

为了保证兼容性，JDK9没有从根本上改变三层类加载器架构和双亲委派模型，但为了模块化系统的顺利运行，仍然发生了一些值得被注意的变动。

1）扩展机制被移除，扩展类加载器由于向后兼容性的原因被保留，不过被重命名为平台类加载器(platform classloader）。可以通过classLoader的新方法getPlatformClassLoader()来获取。

JDK9是基于模块化进行构建（原来的rt.jar和 tools.jar被拆分成数十个JMOD文件），
其中的Java类库就已天然地满足了可扩展的需求，那自然无须再保留〈JAVA_HOME>\liblext目录，此前使用这个目录或者 java.ext.dirs系统变量来扩展JDK功能的机制已经没有继续存在的价值了。

2）平台类加载器和应用程序类加载器都不再继承自java.net.URLClassLoader。
现在启动类加载器、平台类加载器、应用程序类加载器全都继承于jdk.internal.loader.BuiltinClassLoader。

如果有程序直接依赖了这种继承关系，或者依赖了URLClassLoader类的特定方法，那代码很可能会在JDK 9及更高版本的JDK中崩溃。

 

3）在Java 9中，类加载器有了名称。该名称在构造方法中指定，可以通过getName()方法来获取。平台类加载器的名称是platform，应用类加载器的名称是app。类加载器的名称在调试与类加载器相关的问题时会非常有用。

4）启动类加载器现在是在jvm内部和java类库共同协作实现的类加载器（以前是C++实现)，但为了与之前代码兼容，在获取启动类加载器的场景中仍然会返回null，而不会得到BootClassLoader实例。

5）类加载的委派关系也发生了变动。
当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。

 

 

 

 

 

public class ClassLoaderTest {
    public static void main(String[] args) {
        System.out.println(ClassLoaderTest.class.getClassLoader());
        System.out.println(ClassLoaderTest.class.getClassLoader().getParent());
        System.out.println(ClassLoaderTest.class.getClassLoader().getParent().getParent());
 
        //获取系统类加载器
        System.out.println(ClassLoader.getSystemClassLoader());
        //获取平台类加载器
        System.out.println(ClassLoader.getPlatformClassLoader());
        //获取类的加载器的名称
        System.out.println(ClassLoaderTest.class.getClassLoader().getName());
    }
}