深入理解JVM（三）Java 类加载机制

1 什么是类加载机制

Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。

2 类的生命周期

其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段，在这五个阶段中，加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

2.1 加载

将classpath、jar包、网络、某个磁盘位置下的类的class二进制字节流读进来，在内存中生成一个代表这个类的java.lang.Class对象放入元空间，此阶段我们程序员可以干预，我们可以自定义类加载器来实现类的加载。

2.2 验证

验证Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证虚拟机的安全。

• 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
• 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了
  java.lang.Object之外。
• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
• 符号引用验证：确保解析动作能正确执行

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用 -Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

2.3 准备

为类的静态变量(static)分配内存，并将其初始化为默认值(基本数据类型的默认值如下图，引用数据类型的默认值为null)，而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。对于同时被static和final修饰的常量，会被赋实际值。

示例

//实例变量
public int a;

//静态变量(类变量)
public static int b;

//常量
public static final int c = 20;

准备阶段过后，没有对a进行任何处理，将b赋初始值0，将赋实际值20

2.4 解析

将常量池内的符号引用替换为直接引用。

符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可

直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄

2.5 初始化

初始化阶段就是执行类构造器< clinit >()方法的过程，< clinit >()方法是由编译器自动收集类中的所有类变量（静态变量）的赋值动作和静态语句块（static{}块）中的语句合并产生的。

2.5.1 < clinit >()方法详解

编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。

示例

public class Test {
    static {
        i = 0; // 给变量赋值可以正常编译通过
        System.out.print(i); // 这句编译器会提示“非法向前引用”
    }
    static int i = 1;
}

虚拟机会保证在子类的< clinit >()方法执行之前，父类的< clinit >()方法已经执行完毕。因此在虚拟机中第一个被执行的< clinit >()方法的类肯定是java.lang.Object。由于父类的< clinit >()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。

示例

class Parent{
    public static int A=1;

    static{
        A=2;
    }

    static class Child extends Parent{
        public static int B=A;
    }
    public static void main(String[]args){
        System.out.println(Child.B);
    }
}

< clinit >()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成< clinit >()方法。

接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成< clinit >()方法。但接口与类不同的是，执行接口的< clinit >()方法不需要先执行父接口的< clinit >()方法，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也一样不会执行接口的< clinit >()方法。

2.5.2 类在什么情况下会进行初始化

• 创建类的实例，也就是new对象的方式
• 访问某个类或接口的静态变量，或者对该静态变量赋值
• 调用类的静态方法
• 反射（如 Class.forName(“com.demo.Test”)）
• 初始化某个类的子类，则其父类也会被初始化
• Java虚拟机启动时被标明为启动类的类，直接使用 java.exe命令来运行某个主类

2.6 使用

使用这个类。

2.7 卸载

当类使用完了之后，类进入卸载阶段。类使用完的标准如下：

• 该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。

3 类加载器

3.1 什么是类加载器

实现类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作的代码模块称为“类加载器”(Class Loader)，这个动作是可以自定义实现的。

3.2 类的唯一性

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

3.3 类加载的方式

• 命令行启动应用时候由JVM初始化加载
• 通过Class.forName()方法动态加载
• 通过ClassLoader.loadClass()方法动态加载

Class.forName的形式加载类时，默认会执行类的初始化，而ClassLoader.loadClass的方式加载类时，只对类进行加载，而不进行验证、准备和解析，也不进行初始化。

3.4 JVM有哪些类加载器

• 启动类加载器(Bootstrap ClassLoader)

启动类加载器主要加载的是JVM自身需要的类，这个类加载使用C++语言实现的，是虚拟机自身的一部分。它负责加载<JAVA_HOME>\jre\lib\rt.jar，resources.jar、charsets.jar以及被-Xbootclasspath参数所指定的路径中存放的类库。如果文件名不被虚拟机识别，即使把jar包丢到lib目录下也是没有作用的。启动类加载器是无法被Java程序直接引用的。

• 扩展类加载器(Extension ClassLoader)

扩展类加载器是指Sun公司(已被Oracle收购)用Java语言实现的sun.misc.Launcher$ExtClassLoader类，是Launcher的一个静态内部类，它负责加载<JAVA_HOME>\jre\lib\ext目录下或者被系统变量java.ext.dirs系统变量所指定的路径中所有的类库;开发者可以直接使用扩展类加载器。

• 应用程序类加载器(Application ClassLoader)

应用程序类加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader，也是Launcher的一个静态内部类，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

3.5 类加载器间的关系

示例

public class Test {
    public static void main(String[] args) {
        ClassLoader classLoader = Test.class.getClassLoader();
        System.out.println(classLoader);
        System.out.println(classLoader.getParent());
        System.out.println(classLoader.getParent().getParent());
    }
}

因为BootstrapClassLoader是由c++实现的，所以并不存在一个Java的类，因此会打印出null

看到这里，有人可能认为这三个类加载器之间是继承关系，而实际上不是，AppClassLoader和ExtClassLoader都是Launcher类的静态内部类，不存在继承关系，而Bootstrap ClassLoader是由C++语言写的，就更不可能存在继承关系了。

• 启动类加载器(BootstrapClassLoader)，由C++实现，没有父类。
• 拓展类加载器(ExtClassLoader)，父类加载器为null
• 应用程序类加载器(AppClassLoader)，父类加载器为ExtClassLoader
• 自定义类加载器，父类加载器肯定为AppClassLoader

3.6 双亲委派模型

3.6.1 双亲委派模型的工作过程

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当上一层类加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到这个类)时，下一层类加载器才会尝试自己去加载。

双亲委派源码实现

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

3.6.2 为什么要设计双亲委派模型

• 确保安全，避免Java核心类库被修改
• 避免重复加载，保证类的唯一性

示例

package java.lang;

public class String {
    public static void main(String[] args) {
        System.out.println("hello world!");
    }
}

由于双亲委派机制，AppClassLoader和ExtClassLoader均不进行加载，而到了BootstrapClassLoader，该类加载器加载<JAVA_HOME>\jre\lib\rt.jar时，加载了rt.jar中的java.lang包下的String类，因此下层的类加载器将不再进行加载，而rt.jar中的java.lang包下的String类中并没有main方法，因此报错。

3.6.3 可以打破JVM双亲委派模型吗

答案是可以的，想要打破这种模型，那么就自定义一个类加载器，重写其中的loadClass()方法，使其不进行双亲委派即可

3.6.4 为什么Tomcat要破坏双亲委派模型

Tomcat是 web容器，那么一个web容器可能需要部署多个应用程序

• 部署在同一个Tomcat上的两个Web应用所使用的Java类库要相互隔离
• 部署在同一个Tomcat上的两个Web应用所使用的Java类库要互相共享
• 保证Tomcat服务器自身的安全不受部署的Web应用程序影响;
• 需要支持JSP页面的热部署和热加载

3.7 如何自定义自己的类加载器

1. 继承ClassLoader
2. 覆盖findClass(String name)方法或者loadClass()方法

覆盖findClass(String name)方法不会打破双亲委派，覆盖loadClass()方法可以打破双亲委派

3.8 如何实现热加载

在程序代码更改且重新编译后，让运行的进程可以实时获取到新编译后的Class文件，然后重新进行加载

1. 实现自己的类加载器
2. 从自己的类加载器中加载要热加载的类
3. 不断轮询要热加载的类class文件是否有更新，如果有更新，重新加载