深入理解JVM原理之类加载机制（jvm定义的类加载器）

一、类的生命周期

一个类从加载进内存到卸载出内存为止，一共经历7个阶段：

加载——>验证——>准备——>解析——>初始化——>使用——>卸载

其中，类加载包括5个阶段：

加载——>验证——>准备——>解析——>初始化

在类加载的过程中，以下3个过程称为连接：

验证——>准备——>解析

因此，JVM的类加载过程也可以概括为3个过程：

加载——>连接——>初始化

二、类加载的时机

1、类加载过程中“初始化”开始的时机

a. 在运行过程中遇到如下字节码指令时，如果类尚未初始化，那就要进行初始化：new、getstatic、putstatic、invokestatic。这四个指令对应的Java代码场景是：

• 通过new创建对象；
• 读取、设置一个类的静态成员变量(不包括final修饰的静态变量)；
• 调用一个类的静态成员函数。

b. 使用java.lang.reflect进行反射调用的时候，如果类没有初始化，那就需要初始化；

c. 当初始化一个类的时候，若其父类尚未初始化，那就先要让其父类初始化，然后再初始化本类；

d. 当虚拟机启动时，虚拟机会首先初始化带有main方法的类，即主类；

e. 当使用 JDK 1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需先触发其初始化。

2、主动引用与被动引用

JVM规范中要求在程序运行过程中，“当且仅当”出现上述4个条件之一的情况才会初始化一个类。如果间接满足上述初始化条件是不会初始化类的。

其中，直接满足上述初始化条件的情况叫做主动引用；间接满足上述初始化过程的情况叫做被动引用。

那么，只有当程序在运行过程中满足主动引用的时候才会初始化一个类，若满足被动引用就不会初始化一个类。

举几个例子：

示例一：

public class Super{
    public static String name = "后知后觉的老男人";
    static{
        System.out.println("父类被初始化！");
    }
}
public class Sub{
    static{
        System.out.println("子类被初始化！");
    }
}
public static void main(String[] args){
    System.out.println(Sub.name);
}

输出结果：

父类被初始化！
后知后觉的老男人

原因分析：

本示例看似满足初始化时机的第一条：当要获取某一个类的静态成员变量的时候如果该类尚未初始化，则对该类进行初始化。

但由于这个静态成员变量属于Super类，Sub类只是间接调用Super类中的静态成员变量，因此Sub类调用name属性属于间接引用，而Super类调用name属性属于直接引用，由于JVM只初始化直接引用的类，因此只有Super类被初始化。

示例二：

public class Test{
    public static void main(String[] args){
        Super[] arr = new Super[10];
    }
}

输出结果：

并没有输出“父类被初始化！”

原因分析：

这个过程看似满足初始化时机的第一条：遇到new创建对象时若类没被初始化，则初始化该类。

但现在通过new要创建的是一个数组对象，而非Super类对象，因此也属于间接引用，不会初始化Super类。

示例三：

public class Super{
    public static final String name = "后知后觉的老男人";
    static{
        System.out.println("父类被初始化！");
    }
}
public class Test{
    public static void main(String[] args){
        System.out.println(Super.name);
    }
}

输出结果：

后知后觉的老男人

原因分析：

本示例看似满足类初始化时机的第一个条件：获取一个类静态成员变量的时候若类尚未初始化则初始化类。

但是，Super类的静态成员变量被final修饰，它已经是一个常量。被final修饰的常量在Java代码编译的过程中就会被放入它被引用的class文件的常量池中(这里是Test的常量池)。所以程序在运行期间如果需要调用这个常量，直接去当前类的常量池中取，而不需要初始化这个类。

3、接口的初始化

接口和类都需要初始化，接口和类的初始化过程基本一样，不同点在于：

• 类初始化时，如果发现父类尚未被初始化，则先要初始化父类，然后再初始化自己；
• 接口初始化时，并不要求父接口已经全部初始化，只有程序在运行过程中用到当父接口中的东西时才初始化父接口。

三、类加载的过程

1、加载

1.1、加载的过程

在加载过程中，JVM主要做3件事情：

1、通过一个类的全限定名来获取这个类的二进制字节流，即class文件：

在程序运行过程中，当要访问一个类时，若发现这个类尚未被加载，并满足类初始化时机的条件时，就根据要被初始化的这个类的全限定名找到该类的二进制字节流，开始加载过程。

2、将二进制字节流的存储结构转化为特定的数据结构，存储在方法区中；

3、在内存中创建一个java.lang.Class类型的对象：

接下来程序在运行过程中所有对该类的访问都通过这个类对象，也就是这个Class类型的类对象是提供给外界访问该类的接口。

1.2、加载的来源

JVM规范并未严格限制加载的来源。一般二进制字节流都从已经编译好的本地class文件中读取，此外还可以从以下地方读取：

