JVM——类的加载过程

类的生命周期

一个类的完整生命周期如下：

加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序进行，而解析阶段则不一定，可能在初始化阶段后在开始，因为java支持运行时绑定。

类加载过程

Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？

系统加载 Class 类型的文件主要三步:加载->连接->初始化。连接过程又可分为三步:验证->准备->解析。

加载

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

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

虚拟机规范多上面这3点并不具体，因此是非常灵活的。比如：“通过全类名获取定义此类的二进制字节流” 并没有指明具体从哪里获取、怎样获取。比如：比较常见的就是从 ZIP 包中读取（日后出现的JAR、EAR、WAR格式的基础）、其他文件生成（典型应用就是JSP）等等。

一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的 loadClass() 方法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。

所有的类都由类加载器加载，加载的作用就是将 .class文件加载到内存。

类加载器

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包和类。

双亲委派模型

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

AppClassLoader的父类加载器为ExtClassLoader ExtClassLoader的父类加载器为null，null并不代表ExtClassLoader没有父类加载器，而是 BootstrapClassLoader 。

双亲委派模型的好处

双亲委派模型保证了Java程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。

如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。

自定义类加载器

如果不想使用双亲委托机制，可以自定义一个类加载器，然后重写 loadClass() 即可。

除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader。如果我们要自定义自己的类加载器，很明显需要继承 ClassLoader。

验证

加载阶段和连接阶段的部分内容是交叉进行的，加载阶段尚未结束，连接阶段可能就已经开始了。

验证阶段确保被加载的类的正确性：确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

1. 文件格式验证：验证字节流是否符合Class文件格式的规范，如：是否以模数0xCAFEBABE开头、主次版本号是否在当前虚拟机处理范围内等等。
2. 元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求；如：这个类是否有父类，是否实现了父类的抽象方法，是否重写了父类的final方法，是否继承了被final修饰的类等等。
3. 字节码验证：最复杂的一个阶段。通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，如：操作数栈的数据类型与指令代码序列能配合工作，保证方法中的类型转换有效等等。
4. 符号引用验证：确保解析动作能正确执行；如：通过符合引用能找到对应的类和方法，符号引用中类、属性、方法的访问性是否能被当前类访问等等。

验证阶段是非常重要的，但不是必须的。可以采用-Xverify:none参数来关闭大部分的类验证措施。

准备

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

1. 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
2. 这里所设置的初始值"通常情况"下是数据类型默认的零值（如0、0L、null、false等），比如我们定义了public static int value=111 ，那么 value 变量在准备阶段的初始值就是 0 而不是111（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 final 关键字public static final int value=111 ，那么准备阶段 value 的值就被赋值为 111。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。也就是得到类或者字段、方法在内存中的指针或者偏移量。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符7类符号引用进行。

初始化

初始化是为类的静态变量赋予正确的初始值。

初始化时机

加载（loading）阶段，java虚拟机规范中没有进行约束，但初始化阶段，java虚拟机严格规定了有且只有如下5种情况必须立即进行初始化。（只有主动去使用类才会初始化类，初始化前，必须经过加载、验证、准备阶段）

1. 使用new实例化对象时。
2. 读取和设置类的静态变量、静态非字面值常量（静态字面值常量除外）时。（参考下面的小例子）
3. 调用静态方法时。
4. 用 java.lang.reflect 包的方法对类进行反射调用时。
5. 初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。
6. 当虚拟机启动时，用户需要定义一个要执行的主类 (包含 main 方法的那个类)，虚拟机会先初始化这个类。
7. (补充)MethodHandle和VarHandle可以看作是轻量级的反射调用机制，而要想使用这2个调用， 就必须先使用findStaticVarHandle来初始化要调用的类。
8. (补充)当一个接口中定义了JDK8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

关于第2点，有个小例子：

public class TestClass {
    public static void main(String[] args) {
        System.out.println(ClassInit.str);
        System.out.println(ClassInit.id);
    }
}
class ClassInit{
    public static final long id=IdGenerator.getIdWorker().nextId();//静态非字面值常量，需要初始化ClassInit类
    public static final String str="abc";//静态字面值常量
    static{
        System.out.println("ClassInit init");
    }
}

不会导致类的初始化

上面的情况被称为主动引用，除此之外的引用称为被动引用，被动引用不会导致类初始化，但不代表类不会经历加载、验证、准备阶段。

1、通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。

class Parent {
    static int a = 100;
    static {
        System.out.println("parent init！");
    }
}
 
class Child extends Parent {
    static {
        System.out.println("child init！");
    }
}
 
public class Init{  
    public static void main(String[] args){  
        System.out.println(Child.a);  //不会初始化类Child
    }  
}

输出结果为：parent init！ 不会初始化Child类。

2、定义对象数组和集合，不会触发该类的初始化。

 public class Init{  
    public static void main(String[] args){  
        Parent[] parents = new Parent[10]; //不会初始化类Parent
    }  
}

3、类A引用类B的static final常量不会导致类B初始化（注意静态常量必须是字面值常量，否则还是会触发B的初始化）

class Const {
    static final int A = 100; //编译阶段，常量A存储到Init类的常量池中
    static {
        System.out.println("Const init");
    }
}
 
public class Init{  
    public static void main(String[] args){  
        System.out.println(Const.A);  
    }  
}

4、通过类名获取Class对象，不会触发类的初始化。

public class test {
   public static void main(String[] args) throws ClassNotFoundException {
        Class c_dog = Dog.class; //不会初始化Dog类
        Class clazz = Class.forName("zzzzzz.Cat"); //会初始化Cat类
    }
}
 
class Cat {
    private String name;
    private int age;
    static {
        System.out.println("Cat is load");
    }
}
 
class Dog {
    private String name;
    private int age;
    static {
        System.out.println("Dog is load");
    }
}

5、通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化。
6、通过ClassLoader默认的loadClass方法，也不会触发初始化动作

卸载

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

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

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

JDK自带的BootstrapClassLoader,PlatformClassLoader,AppClassLoader负责加载jdk提供的类，所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的，所以使用我们自定义加载器加载的类是可以被卸载掉的。
例子：

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

如果程序运行过程中，将上图左侧三个引用变量都置为null，此时Sample对象结束生命周期，MyClassLoader对象结束生命周期，代表Sample类的Class对象也结束生命周期，Sample类在方法区内的二进制数据被卸载。

当再次有需要时，会检查Sample类的Class对象是否存在，如果存在会直接使用，不再重新加载；如果不存在Sample类会被重新加载，在Java虚拟机的堆区会生成一个新的代表Sample类的Class实例(可以通过哈希码查看是否是同一个实例)。

参考：JVM中类的卸载机制
参考：JVM类加载过程
参考：Java初始化过程总结
参考：类的生命周期