类加载机制

虚拟机的类加载机制就是将描述类的数据从Class文件加载到内存，并对数据进行校验、解析和初始化，最终形成可直接使用的Java类型的过程。
类从被加载到虚拟机内存中开始，直到从内存中卸载为止，它的整个生命周期分为七个阶段：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸御(Unloading)。其中验证、准备、解析三个部分统称为连接。七个阶段发生的顺序如下：

类加载时机

虚拟机规范中没有强行约束类加载的时机。也就是说，具体的虚拟机可以自定义类加载时机。但是，虚拟机严格规范了“类初始化”时机。有且只有下述五种情况会对类进行初始化：
(1) 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，会尝试进行初始化。上述四条指令对应的Java代码场景是：使用new关键字实例化对象时、读取或者设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）时、调用一个类的静态方法。
(2) 使用java.lang.reflect包的方法对类进行反射调用(如Class.forName(“com.xx.Main”))，如果类没有进行过初始化，则需要先触发其初始化。
(3) 当初始化一个类时，如果发现其父类还未初始化，则先触发父类的初始化。
(4) 虚拟机启动时，用户指定的需要执行的主类（包含main()方法的类）先初始化。
(5) 在使用JDK 1.7版本及更高版本时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果是REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄时，会尝试对这个方法句柄对应的类进行初始化。
对于以上五种场景，虚拟机规范将其行为称为对一个类进行“主动引用”。其他引用类的方式，均不会触发类的初始化，统称为“被动引用”。被动引用常见场景如下:
(1) 子类调用父类的静态字段，子类不会被初始化，只有父类会初始化。也就是说，对于静态字段，只有直接定义这个字段的类才会被初始化。
(2) 通过数组定义来引用类，不会触发该类的初始化。
(3) 访问类的常量(static final修饰字段)，不会触发该类的初始化。

类和接口在加载阶段的区别

接口的加载与类的加载稍有不同：
(1) 接口中不能使用static{}块。
(2) 当一个接口在初始化时，并不要求其父接口全部都完成初始化，只有真正在使用到父接口时（例如引用接口中定义的常量）才会初始化。

类加载过程

虚拟机中类加载的全过程包括加载、验证、准备、解析和初始化五个阶段。
在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下会在初始化阶段之后开始，这是为了支持Java语言的运行时绑定。另外，上述几个阶段是按顺序开始，这些阶段是互相交叉进行，通常在一个阶段执行的过程中会调用或激活另一个阶段。

加载(Loading)

加载就是将类的二进制流加载到内存中。详细来说，在加载阶段，虚拟机需要完成以下三件事情：
（1）通过一个类的全限定名来获取其定义的二进制字节流；
（2）将这个二进制字节流所代表的静态存储结构转化为方法区的运行时数据结构；
（3）在 Java 堆中生成一个代表这个类的java.lang.Class对象，作为方法区中这个类的数据的访问入口。
注意，虚拟机没有严格限制二进制字节流的获取来源。除了从Class文件中获取，还可以从ZIP包中获取（Jar包、EAR包、VWAR包）、从网络中获取（最典型的应用是Applet）、运行时计算生成（使用动态代理技术）、其他文件生成（JSP应用）、从数据库中读取，等。
加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是开发人员可控性最强的阶段，开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。
加载阶段的核心是“类加载器”。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，并在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

验证(Verification)

验证的目的是为了确保Class文件的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。
虚拟机对类验证的实现，大致都会包含以下四个阶段的验证：文件格式验证、元数据验证、字节码验证和符号引用验证。
（1）文件格式验证：验证字节流是否符合Class文件格式规范，并且能被当前版本的虚拟机处理。该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。后面三个验证都是基于方法区的存储结构进行的。
（2）元数据验证：对类的元数据信息进行语义分析（对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
（3）字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，确保程序语义是合法、符合逻辑的。对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。字节码校验从类型推导转变为类型检查（StackMapTable属性记录是否合法），节省验证所需时间。
（4）符号引用验证：就是对对类自身以外的信息进行匹配性验证。该验证发生在虚拟机将符号引用转化为直接引用的时候，该验证的主要目的是确保解析动作能正常执行。

准备(Preparation)

准备阶段是为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下两点需要注意：
（1）分配内存的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
（2）这里的初始值，仅是数据类型默认的零值（如0、0L、null、false等），而不是在Java代码中被显式地赋予的值。假设一个类变量的定义为：

public static int value = 3；

那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的putstatic指令是在程序编译后，存放于类构造器（）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。
(3) 字段属性表存在ConstantValue属性（类常量，static final）时，其值会初始化为ConstantValue指定的值。

解析(Resolution)

解析是虚拟机将常量池中的符号引用转化为直接引用的过程。

符号引用和直接引用