• 从压缩包中读取。如：Jar、War、Ear等。
• 从其它文件中动态生成。如：从JSP文件中生成Class类。
• 从数据库中读取：将二进制字节流存储至数据库中，然后在加载时从数据库中读取。有些中间件会这么做，用来实现代码在集群间分发。
• 从网络中获取：从网络中获取二进制字节流。典型就是Applet。

1.3、数组类的加载

数组类本身不通过类加载器创建，它是由 Java 虚拟机直接创建的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型最终是要靠类加载器去创建的，数组创建过程如下：

• 如果数组的组件类型是引用类型，那就递归采用类加载加载。
• 如果数组的组件类型不是引用类型，Java 虚拟机会把数组标记为引导类加载器关联。
• 数组类的可见性与他的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为 public。

1.4、加载过程的注意点

a. JVM规范并未给出类在方法区中存放的数据结构

类完成加载后，二进制字节流就以特定的数据结构存储在方法区中，但存储的数据结构是由虚拟机自己定义的，JVM规范并没有指定。

b. JVM规范并没有指定Class对象存放的位置

在二进制字节流以特定格式存储在方法区后，JVM会创建一个java.lang.Class类型的对象，作为本类的外部接口。既然是对象就应该存放在堆内存中，不过JVM规范并没有给出限制，不同的虚拟机根据自己的需求存放这个对象。HotSpot将Class对象存放在方法区。

c. 加载阶段和连接阶段是交叉的

类加载过程中，必须按照如下顺序开始： 加载、连接、初始化，但结束顺序无所谓，因为由于每个步骤处理时间的长短不一就会导致有些步骤会出现交叉。

2、验证

验证是连接的第一步，它非常重要但不一定必要，如果所运行的代码已经被反复使用和验证过，那么可以使用-Xverify:none参数关闭，以缩短类加载时间。

2.1、验证的目的

验证是为了保证二进制字节流中的信息符合虚拟机规范，并没有安全问题。

2.2、验证的过程

2.2.1、文件格式验证

• 是否以魔数 0xCAFEBABE 开头
• 主、次版本号是否在当前虚拟机处理范围之内
• 常量池的常量是否有不被支持常量的类型（检查常量 tag 标志）
• 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
• CONSTANT_Utf8_info 型的常量中是否有不符合 UTF8 编码的数据
• Class 文件中各个部分文件本身是否有被删除的附加的其他信息

只有通过这个阶段的验证后，字节流才会进入内存的方法区进行存储，所以后面 3 个验证阶段全部是基于方法区的存储结构进行的，不再直接操作字节流。

加载开始前，二进制字节流还没进方法区，而加载完成后，二进制字节流已经存入方法区。而在文件格式验证前，二进制字节流尚未进入方法区，文件格式验证通过之后才进入方法区。也就是说，加载开始后，立即启动了文件格式验证，本阶段验证通过后，二进制字节流被转换成特定数据结构存储至方法区中，继而开始下阶段的验证和创建Class对象等操作。这个过程印证了：加载和验证是交叉进行的。

2.2.2、元数据验证

• 这个类是否有父类（除 java.lang.Object 之外）
• 这个类的父类是否继承了不允许被继承的类（final 修饰的类）
• 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法
• 类中的字段、方法是否与父类产生矛盾（覆盖父类 final 字段、出现不符合规范的重载）

本阶段对方法区中的字节码描述信息进行语义分析，确保其符合Java语法规范。

2.2.3、字节码验证

• 保证任意时刻操作数栈的数据类型与指令代码序列都鞥配合工作（不会出现按照 long 类型读一个 int 型数据）
• 保证跳转指令不会跳转到方法体以外的字节码指令上
• 保证方法体中的类型转换是有效的（子类对象赋值给父类数据类型是安全的，反过来不合法的）

这是整个验证过程中最复杂的一个阶段，这个阶段对类的方法体进行校验分析，保证校验类的方法在运行时不会做出危害虚拟机安全的事件。

2.2.4、符号引用验证

• 符号引用中通过字符串描述的全限定名是否能找到对应的类。
• 在指定类中是否存在符方法的字段描述符以及简单名称所描述的方法和字段。
• 符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问。

符号引用的目的是确保解析动作能正常执行，如果无法通过符号引用验证将抛出一个 java.lang.IncompatibleClass.ChangeError 异常的子类。如 java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError 等。

3、准备

准备阶段完成两件事情：

1. 正式为类变量分配内存

这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在 Java 堆中。

2. 设置类变量的初始值

这里所设置的初始值"通常情况"下是数据类型默认的零值（如0、0L、null、false等），比如定义了public static int value=1 ，那么 value 变量在准备阶段的初始值就是 0 而不是1（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 final 关键字public static final int value=1 ，那么准备阶段 value 的值就被赋值为 1。

数据类型的零值

4、解析

