一. 类文件结构

1.1 概述

在 Java 中，JVM 可以理解的代码就叫做字节码（即扩展名为 .class 的文件），它不面向任何特定的处理器，只面向虚拟机。Java 语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以 Java 程序运行时比较高效，而且，由于字节码并不针对一种特定的机器，因此，Java 程序无须重新编译便可在多种不同操作系统的计算机上运行。
image.png
可以说.class文件是不同的语言在 Java 虚拟机之间的重要桥梁，同时也是支持 Java 跨平台很重要的一个原因。

1.2 类文件结构总结

根据 Java 虚拟机规范，Class 文件通过 ClassFile 定义，有点类似 C 语言的结构体。
ClassFile 的结构如下：

  1. ClassFile {
  2.     u4             magic; //Class 文件的标志
  3.     u2             minor_version;//Class 的小版本号
  4.     u2             major_version;//Class 的大版本号
  5.     u2             constant_pool_count;//常量池的数量
  6.     cp_info        constant_pool[constant_pool_count-1];//常量池
  7.     u2             access_flags;//Class 的访问标记
  8.     u2             this_class;//当前类
  9.     u2             super_class;//父类
  10.     u2             interfaces_count;//接口
  11.     u2             interfaces[interfaces_count];//一个类可以实现多个接口
  12.     u2             fields_count;//Class 文件的字段属性
  13.     field_info     fields[fields_count];//一个类会可以有多个字段
  14.     u2             methods_count;//Class 文件的方法数量
  15.     method_info    methods[methods_count];//一个类可以有个多个方法
  16.     u2             attributes_count;//此类的属性表中的属性数
  17.     attribute_info attributes[attributes_count];//属性表集合
  18. }

通过分析 ClassFile 的内容，我们便可以知道 class 文件的组成。
image.png

1.3 详解

1.3.1 魔数(Magic Number)

  1.     u4             magic; //Class 文件的标志

每个 Class 文件的头 4 个字节称为魔数（Magic Number）,它的唯一作用是确定这个文件是否为一个能被虚拟机接收的 Class 文件。
程序设计者很多时候都喜欢用一些特殊的数字表示固定的文件类型或者其它特殊的含义。

1.3.2 Class文件版本号(Minor&Major Version)

  1.     u2             minor_version;//Class 的小版本号
  2.     u2             major_version;//Class 的大版本号

紧接着魔数的四个字节存储的是 Class 文件的版本号：第 5 和第 6 位是次版本号，第 7 和第 8 位是主版本号。
每当 Java 发布大版本（比如 Java 8，Java9）的时候，主版本号都会加 1。你可以使用 javap -v 命令来快速查看 Class 文件的版本号信息。
高版本的 Java 虚拟机可以执行低版本编译器生成的 Class 文件，但是低版本的 Java 虚拟机不能执行高版本编译器生成的 Class 文件。所以，我们在实际开发的时候要确保开发的的 JDK 版本和生产环境的 JDK 版本保持一致。

1.3.3 常量池(Constant Pool)

  1.     u2             constant_pool_count;//常量池的数量
  2.     cp_info        constant_pool[constant_pool_count-1];//常量池

紧接着主次版本号之后的是常量池，常量池的数量是 constant_pool_count-1（常量池计数器是从 1 开始计数的，将第 0 项常量空出来是有特殊考虑的，索引值为 0 代表“不引用任何一个常量池项”）。
常量池主要存放两大常量：字面量和符号引用。字面量比较接近于 Java 语言层面的的常量概念，如文本字符串、声明为 final 的常量值等。而符号引用则属于编译原理方面的概念。包括下面三类常量：

  • 类和接口的全限定名
  • 字段的名称和描述符
  • 方法的名称和描述符

常量池中每一项常量都是一个表，这 14 种表有一个共同的特点：开始的第一位是一个 u1 类型的标志位 -tag 来标识常量的类型，代表当前这个常量属于哪种常量类型．

