Java类加载机制

你知道Java的类加载机制吗？字节码文件时如何被加载使用的你？今天我们从以下几个方面，一起聊聊类加载。

• 类加载过程以及介绍
• 类加载器介绍

类加载过程

我们用一张图来梳理类的生命周期，如下所示：

类的生命周期

类加载的过程主要有三部分组成：加载、连接、初始化；其中连接可以细分为验证、准备、解析三个过程；那么此过程中各个阶段都分别做了什么工作呢？

加载

“加载”是“类加载”的一个阶段，在这个阶段，虚拟机主要做了以下事情：

• 通过类的全限定名过去二进制字节流
• 将字节流所代表的静态存储结构转化为方法区的运行时数据结果
• 在内存中创建一个代表该类的java.lang.Class对象，用于方法区这个类的各数据的访问入口

验证

验证阶段，主要包含四个验证过程

• 文件格式验证：验证是否符合Class文件格式
• 元数据验证：对类的元数据信息进行语义验证；验证类是否有父类，验证类是否继承了final类，如果类不是抽象类是否实现类接口或父类方法等
• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的，符合逻辑的（最复杂的验证过程）
• 符号引用验证：验证发生在符号引用转换为直接引用的时候，验证是否可以根据全限定名找到指定的类，指定的类是否有指定的方法和字段，验证字段和方法的访问控制(private,protected,default,public) 等；其目的是为了保证解析阶段能够正常的执行

准备

准备阶段完成的工作是给类变量(static修饰)完成内存的分配以及给类变量赋初始值；

private static int a=100;

经过准备阶段的a的初始值是0，而不是100；因为将a值赋值为100的putstatic 指令是在被编译后，存放于<clinit>构造方法之中。
基本类型的初始值如下：
![初始值](https://img.haomeiwen.com/i16709548/0ee51382785cc6bc.png?imageMogr2/aut

o-orient/strip%7CimageView2/2/w/1240)

但是也存在特殊情况，比如被final修饰的类变量将直接被赋值为指定的值；如下的在准备阶段将被赋值为100

private static final int a=100;

解析

解析阶段完成的工作是将符号引用转化为直接引用。

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

直接引用：直接引用可以是一个直接执行目标的指针，偏移量；或者是一个能间接定位到目标对象的句柄。

初始化

初始化时类加载过程的最后一步，前面的加载过程，除了加载阶段有类加载器参与，其余阶段都有虚拟机主导和控制；到了初始化阶段才开始真正执行Java程序(字节码)。

在准备阶段已经完成过一次系统要求的赋值，而在初始化阶段，根据程序员通过程序制定的主观计划去初始化类变量和其他资源。或者从另一个角度说，初始化是执行<clinit> 构造方法的过程。注意:同一个类加载器，同一个类型只会加载一次；当且仅当以下5种场景，会立马触发类的初始化：

• 遇到new,putstatic,getstatic,invokestatic 4中字节码指令时
• 使用java.lang.reflect包下的方法对类进行反射调用时，类还未初始化
• 初始化某个类时，发现其父类还未初始化，则先出法其父类的初始化
• 当虚拟机启动时，执行主类(包含main方法)的类本身，虚拟机会先初始化此类
• 当使用JDK1.7动态语言支持时，使用java.lang.invoke.MethodHandle 实例最后解析结果是REF_getStatic，REF_putStatic，REF_invokeStatic方法句柄，并且这个方法句柄对应的类还没有初始化，则优先触发初始化

类加载器

类和类加载器

类加载器虽然只用于实现“类加载”的动作，但其在Java程序中的作用却远远不限于类加载阶段。对于任意一个类，都需要有该类的类加载器和类本身来确定在虚拟机中的唯一性；也可以这样理解，判断两个类是否“相等”，必须建立在同一个类加载器的前提下，否则是无意义的。这里的“相等”包括，equals()，isInstance()，isAssignableFrom()方法返回的结果以及instanceof关键字。

双亲委派模型

从Java虚拟机的角度来看只存在两种类加载器，一种是Bootstrap ClassLoader（HotSpot由C++实现），是虚拟机的一部分；另一种是其他加载器，这些加载器由Java实现，独立于虚拟机外部，并且全部继承自抽象类ClassLoader。

从Java程序员的角度来看，类加载器划分的更加细致一些；分为Bootstrap ClassLoader (启动类加载器)，Extension ClassLoader (扩展类加载器)，Application ClassLoader(应用类加载器)，以及User ClassLoader (用户自定义加载器)。

Bootstrap ClassLoader：虚拟机的一部分，Java程序无法直接引用；负责加载<JAVA_HOME>/lib 路径下的类库加载到虚拟机内存中。

Extension ClassLoader：由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>/lib/ext 路径下的类库加载到虚拟机内存中。

Application ClassLoader：由sun.misc.Launcher$AppClassLoader实现，负责加载。这个类加载器是CLassLoader中getSystemClassLoader()的返回值，所以也称为系统类加载器，负责加载Classpath上指定的类库，开发者也可以直接使用该加载器。

当然我们也可以根据需要自定义类加载器，各类加载器的继承层次结构如下：

加载器结构图

双亲委派的工作过程：当一个加载器收到类加载请求时，首先它不会自行加载该类，而是交由自己的父类加载器去完成，最终将类加载请求传递至Bootstrap CLassLoader；只有父类加载器反馈自己无法加载时，子类加载器才会自己尝试加载。

双亲委派模型实现

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先通过findLoadedClass判断是否已加载
            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) {
                    // 父加载器加载失败
                }

                if (c == null) {
                    // 如果仍未成功加载，则调用findClass去找到该类
                    long t1 = System.nanoTime();
                    c = findClass(name);
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }