JVM 类加载机制

最新推荐文章于 2023-02-25 21:22:58 发布

SinPingWu

最新推荐文章于 2023-02-25 21:22:58 发布

阅读量211

点赞数 1

分类专栏： JVM 深入理解JVM虚拟机文章标签： JVM 类加载机制

本文链接：https://blog.csdn.net/wxpqqa/article/details/82899378

版权

深入理解JVM虚拟机同时被 2 个专栏收录

6 篇文章 0 订阅

订阅专栏

JVM

4 篇文章 0 订阅

订阅专栏

JVM 类加载机制

首先明确两个问题：

在Class文件中描述的各种信息，最终都需要加载到虚拟机中之后才能被运行和使用。
java可以动态扩展的语言特性是依赖运行期动态加载和动态链接这两个特性实现的。

1、类生命周期

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定，这是由于为了支持Java语言的运行时绑定(动态绑定或晚期绑定)。这里所说的按部就班的开始，是指并不需要上个结束才进行下个阶段，通常会在一个阶段执行过程中，调用或激活另外一个阶段。

2、类加载过程

类加载的全过程包括：加载、验证、准备、解析、初始化这五个阶段。

2.1 加载

“加载”阶段是“类加载”过程的一个阶段，在加载阶段，虚拟机需要完成以下三件事情：

通过一个类的全限定名来获取定义此类的二进制字节流
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
在Java堆中生成一个代表这个类的java.lang.Object对象，作为方法区这些数据的访问入口

虚拟机规范的这三点要求实际上并不具体，因此虚拟机实现与具体应用的灵活度相当大。例如“通过一个类的全限定名来获取定义此类的二级制字节流”，并没有指明二进制字节流要从一个Class文件中获取，准确的说根本没有指明要从哪里获取及怎样获取。例如：

从Zip包中读取，这很常见，最终成为日后的jar、ear、war格式的基础
从网络中获取，这种场景最经典的应用就是Applet.
运行是计算生成，这种场景使用最多的就是动态代理技术。在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass来为特定接口生成*$Proxy的代理类的二进制字节流。
由其他文件生成，典型场景：JSP应用
从数据库中读取，这种场景比较少，有些中间件服务器(如SAP Netweaver)可以选择把程序安装到数据库中来完成程序代码在集群间的分发。
…

加载阶段可以使用系统提供的类加载器来完成，也可以自己定义类加载器，通过自己定义的类加载器可以控制字节流的获取方式。

2.2 验证

为什么进行验证

验证是虚拟机自身保护的一种方式。
虽然在纯粹Java代码中无法做到访问数组边界外的数据、将一个对象转型为它并未实现的类型、跳转到不存在的代码行等之类的事情。但是Class文件并不一定要用Java源码编译而来，如果通过纯粹的16进制编辑器编写Class文件，语义上是可以表达上述情形的。如果虚拟机不检查输入的字节流，很有可能因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。

不同的虚拟机对类验证的实现可能有所不同，但大致上都会完成下面四个阶段的检验过程：

文件格式验证

第一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这一阶段可能包括下面这些验证点：

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

该验证阶段主要目的是保证输入的字节流能正确的解析并存储于方法区内，格式上符合描述一个Java类型信息的要求。这阶段的验证是基于字节流进行的，经过了这个过程的验证之后，字节流才会进入内存的方法区中进行存储，所以后面的三个验证阶段都是基于方法区的储存结构进行的。

元数据验证

第二阶段是针对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，这个阶段可能包括的验证点如下：

这个类是否有父类(除了java.lang.Object之外，所有的类都应当有父类)。
这个类的父类是否继承了不允许被继承的类(被final修饰的类)。
如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
类中的字段、方法是否与父类产生了矛盾(例如覆盖了父类的final字段，或者出现了不符合规则的方法重载，例如方法参数都一致，但返回值类型却不同等)。

第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。

字节码验证

字节码验证主要工作是继续你数据流和控制流分析，这阶段将对类的方法体进行校验分析。主要目的是保证被校验类的方法在运行时不会做出危害虚拟机安全的行为，例如：

保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这样的现象：在操作栈中放置一个int类型的数据，使用时却按long类型来加载入本地变量表中。
保证跳转指令不会跳转到方法体以外的字节码指令上。
保证方法体中的类型转换是有效的。

符号引用验证

符号引用验证发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三个阶段–解析阶段中发生。符号引用可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性的校验，通常需要校验一下内容：

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