类型 标志（tag） 描述
CONSTANT_utf8_info 1 UTF-8 编码的字符串
CONSTANT_Integer_info 3 整形字面量
CONSTANT_Float_info 4 浮点型字面量
CONSTANT_Long_info ５ 长整型字面量
CONSTANT_Double_info ６ 双精度浮点型字面量
CONSTANT_Class_info ７ 类或接口的符号引用
CONSTANT_String_info ８ 字符串类型字面量
CONSTANT_Fieldref_info ９ 字段的符号引用
CONSTANT_Methodref_info 10 类中方法的符号引用
CONSTANT_InterfaceMethodref_info 11 接口中方法的符号引用
CONSTANT_NameAndType_info 12 字段或方法的符号引用
CONSTANT_MothodType_info 16 标志方法类型
CONSTANT_MethodHandle_info 15 表示方法句柄
CONSTANT_InvokeDynamic_info 18 表示一个动态方法调用点

.class 文件可以通过javap -v class类名 指令来看一下其常量池中的信息(javap -v class类名-> temp.txt ：将结果输出到 temp.txt 文件)

1.3.4 访问控制（Access Flags）

在常量池结束之后，紧接着的两个字节代表访问标志，这个标志用于识别一些类或者接口层次的访问信息，包括：这个 Class 是类还是接口，是否为 public 或者 abstract 类型，如果是类的话是否声明为 final 等等。
类访问和属性修饰符:
image.png
我们定义了一个 Employee 类
通过javap -v class类名 指令看一下类的访问标志
image.png

1.3.5 当前类（This Class）、父类（Super Class）、接口（Interfaces）索引集合

  1.     u2             this_class;//当前类
  2.     u2             super_class;//父类
  3.     u2             interfaces_count;//接口
  4.     u2             interfaces[interfaces_count];//一个类可以实现多个接口

类索引用于确定这个类的全限定名，父类索引用于确定这个类的父类的全限定名，由于 Java 语言的单继承，所以父类索引只有一个，除了 java.lang.Object 之外，所有的 java 类都有父类，因此除了 java.lang.Object 外，所有 Java 类的父类索引都不为 0。
接口索引集合用来描述这个类实现了那些接口，这些被实现的接口将按 implements (如果这个类本身是接口的话则是extends) 后的接口顺序从左到右排列在接口索引集合中。

1.3.6 字段表集合(Fields)

  1.     u2             fields_count;//Class 文件的字段属性
  2.     field_info     fields[fields_count];//一个类会可以有多个字段

字段表（field info）用于描述接口或类中声明的变量。字段包括类级变量以及实例变量，但不包括在方法内部声明的局部变量。
image.png

  • access_flags: 字段的作用域（public ,private,protected修饰符），是实例变量还是类变量（static修饰符）,可否被序列化（transient 修饰符）,可变性（final）,可见性（volatile 修饰符，是否强制从主内存读写）。
  • name_index: 对常量池的引用，表示的字段的名称；
  • descriptor_index: 对常量池的引用，表示字段和方法的描述符；
  • attributes_count: 一个字段还会拥有一些额外的属性，attributes_count 存放属性的个数；
  • attributes[attributes_count]: 存放具体属性具体内容。

上述这些信息中，各个修饰符都是布尔值，要么有某个修饰符，要么没有，很适合使用标志位来表示。而字段叫什么名字、字段被定义为什么数据类型这些都是无法固定的，只能引用常量池中常量来描述。

字段的 access_flag 的取值:
image.png

1.3.7 方法表集合(Methods)

  1.     u2             methods_count;//Class 文件的方法数量
  2.     method_info    methods[methods_count];//一个类可以有个多个方法

methods_count 表示方法的数量，而 method_info 表示方法表。
Class 文件存储格式中对方法的描述与对字段的描述几乎采用了完全一致的方式。方法表的结构如同字段表一样，依次包括了访问标志、名称索引、描述符索引、属性表集合几项。
image.png

方法表的 access_flag 取值：
image.png
注意：因为volatile修饰符和transient修饰符不可以修饰方法，所以方法表的访问标志中没有这两个对应的标志，但是增加了synchronized、native、abstract等关键字修饰方法，所以也就多了这些关键字对应的标志。

