从零开始的JVM学习(二):初识类加载子系统

200 阅读8分钟

前言

上一篇文章,初步了解了JVM,也提到了Java程序经过编译,转换成字节码文件,经过类加载子系统加载入内存区域在经过执行引擎和本地方法接口执行程序,这一篇将初步学习类加载子系统。

还是这个图,前面我们提到过:Java代码经过编译器编译成字节码文件,然后经过类加载子系统,经过类加载机制(包括:加载、连接【验证、准备、解析】、初始化阶段)加载入JVM内存区域。

这一篇我们从加载的时机、过程、类加载器和双亲委派模型等角度来学习类加载子系统。


类加载机制

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

类的生命周期包括如下阶段:加载->连接(验证、准备、解析)->初始化->使用->卸载。其中加载、连接、初始化加载、连接、初始化属于类加载的过程。

何时进行类加载

有且仅有以下流种情况必须立即对类进行“初始化”(而加载、验证、准备自然需要在此之前开始):

1、遇到new、getstatic、putstatic、invokestatic这四条指令,如果类型没有进行过初始化,则需要先触发其初始化阶段。

2、使用java.lang.reflect包的方法对类型进行反射调用时。

3、当初始化类时,如果发现其父类还没有进行过初始化。

4、当虚拟机启动时,用户需要指定一个要执行的主类,虚拟机会先初始化这个主类。

5、JDK7动态语言支持,四种方法句柄,并且没有经历过初始化。

6、当一个接口中定义了JDK8新加入的默认方法(被default关键字修饰的接口方法)时,如果这个接口的实现类发生了初始化,那该接口要在其之前被初始化。

类加载的过程

加载

在加载阶段,Java虚拟机需要完成以下三件事:

1.通过一个类的全限定名来获取定义此类的二进制字节流(注:二进制字节流不一定要从某个Class文件获取,JSP生成的、网络中获取等等都可以)

2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

3.在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据访问入口

加载阶段结束后,Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区中了,然后会在Java堆内存中实例化一个java.lang.Class类的对象,这个对象作为程序访问方法区中的类型数据的外部接口。

验证

验证是连接阶段的第一步,这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求,保证这些信息被当做代码运行后不会危害虚拟机自身的安全。验证阶段大致会完成下面四个阶段的检验动作:

1.文件格式验证:验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理。

2.元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合《Java语言规范》。

3.字节码验证:通过数据流分析和控制流分析,确定程序语义是合法的、符合逻辑得到。

4.符号引用验证:对类自身以外的各类信息进行匹配性校验,即该类是否缺少或者被禁止访问它的依赖的某些外部类、方法、字段等资源。

准备

连接阶段的第二步,准备阶段是正式为类中定义的变量(即静态变量,被static修饰的变量)分配内存并设置类变量初始值的阶段。

基本数据类型的零值如下:

数据类型零值
int0
long0L
short(short)0
char'\u0000'
byte(byte)0
booleanfalse
float0.0f
double0.0d
referencenull

但是,如果是被final修饰的变量因为在编译期就被分配了,所以在这个阶段会显式地进行初始化。

解析

解析是连接阶段的第三步,解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程。

事实上,解析操作往往会伴随着JVM在执行完初始化之后再执行。

符号引用:以一组符号来描述所引用的目标,符号可以使任何形式的字面量。

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

初始化

初始化是类加载过程的最后一步,直到此阶段,Java虚拟机才真正开始执行类中定义的Java程序代码。在准备阶段,变量已经被赋过一次系统要求的初始值,而在初始化阶段,则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。另一个更直接的角度来了解:初始化阶段就是执行类构造器<clinit>()方法的过程。

这一步将准备阶段为被赋零值的静态变量指定初始值,或者静态代码块中的值赋初始值。

类加载器和双亲委派模型

在JVM中,判定两个类是否是同一个类的标准是:同一个类、被同一个虚拟机加载、被同一个加载器加载。即一个类被一个JVM的同一个加载器加载才算是同一个类。

如图,类加载器有引导类加载器(Bootstrap ClassLoader)、拓展类加载器(Extension ClassLoader)、系统类加载器或者叫应用程序类加载器(Application ClassLoader)以及用户自定义类加载器(Custom ClassLoader)。

启动类加载器:负责加载存放在<JAVA_HOME>\lib目录,或者被-Xbootclasspath参数所指定的路径中存放的,而且是Java虚拟机就能够识别的(*.jar)类库加载到虚拟机的内存中。一般以java、javax、sun开头的都由启动类加载器加载。

扩展类加载器:负责加载<JAVA_HOME>\lib\ext目录中,或者被java.ext.dirs系统变量所指定的路径中所有的类库。

应用程序类加载器:负责加载用户类路径(ClassPath)上所有的类库,开发者同样可以直接在代码中使用这个类加载器。

启动类加载器由c++实现,getClassLoader()返回是null,而其他加载器都是Java实现,用户自定义类加载器需要继承ClassLoader实现。

双亲委派模型

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

代码实现,源码位置是java.lang.ClassLoader

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;
        }
}

代码的逻辑是:先检查请求加载的类型是否已经被加载过,若没有则调用父加载器的loadClass()方法,若父加载器为空则默认使用启动类加载器作为父加载器。加入父类加载器加载失败,抛出ClassNotFoundException异常的话,才调用自己的findClass()方法尝试进行解析。

双亲委派机制的优点:(1)避免类被重复加载。(2)保护程序安全,防止核心API被随意篡改。

但是有时候需要破坏双亲委派模型来完成一些特定的需求,比如JDBC各种数据库的实现包,在启动类加载器中有一些接口,但是具体实现是在CLassPath下的包中实现,这个时候就使用线程上下文类加载器(Thread Context ClassLoader)来解决这个问题,线程上下文类加载器接受到启动类加载器的反向委托,加载程序ClassPath路劲下的包,默认由应用程序类加载器加载这个类。