第七章虚拟机类加载机制

最新推荐文章于 2024-07-27 17:23:20 发布

WindSearcher

最新推荐文章于 2024-07-27 17:23:20 发布

阅读量124

点赞数

分类专栏： Java虚拟机文章标签：虚拟机类加载机制

本文链接：https://blog.csdn.net/qq_40511966/article/details/96459145

版权

Java虚拟机专栏收录该内容

6 篇文章 0 订阅

订阅专栏

7.2 类加载的时机
1、类的整个生命周期分为哪7个阶段？

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

2、虚拟机规范严格规定了有且只有哪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的方法句柄，并且这个方法所对应的类没有进行初始化

以上一定会触发类进行初始化

    1. 当访问一个静态域，只有真正声明着了语的类才会被初始化(通过子类调用父类的静态变量，不会导致子类初始化，只会初始化父类)
     2. 通过数组定义类引用，不会触发此类的初始化
     3. 引用常量(static final)不会初始化类的初始化(常量在编译阶段就已经存入调用类的常量池中)
3、通过子类引用父类的静态字段。是否会导致子类的初始化？

不会，属于被动引用
4、当子类初始化时，是否要求其父类初始化？当一个接口初始化时，是否要求其父接口初始化？

要求，不要求

7.3 类加载过程

7.3.1 加载

“加载” 是 “类加载” 过程的一个阶段，切不可将二者混淆。

加载阶段由三个基本动作组成：

1) 通过类型的完全限定名，产生一个代表该类型的二进制数据流（根本没有指明从哪里获取、怎样获取，可以说一个非常开放的平台了）

2) 解析这个二进制数据流为方法区内的运行时数据结构

3) 创建一个表示该类型的java.lang.Class类的实例，作为方法区这个类的各种数据的访问入口。

通过类型的完全限定名，产生一个代表该类型的二进制数据流的几种常见形式：

    从zip包中读取，成为日后JAR、EAR、WAR格式的基础；
    从网络中获取，这种场景最典型的应用就是Applet;
    运行时计算生成，这种场景最常用的就是动态代理技术了；
    由其他文件生成，比如我们的JSP；

注意：非数组类加载阶段既可以使用系统提供的类加载器来完成，也可以由用户自定义的类加载器去完成。（即重写一个类加载器的loadClass（）方法）
数组类不适用类加载器

7.3.2 验证
1、验证阶段大致上会完成哪4个检验动作？

第一阶段（文件格式验证）：

第一阶段主要是验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理

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

等等…

只有通过了这个阶段的验证，字节流才会进入内存的方法区中进行存储，所以后面的三个验证阶段全部都是基于方法区的存储结构进行的，不会直接操作字节流
第二阶段(元数据验证阶段)

第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求

    这个类是否具有父类
    这个类的父类是否继承了不允许被继承的类
    如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法

…等等
第三阶段(字节码验证阶段)

第三阶段是整个验证阶段最复杂的，主要目的是通过数据流和控制流分析确定程序语义是否合法和符合逻辑。该阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件。

保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作
保证跳转指令不会跳转到方法体以外的字节码指令上

…等等
第四阶段(符号引用验证阶段)

第四个结点也就是最后的验证阶段，该校验发生在虚拟机将符号引用转换直接引用的时候，这个转化动作将在连接的第三阶段(解析阶段)发生。目的是对类自身以外的信息进行匹配性验证

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

7.3.3 准备
1、什么是类加载的准备阶段？

为类变量分配内存并设置类变量初始值阶段
2、重点：准备阶段对类的变量如何进行赋值？对类的常量如何进行赋值？

为正式的类变量分配内存并设置类变量初始值阶段，这里所说的初值是数据类型的零值，例如：

public static int value = 123,那value准备阶段过后初始值为0，因为这时候尚未执行任何Java方法，而把value赋值为123的putstatic指令是在程序编译后，存放在类构造器<clinit>()方法中，所以12是在初始化阶段才执行的

而对于类常量public static final value = 123,在准备阶段就会初始化为123

7.3.4 解析
1、什么是类加载的解析阶段？

虚拟机将常量池内的符号引用替换为直接引用的阶段
2、什么是符号引用？什么是直接引用？

符号引用：以一组符号来描述所引用的目标，符号可以是任何形式的字面量

直接引用：可以是直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄(这样在对象移动的情况下可以不改变引用，只需改变句柄和对象的引用关系)

7.3.5 初始化
1、初始化阶段是执行类构造器哪个方法的过程？
2、“类加载”过程的初始化对变量的赋值操作与类的准备阶段的变量的赋值操作以及类构造函数中变量的赋值操作三者有何不同？

7.4 类加载器
1、什么是类加载器？

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

7.4.1 类与类加载器
1、比较两个类是否“相等”，必须在什么前提下才有意义？

只有在同一类加载器加载的前提下，否则，即使这两个类来自同一个Class文件，被同一个虚拟机加载，只要两个类加载器不同，两个类必定不同。为什么要多个类加载器呢？首先为了灵活，其次如果一个应用服务器中有多个程序在跑，如果这些程序有同名类，那么该怎么区分，甚至有相同类的不同版本，又怎么区分，所以这就需要多个类加载器 2. 什么是线程上下文类加载器？线程上下文类加载器，并不是一个指定的类加载器，它通常默认是应用类加载器。在Java中的体现就是，可以通过Thread.currentThread.getContextClassLoader去获取当前这个线程的上下文类加载器，这个上下文类加载器默认是应用类加载器，可以通过Thread.currentThread.setContextClassLoader去修改. 它主要的作用就是让根类加载器无法加载到的类，可以通过线程去获取应用类加载器(通常)去人为加载。比如Java的底层提供了很多接口，比如数据库接口，但是具体的驱动实现是在第三方Jar中实现的，虚拟机根类加载器无法加载到，所以我们需要通过获取线程上下文类加载器，将第三方Jar包类加载到虚拟机中

这里演示下，不同的类加载器加载：

package com.xuangy.classloader;

import java.io.IOException;
import java.io.InputStream;


public class ClassLoaderTest {
    public static void main(String[] args) throws Exception {

        ClassLoader myClassLoader = 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 (IOException e) {
                    throw new ClassNotFoundException(name);
                }
            }
        };

        Object object = myClassLoader.loadClass("com.xuangy.classloader.ClassLoaderTest").newInstance();
        System.out.println(object.getClass());
        System.out.println(object instanceof com.xuangy.classloader.ClassLoaderTest);
    }
}

7.4.2 双亲委派模型
1、从java虚拟机角度来说，只存在哪两种不同的类加载器？

启动类加载器(C++语言实现)和所有其他的类加载器(Java实现)
2、从开发人员角度来说，类加载器还可以被更细致的划分为哪三种？

         - 启动类加载器（Bootstrap ClassLoader）：这个类将存放在\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名称不符合类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即。
        - 扩展类加载器（Extension ClassLoader）：这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载器\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
       - 应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中的默认类加载器。

3、什么是双亲委派模型？

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

类加载器的双亲委派模型在JDK1.2期间被引入并被广泛应用于之后几乎所有的Java程序中，但它并不是一个强制性的约束模型，而是Java设计者推荐给开发者的一种类加载实现方式。

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

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统将会出现多个不同的Object类，Java类型体系中最基本的行为也就无法保证，应用程序也将会变得一片混乱。

双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现确非常的简单，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法中，逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

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