1.3.8 属性表集合（Attributes）

  1.     u2             attributes_count;//此类的属性表中的属性数
  2.     attribute_info attributes[attributes_count];//属性表集合

在 Class 文件，字段表，方法表中都可以携带自己的属性表集合，以用于描述某些场景专有的信息。与 Class 文件中其它的数据项目要求的顺序、长度和内容不同，属性表集合的限制稍微宽松一些，不再要求各个属性表具有严格的顺序，并且只要不与已有的属性名重复，任何人实现的编译器都可以向属性表中写 入自己定义的属性信息，Java 虚拟机运行时会忽略掉它不认识的属性。

二. 类加载过程详解

2.1 类的声明周期

类的声明周期如下
image.png

2.2 类加载过程

Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？
系统加载 Class 类型的文件主要三步：加载->连接->初始化。连接过程又可分为三步：验证->准备->解析。
image.png

2.2.1 加载

类加载过程的第一步，主要完成下面 3 件事情：

  1. 通过全类名获取定义此类的二进制字节流
  2. 将字节流所代表的静态存储结构转换为方法区的运行时数据结构
  3. 在内存中生成一个代表该类的 Class 对象，作为方法区这些数据的访问入口

虚拟机规范上面这 3 点并不具体，因此是非常灵活的。比如：”通过全类名获取定义此类的二进制字节流” 并没有指明具体从哪里获取、怎样获取。比如：比较常见的就是从 ZIP 包中读取（日后出现的 JAR、EAR、WAR 格式的基础）、其他文件生成（典型应用就是 JSP）等等。
一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的 loadClass() 方法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。

2.2.2 链接

2.2.2.1 验证

image.png

2.2.2.2 准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

  1. 这时候进行内存分配的仅包括类变量（ Class Variables ，即静态变量，被 static 关键字修饰的变量，只与类相关，因此被称为类变量），而不包括实例变量。实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
  2. 从概念上讲，类变量所使用的内存都应当在 方法区 中进行分配。不过有一点需要注意的是：JDK 7 之前，HotSpot 使用永久代来实现方法区的时候，实现是完全符合这种逻辑概念的。 而在 JDK 7 及之后，HotSpot 已经把原本放在永久代的字符串常量池、静态变量等移动到堆中，这个时候类变量则会随着 Class 对象一起存放在 Java 堆中。
  3. 这里所设置的初始值”通常情况”下是数据类型默认的零值（如 0、0L、null、false 等），比如我们定义了public static int value=111 ，那么 value 变量在准备阶段的初始值就是 0 而不是 111（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 final 关键字public static final int value=111 ，那么准备阶段 value 的值就被赋值为 111。

基本数据类型的零值 ：
image.png

2.2.2.3 解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。
符号引用就是一组符号来描述目标，可以是任何字面量。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。在程序实际运行时，只有符号引用是不够的，举个例子：在程序执行方法时，系统需要明确知道这个方法所在的位置。Java 虚拟机为每个类都准备了一张方法表来存放类中所有的方法。当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法了。通过解析操作符号引用就可以直接转变为目标方法在类中方法表的位置，从而使得方法可以被调用。
综上，解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，也就是得到类或者字段、方法在内存中的指针或者偏移量。（class常量池 -》 运行时常量池）

2.2.3 初始化

初始化阶段是执行初始化方法 ()方法的过程，是类加载的最后一步，这一步 JVM 才开始真正执行类中定义的 Java 程序代码(字节码)。

说明： ()方法是编译之后自动生成的。

