【JVM系列2】Java虚拟机类加载机制及双亲委派模式分析

2020-09-17  本文已影响0人  刀哥说Java

前言

上一篇我们粗略的介绍了一下Java虚拟机的运行时数据区，并对运行时数据区内的划分进行了解释，今天我们就会从类加载开始分析并会深入去看看数据是具体以什么格式存储到运行时数据区的。

编译

一个.java文件经过编译之后，变成了了.class文件，主要经过留下步骤：
.java -> 词法分析器 -> tokens流 -> 语法分析器 -> 语法树/抽象语法树 -> 语义分析器 -> 注解抽象语法树 -> 字节码生成器 -> .class文件 。
具体的过程不做分析，涉及到编译原理比较复杂，我们需要分析的是.class文件到底是一个什么样的文件？

Class文件

在Java中，每个类文件包含单个类或接口，每个类文件由一个8位字节流组成。所有16位、32位和64位的量都是通过分别读取2个、4个和8个连续的8位字节来构建的。

Java虚拟机规范中规定，Class文件格式使用一种类似于C语言的伪结构来存储数据，class文件中只有两种数据类型，无符号数和表。注意，class文件中没有任何对齐和填充的说法，所有数据都按照特定的顺序紧凑的排列在Class文件中。

Class文件结构

一个Class文件大致由如下结构组成：

ClassFile {
    u4             magic;//魔数
    u2             minor_version;//次版本号
    u2             major_version;//主版本号
    u2             constant_pool_count;//常量池数量
    cp_info        constant_pool[constant_pool_count-1];//常量池信息
    u2             access_flags;//访问标志
    u2             this_class;//类索引
    u2             super_class;//父类索引
    u2             interfaces_count;//接口数(2位，所以一个类最多65535个接口)
    u2             interfaces[interfaces_count];//接口索引 
    u2             fields_count;//字段数
    field_info     fields[fields_count];//字段表集合 
    u2             methods_count;//方法数
    method_info    methods[methods_count];//方法集合
    u2             attributes_count;//属性数
    attribute_info attributes[attributes_count];//属性表集合
}

这个结构在本篇文章里不会一一去解释，如果一一去解释的话一来显得很枯燥，二来可能会占据大量篇幅，这些东西脑子里面有个整体的概念，需要的时候再查下资料就好了，后面的内容中，如果遇到一些非常常用的类结构含义会进行说明，如魔数等还是有必要了解一下的。

Class文件示例

我们先任意写一个示例TestClassFormat.java文件：

package com.zwx.jvm;

public class TestClassFormat {

    public static void main(String[] args) {
        System.out.println("Hello JVM");
    }
}

然后进行编译，得到TestClassFormat.class，利用16进制打开：

在这里插入图片描述

因为Java虚拟机只认Class文件，所以必然会对Class文件的格式有严格的安全性校验。

魔数

每个Class文件中都会以一个4字节的魔数(magic)开头(u4)，即上图中的CA FE BA BE（咖啡宝贝）用来标记一个文件是不是一个Class文件。

主次版本号

魔数之后的2个字节(u2)就是minor_version(次版本号)，再往后2个字节(u2)记录的是major_version(次版本号)，这个还是非常有必要了解的，下面这个异常我想可能很多人都曾经遇到过：

java.lang.UnsupportedClassVersionError: com/zwx/demo : Unsupported major.minor version 52.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)

这个异常就是提示主版本号不对。
Java中的版本号是从45开始的，也就是JDK1.0对应到Class文件的主版本号就是45，而JDK8对应到的主版本就是52。
上图中类文件的主版本号(第7和第8位)00 34 ，转成10进制就是52，也就是这个类就用JDK1.8来编译的，然后因为我用的是JDK1.6来运行，就会报上面的错了，因为高版本的JDK能向下兼容低版本的Class文件，但是不能向上兼容更高版本的Class文件，所以就会出现上面的异常。

其他

其他还有很多校验，比如说常量池的一些信息和计数，访问权限(public等)及其他一些规定，都是按照Class文件规定好的顺序往后紧凑的排在一起。

类加载机制