Class文件中不会保存类或接口、字段、方法的内存布局信息，虚拟机会在加载Class文件时进行动态连接，将符号引用转换为直接引用，也就是解析的过程。符号引用和直接引用的区别与关联：
（1）符号引用：一组符号来描述所引用的目标。符号引用与虚拟机实现的内存布局无关，引用的目标无需加载到内存。
（2）直接引用：直接指向目标的指针、相对偏移量或间接定位到目标的句柄。直接引用与虚拟机实现的内存布局相关，同一个符号引用在不同虚拟机实例上解析的直接引用一般不会相同。直接引用引用的目标，必定已经存在于内存中。

解析时机

解析阶段可能开始于初始化之前，也可能在初始化之后开始，虚拟机会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析（初始化之前），还是等到一个符号引用将要被使用前才去解析它（初始化之后）。

解析目标

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符七类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info、CONSTANT_InvokeDynamic_info七种常量类型。
其中方法类型、方法句柄和调用点限定符位是JDK 1.7新增，与动态语言特性相关。
（1）类或接口的解析：将非数组类型或数组类型，调用不同的类加载器，解析成直接引用。在解析完成前，还会确认访问权限。
（2）字段解析：对字段解析前，会获取字段所属类或接口的符号引用，如果没有，则触发该类或接口的解析。获得字段所属类或接口的符号引用后，先在该类或接口中查找匹配的字段。如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和其父接口。如果还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束。在解析完成前，同样也会确认访问权限。
（3）类方法解析：对类方法的解析与对字段解析的搜索步骤相似，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索是先搜索父类，再搜索接口。在解析完成前，同样也会确认访问权限。
（4）接口方法解析：与类方法解析步骤类似，接口不会有父类，因此，只会递归向上搜索父接口。由于接口方法默认是public，所以不存在访问权限问题。

初始化(Initialization)

特指类的初始化。初始化是执行类构造器()方法的过程。相比准备阶段，变量设置系统要求的初始值，初始化阶段会根据程序员指定的主观计划去初始化类变量和其他资源。
()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的。
()方法不同于构造方法（类或实例的()方法）。在子类的调用前保证父类的()方法已被调用。
()方法是线程安全的，执行的线程需先获取锁才能进行初始化操作，保证只有一个线程能执行(利用此特性可以实现线程安全的懒汉单例模式)。

类加载器

类加载器是根据一个类的全限定名来获取描述此类的二进制字节流。该功能模块被放到Java虚拟机外部实现，实现了应用程序自定义所需类的获取方式。

类和类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其唯一性，每个类加载器都有一个独立的类名称空间。
也就是说，同一个类，在多个类加载器加载后，不再相等。

双亲委派模型（Parents Delegation Model）

Java 中类加载器根据是否继承自java.lang.ClassLoader类可分成两类：一类是启动类加载器（Bootstrap ClassLoader），另一其他类加载器（Other ClassLoader）。启动类加载器使用C++实现，由虚拟机提供。其他类加载器由Java语言实现，独立于虚拟机外部。是由 Java 应用开发人员编写的。
从Java开发人员的角度，类加载器可细为四类：引导类加载器（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）、应用程序类加载器（Application ClassLoader）、自定义类加载器（User ClassLoader）。
(1) 引导类加载器（Bootstrap ClassLoader）： 用来加载 Java 的核心库（放在<JAVA_HOME>\lib目录或-Xbootclasspath参数指定目录，且虚拟机指定的文件名）。该类加载器不继承 java.lang.ClassLoader，如需将加载请求委派给引导类加载，直接使用null即可。
(2) 扩展类加载器（Extension ClassLoader）： 用来加载 Java 的扩展库（放在<JAVA_HOME>\lib\ext目录或java.ext.dirs 系统变量指定的路径）。该类加载器继承自 java.lang.ClassLoader，如需将加载请求委派给引导类加载，可直接调用sun.misc.Launcher$ExtClassLoader。(3)应用程序类加载器（ApplicationClassLoader）：用来加载用户类库（放在用户类路径（CLASSPATH））。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以与将其称为“系统类加载器（SystemClassLoader）”。该类加载器继承自java.lang.ClassLoader，如需将加载请求委派给引导类加载，可直接调用sun.misc.Launcher$ApplicationClassLoader。
(4) 用户类加载器（User ClassLoader）。JVM建议用户将应用程序类加载器作为自定义类加载器的父类加载器。

双亲委派模型简介

类加载器之间的层次关系称为双亲委派模型。
双亲委派模型在JDK 1.2被引入。这里的“双亲”不是指父母，而更倾向于父类，指代当前类加载器的基类加载器。Java Doc 对其过程描述是：

The Java platform uses a delegation model for loading classes. The basic idea is that every class loader has a "parent" class loader. When loading a class, a class loader first "delegates" the search for the class to its parent class loader before attempting to find the class itself.  