对于 () 方法的调用，虚拟机会自己确保其在多线程环境中的安全性。因为 () 方法是带锁线程安全，所以在多线程环境下进行类初始化的话可能会引起多个进程阻塞，并且这种阻塞很难被发现。
对于初始化阶段，虚拟机严格规范了有且只有 5 种情况下，必须对类进行初始化(只有主动去使用类才会初始化类)：

  1. 当遇到 new 、 getstatic、putstatic 或 invokestatic 这 4 条直接码指令时，比如 new 一个类，读取一个静态字段(未被 final 修饰)、或调用一个类的静态方法时。
    • 当 jvm 执行 new 指令时会初始化类。即当程序创建一个类的实例对象。
    • 当 jvm 执行 getstatic 指令时会初始化类。即程序访问类的静态变量(不是静态常量，常量会被加载到运行时常量池)。
    • 当 jvm 执行 putstatic 指令时会初始化类。即程序给类的静态变量赋值。
    • 当 jvm 执行 invokestatic 指令时会初始化类。即程序调用类的静态方法。
  2. 使用 java.lang.reflect 包的方法对类进行反射调用时如 Class.forname(“…”), newInstance() 等等。如果类没初始化，需要触发其初始化。
  3. 初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。
  4. 当虚拟机启动时，用户需要定义一个要执行的主类 (包含 main 方法的那个类)，虚拟机会先初始化这个类。

  5. MethodHandle 和 VarHandle 可以看作是轻量级的反射调用机制，而要想使用这 2 个调用， 就必须先使用 findStaticVarHandle 来初始化要调用的类。

    2.3 类的卸载

    卸载类即该类的 Class 对象被 GC。
    卸载类需要满足 3 个要求:

  6. 该类的所有的实例对象都已被 GC，也就是说堆不存在该类的实例对象。

  7. 该类没有在其他任何地方被引用
  8. 该类的类加载器的实例已被 GC

所以，在 JVM 生命周期内，由 jvm 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。
只要想通一点就好了，jdk 自带的 BootstrapClassLoader, ExtClassLoader, AppClassLoader 负责加载 jdk 提供的类，所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的，所以使用我们自定义加载器加载的类是可以被卸载掉的。

三. 类加载器

3.1 类加载器总结

JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader：

  1. BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由 C++实现，负责加载 %JAVA_HOME%/lib目录下的 jar 包和类或者被 -Xbootclasspath参数指定的路径中的所有类。
  2. ExtensionClassLoader(扩展类加载器) ：主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类，或被 java.ext.dirs 系统变量所指定的路径下的 jar 包。
  3. AppClassLoader(应用程序类加载器) ：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。

3.2 双亲委派加载模型

每一个类都有一个对应它的类加载器。系统中的 ClassLoader 在协同工作的时候会默认使用 双亲委派模型 。即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派给父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为 null 时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。
image.png

代码

双亲委派模型的实现代码非常简单，逻辑非常清晰，都集中在 java.lang.ClassLoader 的 loadClass() 中，相关代码如下所示。

  1. private final ClassLoader parent;
  2. protected Class<?> loadClass(String name, boolean resolve)
  3.         throws ClassNotFoundException
  4.     {
  5.         synchronized (getClassLoadingLock(name)) {
  6.             // 首先，检查请求的类是否已经被加载过
  7.             Class<?> c = findLoadedClass(name);
  8.             if (c == null) {
  9.                 long t0 = System.nanoTime();
  10.                 try {
  11.                     if (parent != null) {//父加载器不为空，调用父加载器loadClass()方法处理
  12.                         c = parent.loadClass(name, false);
  13.                     } else {//父加载器为空，使用启动类加载器 BootstrapClassLoader 加载
  14.                         c = findBootstrapClassOrNull(name);
  15.                     }
  16.                 } catch (ClassNotFoundException e) {
  17.                    //抛出异常说明父类加载器无法完成加载请求
  18.                 }
  20.                 if (c == null) {
  21.                     long t1 = System.nanoTime();
  22.                     //自己尝试加载
  23.                     c = findClass(name);
  25.                     // this is the defining class loader; record the stats
  26.                     sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
  27.                     sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
  28.                     sun.misc.PerfCounter.getFindClasses().increment();
  29.                 }
  30.             }
  31.             if (resolve) {
  32.                 resolveClass(c);
  33.             }
  34.             return c;
  35.         }
  36.     }

3.3 为啥使用双亲委派加载模型

双亲委派模型保证了 Java 程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。