.java文件经过编译之后，就需要将class文件加载到内存了了，并将数据按照分类存储在运行时数据区的不同区域。

一个类从被加载到内存，再到使用完毕之后卸载，总共会经过5大步骤(7个阶段)：
加载(Loading)，连接(Linking)，初始化(Initialization)，使用(Using)，卸载(Unloading) ,其中连接(Linking)又分为：验证(Verification),准备(Preparation)，解析(Resolution)。

在这里插入图片描述

加载(Loading)

加载指的是通过一个完整的类或接口名称来获得其二进制流的形式并将其按照Java虚拟机规范将数据存储到运行时数据区。

类的加载主要是要做以下三件事：

上面的第1步在虚拟机规范中并没有说明Class来源于哪里,也没有说明怎么获取，所以就会产生了非常多的不同实现方式，下面就是一些常用的实现方式：

执行Class(类或者接口)的加载操作需要一个类加载器，而一个良好的，合格的类加载器需要具有以下两个属性：

在Java中的类加载器不止一种，而对于同一个类，用不同的类加载器加载出来的对象是不相等的，那么Java是如何保证上面的两点的呢？
这就是双亲委派模式，Java中通过双亲委派模式来防止恶意加载，双亲委派模式也确保了Java的安全性。

双亲委派模式

双亲委派模式的工作流程很简单，当一个类加载器收到加载请求时，自己不去加载，而是交给它的父加载器去加载，以此类推，直到传递到最顶层类加载器，而只有当父加载器反馈说自己无法加载这个类，子加载器才会尝试去加载这个类。

在这里插入图片描述

上图中就是双亲委派模型，细心的人可能注意到，顶层加载器我使用了虚线来表示，因为顶层加载器是一个特殊的存在，没有父加载器，而且从实现上来说，也没有子加载器，是一个独立的加载器，因为扩展类加载器(Extension ClassLoader)和应用程序类加载器(Application ClassLoader)两个加载器从继承关系来看，是有父子关系的，均继承了URLClassLoader。但是虽然从类的继承关系来说启动类加载器(Bootstrap ClassLoader)没有子加载器，但是逻辑上扩展类加载器(Extension ClassLoader)还是会将收到的请求优先交给启动类加载器(Bootstrap ClassLoader)来进行优先加载。

破坏双亲委派模式

双亲委派模式并不是一个强制性的约束模型，只是一种推荐的加载模型，虽然大家大都遵守了这个规则，但是也有不遵守双亲委派模型的，比如：JNDI,JDBC等相关的SPI动作并没有完全遵守双亲委派模式

破坏双亲委派模式的一个最简单的方式就是：继承ClassLoader类，然后重写其中的loadClass方法(因为双亲委派的逻辑就写在了loadClass()方法中)。

常见异常

如果加载过程中发生异常，那么可能抛出以下异常(均为LinkageError的子类)：

ClassNotFoundException和NoClassDefFoundError

还有一个异常ClassNotFoundException可能也会经常遇到，这个看起来和NoClassDefFoundError很相似，但其实看名字就知道ClassNotFoundException是继承自Exception，而NoClassDefFoundError是继承自Error。

连接(Linking)

链接是获取类或接口类型的二进制形式并将其结合到Java虚拟机的运行时状态以便执行的过程。链包含三个步骤：验证，准备和解析。

注意：因为链接涉及到新数据结构的分配，所以它可能会抛出异常OutOfMemoryError。

验证(Verification)

这个步骤很好理解，类加载进来了肯定是需要对格式做一个校验，要不然什么东西都直接放到内存里面，Java的安全性就完全无法得到保障。
主要验证以下几个方面：

如果验证失败，会抛出一个异常VerifyError（继承自LinkageError）。

准备(Preparation)

准备工作是正式开始分配内存地址的一个阶段，主要为类或接口创建静态字段(类变量和常量)，并将这些字段初始化为默认值。
以下是一些常用的初始值：

数据类型 默认值
int 0
long 0L
short (short)0
float 0.0f
double 0.0d
char ‘\u0000’
byte (byte)0
boolean false
引用类型 null