• 符号引用：符号引用以一组符号来描述所引用的目标，符号可以使任何形式的字面量。
• 直接引用：直接引用可以使直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。

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

5、初始化

初始化阶段就是执行类构造器clinit()的过程。

clinit()方法由编译器自动产生，收集类中static{}代码块中的类变量赋值语句和类中静态成员变量的赋值语句。在准备阶段，类中静态成员变量已经完成了默认初始化，而在初始化阶段，clinit()方法对静态成员变量进行显示初始化。

初始化过程的注意点

• clinit()方法中静态成员变量的赋值顺序是根据Java代码中成员变量的出现的顺序决定的。
• 静态代码块能访问出现在静态代码块之前的静态成员变量，无法访问出现在静态代码块之后的成员变量。
• 静态代码块能给出现在静态代码块之后的静态成员变量赋值。
• 构造函数init()需要显示调用父类构造函数，而类的构造函数clinit()不需要调用父类的类构造函数，因为虚拟机会确保子类的clinit()方法执行前已经执行了父类的clinit()方法。
• 如果一个类/接口中没有静态代码块，也没有静态成员变量的赋值操作，那么编译器就不会生成clinit()方法。
• 接口也需要通过clinit()方法为接口中定义的静态成员变量显示初始化。
• 接口中不能使用静态代码块。
• 接口在执行clinit()方法前，虚拟机不会确保其父接口的clinit()方法被执行，只有当父接口中的静态成员变量被使用到时才会执行父接口的clinit()方法。
• 虚拟机会给clinit()方法加锁，因此当多条线程同时执行某一个类的clinit()方法时，只有一个方法会被执行，其它的方法都被阻塞。并且，只要有一个clinit()方法执行完，其它的clinit()方法就不会再被执行。因此，在同一个类加载器下，同一个类只会被初始化一次。

四、类加载器

JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader：

• BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由C++实现，负责加载 %JAVA_HOME%/lib目录下的jar包和类或者或被 -Xbootclasspath参数指定的路径中的所有类。
• ExtensionClassLoader(扩展类加载器) ：主要负责加载目录 %JRE_HOME%/lib/ext 目录下的jar包和类，或被 java.ext.dirs 系统变量所指定的路径下的jar包。
• AppClassLoader(应用程序类加载器) :面向我们用户的加载器，负责加载当前应用classpath下的所有jar包和类。

五、双亲委派模型

1、双亲委派介绍

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

2、源码分析

protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先检查这个classsh是否已经加载过了
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    // c==null表示没有加载，如果有父类的加载器则让父类加载器加载
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        //如果父类的加载器为空 则说明递归到bootStrapClassloader了
                        //bootStrapClassloader比较特殊无法通过get获取
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {}
                if (c == null) {
                    //如果bootstrapClassLoader 仍然没有加载过，则递归回来，尝试自己去加载class
                    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;
        }
    }

3、双亲委派模型的作用

• 保证Java程序的稳定运行，可以避免类的重复加载。
• 保证了Java核心API不能被篡改。通过委托方式，不会去篡改核心API，即使篡改也不会去加载，即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。

4、破坏双亲委派模型

4.1、为什么需要破坏双亲委派？

因为在某些情况下受到加载范围的限制，父类加载器无法加载到需要的文件，就需要委托子类加载器去加载class文件。

举个例子，以JDBC中的Driver接口为例，由于Driver接口定义在jdk当中的，而其实现由各个数据库的服务商来提供，比如MySQL的mysql-connector-.jar中的Driver具体实现类。

那么问题就来了，DriverManager（也由jdk提供）要加载各个实现了Driver接口的实现类，然后进行管理，但是DriverManager由启动类加载器加载，只能加载JAVA_HOME的lib下文件，而其实现是由服务商提供的，由系统类加载器加载，这个时候就需要启动类加载器来委托子类来加载Driver实现，从而破坏了双亲委派。

4.2、破坏双亲委派的历史

第一次破坏：

由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则在JDK1.0时代就已经存在，面对已经存在的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。在此之前，用户去继承java.lang.ClassLoader的唯一目的就是为了重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法唯一逻辑就是去调用自己的loadClass()。

第二次破坏：

双亲委派很好地解决了各个类加载器的基础类的同一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的API，但世事往往没有绝对的完美。如果基础类又要调用回用户的代码，那该怎么办？

一个典型的例子就是JNDI服务，它的代码由启动类加载器去加载（在JDK1.3时放进去的rt.jar），但JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者的代码，但启动类加载器不“认识”这些代码。

为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，他将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文加载器，JNDI服务就可以使用它去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则，但这也是无可奈何的事情。Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI、JDBC、JCE、JAXB和JBI等。

第三次破坏：

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求导致的，“动态性”指的是代码热替换、模块热部署等，简单地说就是机器不用重启，只要部署上就能用。