双亲委派模型工作过程是： 如果一个类加载器收到了类加载请求，它并不会自己先去加载这个类，而是把这个请求委托给父类的加载器去执行，每一层的类加载器都进行该操作，因此，请求最终将到达顶层的启动类加载器。只有当父类加载器无法完成此加载任务，子加载器才会尝试自己去加载。

双亲委派模型优势

双亲委派模型的优势是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。这种机制的好处是：
（1）首先，这种层级关系可以避免类的重复加载，当父亲已经加载了该类时，就没有必要在子ClassLoader再加载一次。
（2）其次，是考虑到安全因素。Java 核心 API 中定义类型不应被随意替换。假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。同时，java.lang作为核心API包，需要访问权限，强制定义一个启动类加载器无法解析的类后，在自定义类加载中不会被加载。
双亲委派模型的实现如下：

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    Class currentClass = findLoadedClass(name); // 首先，判断是否已经加载过该类
    if(currentClass == null) {
        try {
            if(parent != null) {
                currentClass = parent.loadClass(name, resolve);
            } else {
                currentClass = findBoostrapClassOrNull(name);
            }
        }catch(ClassNotFoundException exception) {
            // 父类无法完成加载请求
        }

        if(currentClass ==  null) {
            c = findClass(name);// 调用自身findClass方法加载类
        }
    }

    if(resolve) {
        resolveClass(currentClass);
    }
}

破坏双亲委派模型

任何事物都具有两面性，双亲委派模型也不例外。在双亲委派模型的发展中，有三次较大的“被破坏”情况。

向下兼容

双亲委派模型的第一次“被破坏”发生在双亲委派模型出现之前。
双亲委派模型发布于JDK 1.2，所以JDK 1.2之前的版本（JDK 1.0 和 JDK 1.1）实现的类加载器不支持双亲委派模型。在JDK 1.2之前，用户通过继承java.lang.ClassLoader，并重写loadClass()方法，实现自定义类加载器。比如，web容器（JBoss、Tomcat、Weblogic）实现了自定义类加载器。
为支持向后兼容，JDK1.2之后的java.lang.ClassLoader添加一个新的proceted方法findClass()。JDK1.2之后已不再提倡用户去覆盖loadClass()方法，而是把自己的类加载逻辑写到findClass()方法中。而对于基于重写loadClass()方法的方式，如果父类加载器加载失败，则可调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派模型的。 实现双亲委派模型的两种方式：
方法一：
重写父类java.lang.ClassLoader的findClass()方法。该方法仅适用于JDK 1.2及之后版本的类加载器。
方法二：
重写父类java.lang.ClassLoader的loadClass()方法和findClass()方法，并在调用loadClass()方法尝试使用父类加载器加载失败后，调用自己的findClass()方法。
打破双亲委派模型示例代码链接：
https://blog.csdn.net/m0_37556444/article/details/81912283

支持SPI调用

双亲委派模型的第二次“被破坏”是这个模型自身的缺陷所导致的。
双亲委派模型解决了各个类加载器的基础类统一问题(越基础的类由越上层的加载器进行加载)，但是却无法解决基础类调用用户代码的场景。一个典型的例子便是JNDI服务，它的代码由启动类加载器去加载(在JDK1.3时放进rt.jar中)，但JNDI的目的就是对资源进行集中管理和查找，它需要调用独立厂商实现部署在应用程序的classpath下的JNDI接口提供者(SPI, Service Provider Interface)的代码，但启动类加载器不可能“认识”这些代码。
为了解决这个困境，Java设计团队只好引入了一个不太优雅的设计：线程上下文件类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置：如果创建线程时还未设置，它将会从父线程中继承一个；如果在应用程序的全局范围内都没有设置过，那么这个类加载器默认就是应用程序类加载器。
这样，JNDI服务就可通过线程上下文类加载器去加载所需SPI代码，也就是父类加载器请求子类加载器去完成类加载动作，这种行为实际上打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背双亲委派模型。Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI,JDBC,JCE,JAXB和JBI等。

支持热部署

双亲委派模型的第三次“被破坏”是由于用户对程序的动态性的追求导致的。
用户希望应用程序能像计算机外设一样，不用重启机器就能立即使用。对一些生产系统，“热部署”（代码热替换、模块热部署），尤其是企业级软件开发者具有极大的吸引力。
模块化规范化之争，主要有Sun主导的Jigsaw项目和已经成为业界“事实上”的Java模块化标准的OSGi。
OSGi的原理是：每个程序模块（OSGi称之为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，将Bundle连同类加载器一起换掉（程序模块和类加载器绑定在一起），以实现代码的热替换。 在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为网状结构。

参考

https://www.jianshu.com/p/bfa495467014
https://www.unclewang.info/learn/java/765/
https://blog.51cto.com/westsky/1579033