符号引用验证的目的是确保解析动作能够正常执行。
验证阶段对于虚拟机的类加载机制来说是个很重要的过程，但是不是必须的过程。

2.3 准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都在方法区中进行分配。关于JVM的运行时内存分配可见JVM运行时数据区域

类变量：指的是在类中用static修饰符修饰的变量，由new关键字创建的变量属于实例变量，实例变量在对象实例化时随着对象一起分配在Java堆中。

初始值通常情况下是数据类型的零值。假如：

public static int value = 1;

在准备阶段为value设置的初始值为0，真正为value赋值为1是由指令putstatic在编译完成后在类的构造方法()方法中进行。

特殊情况：如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值。假如：

public static final int value = 1;

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为1。

2.4 解析

解析阶段是虚拟机将常量池中的符号引用替换成直接引用的过程。

符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任意形式的字面量，只要使用时能无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标不一定已加载到内存中。
直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用与虚拟机实现的内存布局相关，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那么引用的目标必定在内存中存在。

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info和CONSTANT_InterfaceMethodref_info四种常量类型。

2.5 初始化

主动引用

虚拟机没有强制规定加载过程在什么时候进行，但是对于初始化阶段，虚拟机严格规定了有且只有四种情况必须立即对类进行初始化，而加载、验证、准备自然需要在此之前开始。

遇到new、 getstatic、putstatic或invokestatic这四种字节码指令时，如果类没有进行初始化，则需要对类进行初始化。生成这四条指令的最常见的Java代码场景是：使用new 关键字实例化对象的时候、读取或设置一个类的静态字段(被final修饰、已在编译期把结果放入常量池的静态字段除外)的时候，以及调用一个类的静态方法的时候
使用java.lang.reflect包的方法对类进行发射调用的时候，如果类没有进行过初始化，则需要先触发初始化
当初始化一个类的时候，如果发现其父类还没有进行初始化，则需要先触发父类的初始化
当虚拟机启动时，用户需要制定一个要执行的主类(包含main()方法的那个类)，虚拟机会先初始化这个主类。

被动引用

上述四种场景中的行为称为对一个类进行主动引用。除此之外所有引用类的方式，都不会触发初始化，称为被动引用。

被动引用实例一：

package org.fenixsoft.classloading；

/**
* 被动使用类字段演示一
* 通过子类引用父类的静态字段，不会导致子类初始化
**/
public class SuperClass {
    
    static {
        System.out.println("SuperClass init!");
    }
    
    public static int value = 123;
}

public class SubClass extends SuperClass {
    
    static {
        System.out.println("SubClass init!");
    }
}

/**
* 非主动使用类字段演示
**/
public class NotInitialization {
    
    public static void main(String[] args) {
        System.out.println(SubClass.value);
    }
}

上述代码运行后，只会输出 “SuperClass init!”，而不会输出"SubClass init!"。对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过子类来引用父类中定义的静态value，只会触发父类的初始化，而不会触发子类的初始化。至于是否要触发子类的加载和验证，在虚拟机中没有明确规定，这点取决于虚拟机的具体实现。对于Sun HotSpan虚拟机来说，可通过 -Xx:+TraceClassLoading参数看到此操作会导致子类的加载。

被动调用实例二：

package org.fenixsoft.clasloading;

/**
* 被动调用类字段演示二：
* 通过数组定义来引用类，不会触发此类的初始化
**/
public class NotInitialization {
    
    public static void main(String[] args) {
        SuperClass[] array = new SuperClass[10];
    }
}

这段代码运行后，不会触发SuperClass的初始化，但是会触发另外一个名为"[Lorg.fenixsoft.classloading.SuperClass"类的初始化，这个类是有虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作是由字节码指令newarray触发的。
这个类代表了一个元素类型为org.fenixsoft.classloading.SuperClass的一维数组，数组中应有的属性和方法(用户可直接使用的只有被修饰的public的属性和clone()方法)都实现在这个类里面。

被动调用实例三：

package org.fenixsoft.classloading;

/**
* 被动使用类字段演示三：
* 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
**/
public class ConstClass {

    static {
        System.out.println("ConstClass init!");
    }
    
    public static final String HELLO_WORLD = "Hello World";
}

/**
* 非主动使用类字段演示
**/
public class NotInitialization {
    
    public static void main(String[] args) {
        System.out.println(ConstClass.HELLO_WORLD);
    }
}

