java虚拟机系列（六）- 虚拟机类加载机制

最新推荐文章于 2024-11-16 11:39:55 发布

likaihai918

最新推荐文章于 2024-11-16 11:39:55 发布

阅读量425

点赞数

分类专栏： jvm系列文章标签：类加载机制 jvm

本文链接：https://blog.csdn.net/lixiaohai_918/article/details/101755502

版权

jvm系列专栏收录该内容

8 篇文章 1 订阅

订阅专栏

文章目录

java虚拟机系列（六）- 虚拟机类加载机制

java虚拟机系列（六）- 虚拟机类加载机制

一、概述

一个Java文件从编码完成到最终执行，一般主要包括两个过程

编译： 即把我们写好的java文件，通过javac命令编译成字节码，也就是我们常说的.class文件
运行： 则是把编译生成的.class文件交给Java虚拟机(JVM)执行。

而我们所说的类加载过程即是指JVM虚拟机把.class文件中类信息加载进内存，并进行解析生成对应的class对象的过程。

举个通俗点的例子来说，JVM在执行某段代码时，遇到了class A，然而此时内存中并没有classA的相关信息，于是JVM就会到相应的class文件中去寻找class A的类信息，并加载进内存中，这就是我们所说的类加载过程。

由此可见，JVM不是一开始就把所有的类都加载进内存中，而是只有第一次遇到某个需要运行的类时才会加载，且只加载一次。

二、类加载时机

类从加载到虚拟机内存开始到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用、卸载7个阶段。其中验证、准备、解析统称为连接，这7个阶段的发生顺序如下图所示。

在这里插入图片描述

加载、验证、准备、初始化、卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班的开始，而解析阶段则不一定：它在某些阶段可以在初始化阶段之后再开始，这是为了支持java语言的运行时绑定。

虚拟机规范没有强制约束在什么情况下开始类加载过程的第一个阶段：加载，而是由虚拟机的具体实现来自由把握。

但是对于初始化阶段，虚拟机规范则是严格规定有且只有5种情况必须对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

（1）遇到new、getstatic、putstatic或invokestatic这4字节码指令时。如果类没有经过初始化，则需要先触发其初始化。生成这4条指令的最常见的java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类静态字段值的时候（被final修饰，已经在编译期把结果放入常量池的静态字段除外）、调用一个类的静态方法的时候。
（2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行初始化，则需要先触发其初始化。
（3）当初始化一个类的时候，如果发现其父类还有初始化，则需要先触发其父类的初始化。
（4）当虚拟机启动的时候，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会先初始化这个主类。
（5）当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

除了这5种主动引用会触发类进行初始化之外，其余的被动引用都不会触发类的初始化。

接口的加载过程和类的加载过程有稍有一些不同，针对接口需要做一些特殊说明：接口也有初始化过程，但在上面的5种“有且仅有”需要初始化场景中，区别在第3种：当一个类在完成初始化时，要求其父类全部已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部完成了初始化，只有在真正使用到父接口的时候才会初始化（如引用接口中定义的常量）。

三、类的加载过程

虚拟机中类加载的全过程也就是加载、连接（验证、准备、解析）、初始化这5个阶段所执行的具体动作。

3.1 加载

在加载阶段，虚拟机要完成以下3件事情

（1）类加载器通过一个类的全限定名来获取定义此类的二进制字节流
（2）将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构
（3）然后根据字节流在堆中生成一个代表这个类的java.lang.Class对象作为方法区这个类的各种数据访问入口

“通过一个类的全限定名来获取定义此类的二进制字节流”，虚拟机规范没有指明二进制字节流必须从Class读取，也可以从例如：

可以从ZIP包中读取
网络中读取
运行时动态生成（动态代理）
由其他文件生成如jsp文件生成对应的Class文件
数据库中读取

加载阶段完成后，虚拟机外部的二进制字节流按照虚拟机所需的格式存储在方法区之中。然后在内存中实例化一个java.lang.Class类的对象（并没有明确规定是在java堆中，对于HotSpot虚拟机而言，Class对象比较特殊，是存储在方法区中），这个对象将作为程序访问方法区中这些类型数据的外部接口。

加载阶段与连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，可能连接阶段已经开始，但是这些夹在加载阶段之中进行的动作仍然属于连接阶段的内容。

3.2 连接

3.2.1验证

保证加载进来的java字节流符合虚拟机规范，不会危化虚拟机自身的安全。（对字节码、符号引用、元数据、文件格式等进行验证）

因为Class文件不一定要求从java源码编译而来，可以用任何途径产生，所以虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作

3.2.2 准备

主要为类变量赋予默认的初始值（比如private static int = 123，那么初始值为 0）

(当类字段的字段属性是ConstantValue常量值时，会在准备阶段初始化为指定的值，所以变量value被final修饰之后，value的值在准备阶段初始化为123而非0。
如：

public static final int value = 123;
)

3.2.3 解析

将常量池中的符号引用替换为直接引用的过程

符号引用在Class文件中它以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现。那解析阶段中的符号引用和直接引用的关系：