OSGi实现模块化热部署的关键则是它自定义的类加载器机制的实现。每一个程序模块(Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当受到类加载请求时，OSGi将按照下面的顺序进行类搜索：

1）将java.＊开头的类委派给父类加载器加载。

2）否则，将委派列表名单内的类委派给父类加载器加载。

3）否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载。

4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。

5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。

6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。

7）否则，类加载器失败。

4.3、破坏双亲委派的实现

结合Driver来看下如何破坏双亲委派。

先从DriverManager开始看，平时我们通过DriverManager来获取数据库的Connection：

String url = "jdbc:mysql://localhost:3306/testdb";
Connection conn = java.sql.DriverManager.getConnection(url, "root", "root"); 

在调用DriverManager的时候，会先初始化类，调用其中的静态块：

static {
    loadInitialDrivers();
    println("JDBC DriverManager initialized");
}
private static void loadInitialDrivers() {
    ...
        // 加载Driver的实现类
        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {
                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                Iterator<Driver> driversIterator = loadedDrivers.iterator();
                try{
                    while(driversIterator.hasNext()) {
                        driversIterator.next();
                    }
                } catch(Throwable t) {
                }
                return null;
            }
        });
    ...
}

重点看下ServiceLoader.load(Driver.class)：

public static <S> ServiceLoader<S> load(Class<S> service) {
    // 获取当前线程中的上下文类加载器
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

可以看到，load方法调用获取了当前线程中的上下文类加载器，那么上下文类加载器放的是什么加载器呢？

public Launcher() {
	...
    try {
        this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
    } catch (IOException var9) {
        throw new InternalError("Could not create application class loader", var9);
    }
    Thread.currentThread().setContextClassLoader(this.loader);
    ...
}

在sun.misc.Launcher中，Launcher初始化的时候，会获取AppClassLoader，然后将其设置为上下文类加载器，而这个AppClassLoader，就是之前上文提到的系统类加载器Application ClassLoader，所以上下文类加载器默认情况下就是系统加载器。

继续来看下ServiceLoader.load(service, cl)：

public static <S> ServiceLoader<S> load(Class<S> service,
                                        ClassLoader loader){
    return new ServiceLoader<>(service, loader);
}
private ServiceLoader(Class<S> svc, ClassLoader cl) {
    service = Objects.requireNonNull(svc, "Service interface cannot be null");
    // ClassLoader.getSystemClassLoader()返回的也是系统类加载器
    loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
    acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
    reload();
}
public void reload() {
    providers.clear();
    lookupIterator = new LazyIterator(service, loader);
}

然后就是看LazyIterator迭代器：

private class LazyIterator implements Iterator<S>{
    // ServiceLoader的iterator()方法最后调用的是这个迭代器里的next
    public S next() {
        if (acc == null) {
            return nextService();
        } else {
            PrivilegedAction<S> action = new PrivilegedAction<S>() {
                public S run() { return nextService(); }
            };
            return AccessController.doPrivileged(action, acc);
        }
    }
    
    private S nextService() {
        if (!hasNextService())
            throw new NoSuchElementException();
        String cn = nextName;
        nextName = null;
        Class<?> c = null;
        // 根据名字来加载类
        try {
            c = Class.forName(cn, false, loader);
        } catch (ClassNotFoundException x) {
            fail(service,
                 "Provider " + cn + " not found");
        }
        if (!service.isAssignableFrom(c)) {
            fail(service,
                 "Provider " + cn  + " not a subtype");
        }
        try {
            S p = service.cast(c.newInstance());
            providers.put(cn, p);
            return p;
        } catch (Throwable x) {
            fail(service,
                 "Provider " + cn + " could not be instantiated",
                 x);
        }
        throw new Error();          // This cannot happen
    }
    
    public boolean hasNext() {
        if (acc == null) {
            return hasNextService();
        } else {
            PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
                public Boolean run() { return hasNextService(); }
            };
            return AccessController.doPrivileged(action, acc);
        }
    }
    
    
    private boolean hasNextService() {
        if (nextName != null) {
            return true;
        }
        if (configs == null) {
            try {
                // 在classpath下查找META-INF/services/java.sql.Driver名字的文件夹
                // private static final String PREFIX = "META-INF/services/";
                String fullName = PREFIX + service.getName();
                if (loader == null)
                    configs = ClassLoader.getSystemResources(fullName);
                else
                    configs = loader.getResources(fullName);
            } catch (IOException x) {
                fail(service, "Error locating configuration files", x);
            }
        }
        while ((pending == null) || !pending.hasNext()) {
            if (!configs.hasMoreElements()) {
                return false;
            }
            pending = parse(service, configs.nextElement());
        }
        nextName = pending.next();
        return true;
    }
}

至此，整个流程的代码就很清晰了，下面再上一张图表示整个流程：