类的加载

Class文件结构

1. 魔数(Magic Number)
2. Class 文件版本号
3. 常量池(Constant Pool)
4. 访问标志(Access Flags)
5. 当前类(This Class)、父类(…
6. 字段表集合(Fields)
7. 方法表集合(Methods)
8. 属性表集合(Attributes

OOP-KLASS

HotSpot采用Oop-Klass模型来表示Java对象。其中Klass对应着Java对象的类型，就是方法区存储的元数据结构体，用C语言的结构体表示，如类的继承关系、方法表、字段表、常量池等。而Oop则对应着Java对象的实例（Instance）。

Oop是一个继承体系，其中oop是体系中的最高父类。这里的Oop并非是Object-oriented programming，而是Ordinary object pointer（普通对象指针），是HotSpot用来表示Java对象的实例信息的一个体系。其中oop是Oop体系中的最高父类，整个继承体系如下所示：

oop的子类有两个，分别是instanceOop和arrayOop。前者表示Java中普通的对象，后者则表示数组对象。arrayOop也有两个子类，objArrayOop表示普通对象类型的数组，而typeArrayOopDesc则表示基础类型的数组。如下图所示，oop的存储结构主要由对象头和对象体组成。

Oop的存储结构可以分成对象头和对象体，对象头主要由两部分组成，一部分是 Mark Word，另一部分包括 Klass 指针，还可能包含数组长度（针对数组对象）。 Mark Word 用于存储对象的一些运行时数据，如哈希码、分代年龄、锁状态等信息，对象体存储的是具体的成员属性。值得注意的是，如果成员属性属于普通对象类型，则oop只存储它的地址。

代码中通过对象实例调用方法，JVM如何找到这个方法的定义然后执行呢？通过下图即可知道答案，通过栈帧的局部变量表中存储的对象引用，从堆中找到相应的Java对象实例，对象头中维护了指向Klass结构的指针，指向方法区该类型的InstanceKlass，其中包含了该类的定义，就是Class文件中的定义加载到JVM后的结构表示，其中还维护了一个指向Class对象的指针，Class对象存储在堆中，除了类的定义信息，还添加了例如getName、getSimpleName、getModifiers等方法，方便对类的操作。注意：下图只是示意图，描述并不完整。

类的生命周期

类从被加载到虚拟机内存中开始到卸载出内存为止，它的整个生命周期可以简单概括为 7 个阶段：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）。其中，验证、准备和解析这三个阶段可以统称为连接（Linking）。

加载

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

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

加载这一步主要是通过我们后面要讲到的 类加载器 完成的。类加载器有很多种，当我们想要加载一个类的时候，具体是哪个类加载器加载由 双亲委派模型 决定（不过，我们也能打破由双亲委派模型）。

每个 Java 类都有一个引用指向加载它的 ClassLoader。不过，数组类不是通过 ClassLoader 创建的，而是 JVM 在需要的时候自动创建的，数组类通过getClassLoader()方法获取 ClassLoader 的时候和该数组的元素类型的 ClassLoader 是一致的。

验证

验证是连接阶段的第一步，这一阶段的目的是确保 Class 文件的字节流中包含的信息符合《Java 虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证阶段也不是必须要执行的阶段。如果程序运行的全部代码(包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码)都已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。但是需要注意的是 -Xverify:none 和 -noverify 在 JDK 13 中被标记为 deprecated ，在未来版本的 JDK 中可能会被移除。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段。

这时候进行内存分配的仅包括类变量（ Class Variables ，即静态变量，被 static 关键字修饰的变量，只与类相关，因此被称为类变量），而不包括实例变量。实例变量会在对象实例化时随着对象一块分配在 Java 堆中。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。

.符号引用(SymbolicReferences):符号引用以一组符号来描述所引用的目标，符号可以是任何只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引形式的字面量，用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。
·直接引用(DirectReferences):直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

初始化

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

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

对于初始化阶段，虚拟机严格规范了有且只有 6 种情况下，必须对类进行初始化(只有主动去使用类才会初始化类)：

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 来初始化要调用的类。
6. 「补充，来自issue745」 当一个接口中定义了 JDK8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

类卸载

卸载这部分内容来自 issue#662由 guang19 补充完善。

卸载类即该类的 Class 对象被 GC。

卸载类需要满足 3 个要求:

1. 该类的所有的实例对象都已被 GC，也就是说堆不存在该类的实例对象。
2. 该类没有在其他任何地方被引用
3. 该类的类加载器的实例已被 GC

所以，在 JVM 生命周期内，由 jvm 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。

只要想通一点就好了，JDK 自带的 BootstrapClassLoader, ExtClassLoader, AppClassLoader 负责加载 JDK 提供的类，所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的，所以使用我们自定义加载器加载的类是可以被卸载掉的。

类加载器

重复加载问题

假设有两个自定义类加载器 ClassLoaderA 和 ClassLoaderB，它们都可以独立加载类。现在有一个类 MyClass，ClassLoaderA 和 ClassLoaderB 都收到了加载 MyClass 的请求。由于没有双亲委派模型，它们不会将加载请求委派给父类加载器，而是各自去加载 MyClass，这样 MyClass 就会被重复加载。

双亲委派模型

JVM 中内置了三个重要的 ClassLoader：

1. BootstrapClassLoader(启动类加载器)：最顶层的加载类，由 C++实现，通常表示为 null，并且没有父级，主要用来加载 JDK 内部的核心类库（ %JAVA_HOME%/lib目录下的 rt.jar、resources.jar、charsets.jar等 jar 包和类）以及被 -Xbootclasspath参数指定的路径下的所有类。
2. ExtensionClassLoader(扩展类加载器)：主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类以及被 java.ext.dirs 系统变量所指定的路径下的所有类。
3. AppClassLoader(应用程序类加载器)：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。

Java 类加载器采用双亲委派模型，当一个类加载器收到类加载请求时，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都会传送到最顶层的启动类加载器。只有当父类加载器反馈自己无法完成该加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

在这个过程中，类加载器会维护一个已加载类的列表，这个列表通常使用类的全限定名（包含包名的类名，如 java.lang.String）作为键来存储已经加载的类的信息。当收到一个类加载请求时，类加载器会首先检查这个列表，看请求加载的类的全限定名是否已经存在于列表中。

打破双亲委派模型的办法

自定义加载器的话，需要继承 ClassLoader 。如果我们不想打破双亲委派模型，就重写 ClassLoader 类中的 findClass() 方法即可，无法被父类加载器加载的类最终会通过这个方法被加载。但是，如果想打破双亲委派模型则需要重写 loadClass() 方法。

为什么是重写 loadClass() 方法打破双亲委派模型呢？双亲委派模型的执行流程已经解释了：

类加载器在进行类加载的时候，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成（调用父加载器 loadClass()方法来加载类）。

重写 loadClass()方法之后，我们就可以改变传统双亲委派模型的执行流程。例如，子类加载器可以在委派给父类加载器之前，先自己尝试加载这个类，或者在父类加载器返回之后，再尝试从其他地方加载这个类。具体的规则由我们自己实现，根据项目需求定制化。