符号引用： 符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量（如类的权限定名、方法名和描述、字段名和描述），只要能无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中。
直接引用： 直接引用是可以直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄（可以理解为目标的内存地址）。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同的虚拟机上翻译出来的直接引用一般不会相同。如果有直接引用，那么引用的目标必定已经存在内存中。

3.3 初始化

（1）主要是对类变量进行初始化（比如 a = 123）。
（2）初始化阶段是执行类构造器()方法的过程。
（3）父类的初始化，类静态变量和静态代码块的初始化等。

类构造器()方法的执行过程中可能会影响程序运行行为的特点和细节：

()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}）中的语句合并产生，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在在静态语句块之前的变量，对于定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。
()方法和类的构造函数（或者说实例构造器()方法）不同，它不需要显示的调用父类构造器，虚拟机会保证在子类()方法执行之前，父类()方法已经执行完毕。因为在虚拟机中第一个被执行的()方法的类肯定是java.lang.Object。
由于父类的()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的地变量赋值操作。如下代码清单，变量B的值是2而不是1。

public class JvmLoadParent {
    public static int A =  1;
    static {
        A = 2;
    }
}

public class JvmLoadChild extends JvmLoadParent {
    public static int B = A;
}

public class JvmLoadMain {
    public static void main(String[] args)
    {
        System.out.println(JvmLoadChild.B);
    }
}

方法对于类或者接口来说并不是必必需的，如果一个类中没有静态语句块，也就没有对变量的赋值操作，那么编译器可以不为这个类生成()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样，都会生成方法。但是接口与类不同的是执行接口的方法不需要先执行父接口的方法。只有当父接口中定义的变量使用时，父接口才会初始化，另外，接口的实现类在初始化时也一样不会执行接口的方法。
虚拟机会保证一个类的方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的方法，其它线程都需要阻塞等待，直到活动线程执行方法完毕。如果一个类在方法中有耗时很长的操作，就可能造成多个线程的阻塞，在实际应用中这种阻塞往往是很隐蔽的。

四、类加载器

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。

4.1 类与类加载器

类加载器用于实现类的加载动作，比较两个类是否“相等”，就这两个类是否被同一个类加载器加载。否则，哪怕来自同一个Class文件，被同一个虚拟机加载，但不是被同一个类加载器加载，那么两个类也必定不相等。

这里的“相等”，包括代表类的Class对象的equals()方法，isInstance()方法返回的结果等的判定情况。

4.1.1 从虚拟机角度看类加载器

从虚拟机的角度来讲，只存在两种不同的类加载器：

一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分。
另一种就是所有其它的类加载器，这些类加载器都由java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

4.1.2 从java开发人员角度看类加载器

从java开发人员的角度来看，类加载器还可以划分得更细致一些，分为系统提供的 3 种类加载器：

启动类加载器（Bootstrap ClassLoader）： 启动类加载器使用C++语言实现，是虚拟机自身的一部分。它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中（启动类加载器根据文件名识别，名字不符合的类库即使放在lib目录下也是无用的，出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类）。
扩展（Extension）类加载器： 扩展类加载器是由sun.misc.Launcher$ExtClassLoader类实现的，由Java语言实现的，是Launcher的静态内部类，它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库，开发者可以直接使用扩展类加载器。
系统（System）类加载器： 也叫应用程序类加载器，这个类加载器是由sun.misc.Launcher$AppClassLoader实现的。它负责用户类路径（Classpath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，这个就是程序中默认的类加载器。

还有两种是用户自定义类加载器以及线程上下文类加载器，这里暂不表述。

4.2 双亲委派模型

应用程序都是由启动类加载器（Bootstrap ClassLoader）、扩展（Extension）类加载器、系统（System）类加载器这三种类加载器进行加载的，如果有必要，还可以加入自己定位的类加载器。这些类加载器的关系如下图所示。

在这里插入图片描述

类加载器之间的这种层级关系称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里的类加载器之间的父子关系一般不会以继承的关系来实现，而是使用组合关系来复用父加载器的代码。

双亲委派模型的工作过程： 如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个类加载请求委派给父类加载器去完成，每个层次的类加载器都是如此，因此所有的类加载请求最终都应该传到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围没有找到所需的类）时，子加载器才会尝试自己去加载。

双亲委派模型对于保证java程序的稳定运作很重要。如果用户自定义一个系统中已经存在的类如java.lang.Object类，将此类放在程序的ClassPath目录下，那么系统将会出现多个不同的Object类，java类型体系中最基础的行为就无法保证，应用程序也将变得一片混乱。而双亲委派模型保证了每个类最终都只会受到一个类加载器加载而不是多个。

实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中，代码如下。

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先，检查请求的类是否被加载过
            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
                    // 说明父类加载器无法完成加载请求
                }

                if (c == null) {
                    // 在父类加载器无法加载请求的时候
                    // 再调用本加载器的findClass方法来进行类加载
                    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;
        }
    }

类加载器去检查一个类时，先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空，则默认使用启动类加载器作为父类加载器。如果父类加载失败抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

参考资料：《深入理解java虚拟机》