需要注意的是，假设某些字段的在常量池中已经存在了，则会直接在春被阶段就会将其赋值。
如：

static final int i = 100;

这种被final修饰的会直接被赋初始值，而不会赋默认值。

解析(Resolution)

解析阶段就是将常量池中符号引用替换为直接引用的过程。在使用符号引用之前，它必须经过解析，解析过程中符号引用会对符号引用的正确性进行检查。

注意：因为Java是支持动态绑定的，有些引用需要等到具体使用的时候才会知道具体需要指向的对象，所以解析这个步骤是可以在初始化之后才进行的。

常见异常

解析过程中可能会发生以下异常：

符号引用

符号引用以一组符号来描述锁引用的目标，其中的符号可以是任何形式的字面量，只要根据符号唯一的定位到目标即可。比如说：String s = xx，xx就是一个符号，只要根据这个符号能定位到这个xx就是变量s的值就行。

直接引用

直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。对于同一个符号引用经过不同虚拟机转换而得到的直接饮用一般是不相同的。当有了直接引用之后，那么引用的目标必然已经存在于内存，所以这一步要在准备之后，因为准备阶段会分配内存，而这一步实际上也就是一个地址的配对的过程。

初始化(Initialization)

这个阶段就是执行真正的赋值，会将之前赋的默认值替换为真正的初始值，在这一步，会执行构造器方法。

那么一个类什么时候需要初始化？父类和子类的初始化顺序又是如何？

初始化顺序

在Java虚拟机规范中规定了5种情况必须立即对类进行初始化，主动触发初始化的行为也被称之为主动引用(除了以下5种情况之外，其余不会触发初始化的引用都称之为被动引用)。

注意：接口的初始化在第3点会有点不一样，就是当一个接口在初始化的时候，并不要求其父接口全部都初始化，只有在真正使用到父接口的时候(如调用接口中定义的常量)才会初始化。

初始化实战举例

下面我们来看一些初始化的例子：

package com.zwx.jvm;

public class TestInit1 {
    public static void main(String[] args) {
        System.out.println(new SubClass());//A-先初始化父类，后初始化子类
//        System.out.println(SubClass.value);//B-只初始化父类，因为对于static字段，只会初始化字段所在类
//        System.out.println(SubClass.finalValue);//C-不会初始化任何类，final修饰的数据初始化之前就会放到常量池
//        System.out.println(SubClass.s1);//D-不会初始化任何类，final修饰的数据初始化之前就会放到常量池
//        SubClass[] arr = new SubClass[5];//E-数组不会触发初始化
    }
}

class SuperClass{
  static {
        System.out.println("Init SuperClass");
    }
    static int value = 100;

    final static int finalValue = 200;

    final static String s1 = "Hello JVM";
}

class SubClass extends SuperClass{
    static {
        System.out.println("Init SubClass");
    }
}

因为new关键字会触发SubClass的初始化(主动引用情况2)，而其父类没有被初始化会先触发父类的初始化(主动引用情况3)

调用了类的静态常量(主动引用情况2)，虽然是通过子类调用的，但是静态常量却定义在父类，所以只会触发其父类初始化，因为静态属性的调用只会触发属性所在类

因为被final修饰的静态常量存在于常量池中，在连接的准备阶段就会将属性直接进行赋值了，不需要初始化类。

使用(Using)

经过上面五个步骤之后，一个完整的对象已经加载到内存中了，接下来在我们的代码中就可以直接使用啦。

卸载(Unloading)

当一个对象不再被使用之后，会被垃圾回收掉，垃圾回收会在JVM系列后续文章中进行介绍。

总结

本文主要介绍了Java虚拟机的类加载机制，相信看完这篇再结合上一篇对运行时数据区的讲解，大家对Java虚拟机的类加载机制的工作原理有了一个整体的认知，那么下一篇，我们会从更深层次的字节码上来更具体更深入的分析Java虚拟机的方法调用流程及方法重载和方法重写的原理分析。

请关注我，一起学习进步

上一篇：

【JVM系列1】深入分析Java虚拟机堆和栈及OutOfMemory异常产生原因

上一篇下一篇

猜你喜欢

热点阅读