上述代码运行后，也没有输出“ConstClass init!”，这是因为虽然在Java源码中引用了ConstClass类中的常量HELLO_WORLD，但是在编译阶段将此常量的值“Hello world”存储到了NotInitialization类的常量池中，对常量ConstClass.HELLO_WORLD的引用实际转化为NotInitilizationl类对自身常量池的引用。也就是说实际上NotInitilization的Class文件中并没有ConstClass类的符号引用入口，这两个类在编译成Class文件后就不存在任何的联系。

接口初始化

接口的加载过程与类的加载过程稍微有些不同。接口也有初始化的过程，这点与类一致，上面代码都是用静态语句块 “static{}”来输出初始化信息的，而接口中不能使用“static{}”语句块，但编译器任然会为接口生成“()”类构造器，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是前面讲述的四种"有且仅有"需要开始初始化场景中的第三种：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成初始化，只有在真正使用到父接口的时候(如引用接口中定义的常量)才会初始化。

类构造器<clinit>()方法

在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。执行<clinit>()方法会对程序有如下影响：

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在静态语句块之后的变量，在静态语句块中可以赋值，但是不能访问。
<clinit>()方法与类的构造函数不同，他不需要显式的调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。
由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要先于子类的变量赋值操作。
<client>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
接口中不能使用静态语句块，但仍然可有变量初始化的赋值操作，因此接口与类一样都会生辰<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法，只有当父接口中定义的变量在子接口中被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，那就可能造成多个进程阻塞。

3、类加载器

实现“通过类的全限定名来获取描述此类的二进制字节流”这个动作的代码模块被称作类加载器。这个动作放到了Java虚拟机外部实现，以便让应用程序自己决定如何获取所需的类。

3.1 类与类加载器

在虚拟机中确定类的唯一性需要类本身和加载这个类的类加载器两个要素。也就是说，不同类加载器加载的同一个类在虚拟机中是不相等的，这个不相等可体现在Class对象的equals()方法、isAssignalbeFrom()方法、isInstance()方法、instanceof关键字的返回结果。如下代码演示不同类加载器对instanceof关键字的影响：

import java.io.InputStream;

public class ClassLoadTest {

    public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
        
        ClassLoader loader = new ClassLoader() {

            @Override
            public Class<?> loadClass(String name) throws ClassNotFoundException {
                try {
                    String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
                    InputStream is = getClass().getResourceAsStream(fileName);
                    if (is == null) {
                        return super.loadClass(name);
                    }
                    byte[] b = new byte[is.available()];
                    is.read(b);
                    return defineClass(name, b, 0, b.length);
                } catch(Exception e) {
                    throw new ClassNotFoundException(name);
                }
            }
        };

        Object obj = loader.loadClass("com.youye.test.ClassLoadTest").newInstance();

        System.out.println(obj.getClass());
        System.out.println(obj instanceof com.youye.test.ClassLoadTest);
    }
}

结果如下所示

class com.youye.test.ClassLoadTest
false

3.2 双亲委派模型

~~相当于Android中的事件传递机制。~~ 有所不同，可以查看我的这篇文章

类加载器大致可分为三种：

启动类加载器：采用C++编写，属于虚拟机自身一部分。加载<JAVA_HOME>/lib目录中的类库。启动类加载器无法被Java程序直接使用。
扩展类加载器：负责加载<JAVA_HOME>\lib\ext目录中的类库。
应用程序类加载器：也成为系统类加载器，负责加载用户路径(ClassPath) 上所指定的类库，开发者可以直接使用该类库，如果程序没有自定义类加载器，那么一般情况下这个就是程序中默认的类加载器。

双亲委派模型要求除顶层的启动类加载器外，其他的类加载器都要有父类加载器，这种父子类关系通过组合方式实现。如果一个类加载器收到加载类的请求，它通常将加载类的请求交给父类加载器去执行，每个层次的类加载都是如此，最终都会到顶层类加载器，只有当父类加载器反馈自己无法完成这个加载请求时，子类加载器才会尝试自己加载。

为什么采用双亲委派模型

保证类的唯一性。因为在Java虚拟机中确认一个类是否唯一需要该类本身和加载该类的类加载器，即使同一个类，采用不同的类加载器加载，结果是不相同的。可以采用instanceof进行校验。

SinPingWu

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JVM 类加载机制

JVM 类加载机制首先明确两个问题：在Class文件中描述的各种信息，最终都需要加载到虚拟机中之后才能被运行和使用。java可以动态扩展的语言特性是依赖运行期动态加载和动态链接这两个特性实现的。1、类生命周期加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定，这是由于为了支持Java语言的运行时绑定(动态绑定或晚期绑...
复制链接

扫一扫