第三部分 虚拟机执行子系统.md

Java jvm 深入理解 Java 虚拟机
960

第六章 类文件结构

6.2 无关性的基石

平台无关性和语言无关系：字节码

image20210717195251143.png

6.3 Class 类文件的结构

Class 文件是一组以 8 个字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在文件之中，中间没有添加任何分隔符，这使得整个 Class 文件中存储的内容几乎全部是程序运行的必要数据，没有空隙存在。当遇到需要占用 8 个字节以上空间的数据项时，则会按照高位在前的方式分割 成若干个8个字节进行存储。

Class 文件采用一种 伪结构 来存储数据，这种伪结构只有两种数据类型：

  • 无符号数：以 u1、u2、u4、u8 分别代表 1 个字节、2 个字节、4 个字节和 8 个字节的无符号数，可以描述数字、索引引用、数量或按照 UTF-8 编码构成的字符串。
  • 表由多个无符号数或者其他表作为数据项构成的复合数据类型，为了便于区分，所有表的命名 都习惯性地以 _info 结尾

整个 Class 文件本质上可以视作一张表，由一下数据项按顺序构成：

image20210717195828648.png

无论是无符号数还是表，当需要描述同一类型但数量不定的多个数据时，经常会使用一个前置的 容量计数器加若干个连续的数据项的形式，这时候称这一系列连续的某一类型的数据为某一类型的 集合。

6.3.1 魔数与 Class 文件的版本

Class 文件的魔数为 0xCAFEBABE ( 咖啡宝贝 )，在文件开头，为 1 个 u4，占 4 个字节。

紧接着是 Class 文件的版本号，为 2 个 u2，其中第一个 u2 为主要版本，第二个为次要版本。虚拟机必须要能运行之前版本的 Class 文件，也要拒绝运行之后版本的 Class 文件。

6.3.2 常量池

这部分有一个 u2 与一张 cp_info 表组成，第一个 u2 表示接下来 cp_info 表占用的字节数。

这里 u2 的计数是从 1 开始的，如果该值为 22，则代表常量池中有 21 项常量，其索引为 1 到 21，其中第 0 个索引代表 不引用常量池项目 。

常量池主要存放两大类常量：字面量 (Literal) 与 符号引用 (Symbolic References)

字面量包括：文本字符串，被声明为 final 的常量值

符号引用包括：

  • 被模块导出或开放的包 ( Package)
  • 类和接口的全限定名 ( Fully Qualified Name)
  • 字段的名称和描述符 ( Descriptor )
  • 方法的名称和描述符
  • 方法句柄和方法类型 ( Method Handle, Method Type, Invoke Dynamic )
  • 动态调用点和动态常量 ( Dynamically-Computed Call Site, Dynamically-Cmputed Constant )

常量池中每一项常量都是一个表，截止至 JDK13，常量表中共有 17 中不同类型的常量，表结构起始的第一位是个 u1 类型的标志位：

image20210717201311820.png

各常量说明：

image20210717203202330.png

image20210717203214586.png

image20210717203224179.png

3.3.3 访问标志

常量池结束后，紧接一个 u2 的无符号数代表访问标志 (access_flags)，

image20210717203336130.png

6.3.4 类索引、父类索引与接口索引集合

类索引（this_class）和父类索引（super_class）都是一个 u2 类型的数据，而接口索引集合 （interfaces）是一组 u2 类型的数据的集合，Class 文件中由这三项数据来确定该类型的继承关系。

类索引、父类索引和接口索引集合都按顺序排列在访问标志之后，类索引和父类索引用两个 u2 类 型的索引值表示，它们各自指向一个类型为 CONSTANT_Class_info 的类描述符常量，通过 CONSTANT_Class_info 类型的常量中的索引值可以找到定义在 CONSTANT_Utf8_info 类型的常量中的 全限定名字符串。

6.3.5 字段表集合

字段表（field_info）用于描述接口或者类中声明的变量。Java语言中的“字段”（Field）包括类级变 量以及实例级变量，但不包括在方法内部声明的局部变量。

image20210717204142172.png

image20210717204159279.png

image20210717204352974.png

对于数组类型，每一维度将使用一个前置的 [ 字符来描述，如一个定义为 java.lang.String[][] 类型 的二维数组将被记录成 [[Ljava/lang/String；，一个整型数组 int[] 将被记录成 [I 。

用描述符来描述方法时，按照先参数列表、后返回值的顺序描述，参数列表按照参数的严格顺序 放在一组小括号 () 之内。如方法 void inc() 的描述符为 ()V，方法 java.lang.String toString() 的描述符 为 ()Ljava/lang/String；，方法 int indexOf(char[]source，int sourceOffset，int sourceCount，char[]target， int targetOffset，int targetCount，int fromIndex) 的描述符为 ([CII[CIII)I。

6.3.6 方法表集合

Class 文件存储 格式中对方法的描述与对字段的描述采用了几乎完全一致的方式，方法表的结构如同字段表一样，依 次包括访问标志（access_flags）、名称索引（name_index）、描述符索引（descriptor_index）、属性表 集合（attributes）几项

image20210717204925684.png

image20210717204933837.png

6.3.7 属性表集合 (pass)

6.4 字节码指令简介 (pass)

第七章 虚拟机类加载机制

7.2 类加载时机

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载 （Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化 （Initialization）、使用（Using）和卸载（Unloading）七个阶段，其中验证、准备、解析三个部分统称 为连接（Linking）。

image20210717205827644.png

《Java虚拟机规范》 则是严格规定了有且只有六种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

  1. 遇到 new, getstatic, putstatic 或 invokestatic 这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化，有三种典型场景能生成这四条指令：
    • 使用 new 关键字实例化
    • 读取或设置一个类型的静态字段 ( 被 final 修饰，在编译器把值放入常量池的静态字段除外 )
    • 调用一个类型的静态方法
  2. 使用 java.lang.reflect 包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先出发其初始化
  3. 当初始化类的时候，如果其父类还没有进行过初始化，则需要先触发
  4. 当虚拟机启动时，用户需指定一个要执行的主类，虚拟机会首先初始化该类
  5. 当使用动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后解析结果为 REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial 四种类型的方法句 柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
  6. 当一个接口中定义了 default 方法时，如果有这个接口的实现类发生初始化，则该接口需要先初始化。

以上六种称为主动引用，此外其他情况称为被动引用都不会触发初始化，如：

  • 通过子类引用父类的静态字段，不会导致子类初始化
  • 通过数组定义引用类，不会触发类的初始化
  • 调用类的常量，不会触发定义常量的类的初始化

注意：一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化

7.3 类加载过程

7.3.1 加载

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

加载阶段既可以使用Java虚拟机里内置的引导类加 载器来完成，也可以由用户自定义的类加载器去完成，开发人员通过定义自己的类加载器去控制字节 流的获取方式（重写一个类加载器的 findClass() 或 loadClass() 方法），实现根据自己的想法来赋予应用 程序获取运行代码的动态性。

数组类的创建遵循以下规则：

  • 如果数组的组件类型（Component Type，指的是数组去掉一个维度的类型，注意和前面的元素类 型区分开来）是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组 C 将被标 识在加载该组件类型的类加载器的类名称空间上（这点很重要，在7.4节会介绍，一个类型必须与类加 载器一起确定唯一性）。
  • 如果数组的组件类型不是引用类型（例如 int[] 数组的组件类型为 int ），Java 虚拟机将会把数组 C 标记为与引导类加载器关联。
  • 数组类的可访问性与它的组件类型的可访问性一致，如果组件类型不是引用类型，它的数组类的 可访问性将默认为 public，可被所有的类和接口访问到。

类型数据妥善安置在方法区之后，会在Java堆内存中实例化一个 java.lang.Class 类的对象， 这个对象将作为程序访问方法区中的类型数据的外部接口。

加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段 尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的一部分，这两个阶段的开始时间仍然保持着固定的先后顺序

7.3.2 验证

  1. 文件格式验证

    • 魔数是否为 0xCAFEBABE
    • 主次版本号是否可接受
    • 常量池的常量中是否有不被支持的常量类型 ( tag 标志 )
    • 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
    • CONSTANT_Utf8_info 型的常量中是否有不符合 UTF-8 编码的数据
    • Class 文件中各个部分及文件本身是否有被删除的或附加的其他信息
    • 其他 ……

  2. 元数据验证

    对字节码描述的信息进行语义分析：

    • 这个类是否有父类
    • 这个类是否继承了不被允许继承的类
    • 如果这个类不是抽象类，是否实现了其父类或接口中的抽象方法
    • 类中的字段、方法是否与父类产生矛盾
    • 其他 ……

  3. 字节码验证

通过数据流分析和控制流分析，确定 程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型校验完毕以后，这阶段就要 对类的方法体（Class文件中的Code属性）进行校验分析，保证被校验类的方法在运行时不会做出危害 虚拟机安全的行为，例如：

  • 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似于 “ 在操作 栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中 ” 这样的情况。
  • 保证任何跳转指令都不会跳转到方法体以外的字节码指令上。
  • 保证方法体中的类型转换总是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全 的，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系、完全不相干的一个 数据类型，则是危险和不合法的。
  • 其他 ……

  1. 符号引用验证

    最后一个阶段的校验行为发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在 连接的第三阶段——解析阶段中发生。符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外 类、方法、字段等资源。本阶段通常需要校验下列内容：

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

7.3.3 准备

关于准备阶段，还有两个容易产生混淆的概念笔者需要着重强调，首先是这时候进行内存分配的 仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其 次是这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：

public static int value = 123;

那变量 value 在准备阶段过后的初始值为 0 而不是 123，因为这时尚未开始执行任何 Java 方法，而把 value 赋值为123的 putstatic 指令是程序被编译后，存放于类构造器()方法之中，所以把 value 赋值 为123 的动作要到类的初始化阶段才会被执行。

image20210717214943253.png

如果变量为 final 并且等号右边为字面量，则在准备阶段就会直接赋值，例如以下代码：

public static final int value = 132;

7.3.4 解析

解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用在第6章讲解Class 文件格式的时候已经出现过多次，在Class文件中它以CONSTANT_Class_info、 CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现，那解析阶段中所说的直接 引用与符号引用又有什么关联呢？

  • 符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何 形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引 用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同， 但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在《Java虚拟机规 范》的Class文件格式中。
  • 直接引用（Direct References）：直接引用是可以直接指向目标的指针、相对偏移量或者是一个能 间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚 拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在虚拟机 的内存中存在。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这 7 类符号引用进行。

7.3.5 初始化

执行类的 <clinit> 方法 ，该方法由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的 语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的。

Java 虚拟机会保证该类 <clinit> 方法执行前，其父类的该方法已经被执行。

如果一个类或接口中没有静态语句块，也没有对变量的赋值，则虚拟机可以不为该类生成 <clinit> 方法。

Java 虚拟机会保证一个类的 <clinit> 方法同时只能由一个线程执行，会隐式加锁。如果一个类该方法中有阻塞方法，则可能会造成多线程阻塞。同时，一个类只会被初始化一次，当多个线程同时执行 <clinit>，则在第一个执行该方法的线程执行结束后，其他线程并不会继续执行该方法。

7.4 类加载器

7.4.1 类与类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段。对于 任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每 一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相 等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

包括 Class 对象的 equals() , isAssignableFrom() , isInstance() 方法的返回结果，也包括 instanceof 。

比如如下代码：

package com.heyanle;

import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.InvocationTargetException;

/**
 * Created by HeYanLe on 2021/7/17 18:52.
 * https://github.com/heyanLE
 */
public class Main {

    public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException {
        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 (IOException e) {
                    throw new ClassNotFoundException(name);
                }
            }
        };
        Object object = loader.loadClass("com.heyanle.Main").getConstructor().newInstance();
        System.out.println(object instanceof Main);
    }

}

最终会打印 false 。

7.4.2 传统双亲委派模型

image20210717221103113.png

  • 启动类加载器 (Bootstrap Class Loader)： 加载存放在 <JAVA_HOME>\lib 目录中的，Java 虚拟机能识别的类，如 rt.jar。该加载器无法被 Java 程序直接引用，如果需要将加载请求委派给引导类加载器，则直接用 null 代替，这是一种约定规则。
  • 扩展类加载器 (Extension Class Loader)：该加载器路径为 sun.misc.Launcher$ExtClassLoder。它负责加载 <JAVA_HOME>\lib\ext 中，或被 java.ext.dirs 系统变量所指定的路径中的所有类库。
  • 应用程序类加载器 (Application Class Loader) ：路径为 sun.misc.Launcher$AppClassLoader，是 ClassLoader.getSystemClassLoader() 方法的返回值，负责加载用户类 (ClassPath) 中的所有类。如果应用程序中没有自定义过类加载器，一般情况就是默认的类加载器。

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

例如 java.lang.Object，存放在 rt.jar 中，在双亲委派模型下，可以保证在各种类加载器中的 Objefct 都为同一个类 。

双亲委派模型的实现：

/**
 * java.lang.ClassLoader#loadClass()
 */
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    // 首先，检查请求的类是否已经被加载过了
    Class c = findLoadedClass(name);
    if (c == null) {
        try {
            if (parent != null) {
            	c = parent.loadClass(name, false);
            } else {
            	c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
        // 如果父类加载器抛出ClassNotFoundException
        // 说明父类加载器无法完成加载请求
        }
        if (c == null) {
            // 在父类加载器无法加载时
            // 再调用本身的findClass方法来进行类加载
            c = findClass(name);
        }
    }
    if (resolve) {
    	resolveClass(c);
    }
    return c;
}

可以看出，当 classLoader 为 null 是，规定为 BootstrapClassLoader，当父类加载器无法加载该类时，才调用自己的 findClass 方法。

7.4.3 破坏双亲委委派模型

  1. 第一次为为了兼容 JDK1.2 之前的代码 ( 双亲委托模型在 JDK 1.2 中提出 )，并没有在 loadClass 方法中使用双亲委托模型，而是重新添加了 findClass 方法，并引导用户使用 findClass 方法。

  2. 第二次是由于该模型自身的缺陷，父类加载器加载器的类无法调用子类加载器中的类的代码，父类会重新加载该类，并与子类加载器中的类区分开。为了解决该问题，Java 团队引入了 线程上下文类加载器 (Thread Context Class.oader)。 可以使用 Thread.setContextClassLoader() 方法进行设置。

  3. 第三次是由于一些动态性的需求，比如：代码热替换 (Hot Swap), 模块热部署 (Hot Deployment) 等。

    比如， OSGi 为了实现模块化热部署定义了自己的类加载机制，不再是树状结构而是网状结构，并采用以下搜索规则：

    • 以 java.* 开头的类委派给父类加载器
    • 否则，将委派列表名单内的类，委派给父类加载器
    • 否则，将 Import 列表中的类，委派给 Export 这个类的 Bundle 的类加载器加载
    • 否则，查找当前 Bundle 的 ClassPath，使用自己的类加载器加载
    • 否则，查找类是否在自己的 Fragment Bundle 中，如果在，则委派给 Fragment Bundle 的类加载器加载
    • 否则，查找 Dynamic Import 列表的 Bundle，委派给对应 Bundle 的类加载器加载
    • 否则，加载失败

7.5 模块化系统

JDK 9 中引入，为了实现模块化的关键目标 —— 可配置的封装隔离机制，虚拟机对类加载加工做出了相应的调整

7.5.1 模块的兼容性

7.5.2 模块化下的类加载

模块化在 JDK 9 中更新。

扩展类加载器被 (Extension Class Loader) 被平台类加载器 (Platform Class Loader) 取代。同时 <JAVA_HOME>\lib\ext 目录也不复存在。

其次，平台类加载器和应用程序类加载器不在派生自 java.net.URLClassLoader，现在 启动类加载器，平台类加载器，应用程序类加载器全部继承于 jdk.internal.loader.BuiltinClassLoader，该类实现了新的模块化架构下类如何从模块中加载的逻辑。

此外，虽然 JDK9 源码中存在 BootClassLoader，但是为了保证兼容，还是以 null 来代指该加载器，而不会得到该实例。

image20210718090547465.png

除了传统的双亲委派机制，还引入了模块机制，在委派给父加载器之前，如果该类能归属到某个模块，则优先委派给负责那个模块的加载器完成加载。

  • 启动类加载器负责加载的模块

image20210718090736037.png

  • 平台类加载器负责加载的模块

image20210718090742485.png

  • 应用程序类加载器负责加载的模块

image20210718090748374.png

第八章 虚拟机字节码执行引擎

8.1 概述

物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层 面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执 行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。

8.2 运行时栈帧的结构

在编译Java程序源码的时候，栈帧中需要多大的局部变量表，需要多深的操作数栈就已经被分析计算 出来，并且写入到方法表的Code属性之中。换言之，一个栈帧需要分配多少内存，并不会受到程序 运行期变量数据的影响，而仅仅取决于程序源码和具体的虚拟机实现的栈内存布局形式。

image20210718091544566.png

8.2.1 局部变量表

局部变量表 ( Local Variables Table ) 是一组变量值的存储空间，用于存放方法参数和方法内定义的局部变量。在编译成 Class 文件时，就在该方法的 Code 属性的 max_locals 数据项中确定了该方法所需分配的局部变量表的最大容量。

局部变量表的容量以 变量槽 (Variable Slot) 为最小单位

《Java虚拟机规范》中并没有明确指出 一个变量槽应占用的内存空间大小，只是很有导向性地说到每个变量槽都应该能存放一个 boolean、 byte、char、short、int、float、reference或returnAddress 类型的数据，这 8 种数据类型，都可以使用 32 位 或更小的物理内存来存储，但这种描述与明确指出“每个变量槽应占用 32 位长度的内存空间”是有本质 差别的，它允许变量槽的长度可以随着处理器、操作系统或虚拟机实现的不同而发生变化，保证了即使在 64 位虚拟机中使用了 64 位的物理内存空间去实现一个变量槽，虚拟机仍要使用对齐和补白的手段 让变量槽在外观上看起来与 32 位虚拟机中的一致。

reference 类型表示对一个对象实例的引用，虚拟机实现至少应该能通过该引用做到两件事：

  1. 根据引用直接或间接地查找到对象在 Java 堆中的数据存放的起始地址或索引
  2. 根据引用直接或间接地查找到该对象所属数据类型在方法区中的存储的类型信息

returnAddress 类型目前很少见，是为了跳转等字节码指令服务的，古老的 Java 虚拟机曾经使用其来实现异常处理的跳转，现在已经改为异常表来替代。

一般来说，虚拟机都规定一个变量槽占 32 位，而对于 64 位的数据类型，则分配两个变量槽

当一个方法被调用时，Java 虚拟机会使用局部变量表来完成参数值到参数变量列表的传递过程，即实参到形参的转变。如果执行的是实例中的方法，则局部变量表中第 0 位索引的变量槽默认是用于传递方法所属对象的引用，方法中可通过关键字 this 来访问该变量。其余参数按照参数表顺序从第 1 位索引的变量槽开始占用。之后再根据方法内定义局部变量的顺序和作用域分配其余的变量槽。

变量槽复用：当方法中定义的变量作用域不覆盖整个方法时，虚拟机有可能会复用一些变量槽。不过这样会导致少量副作用，如某些情况会影响到 GC 行为：

某些虚拟机有专门做优化，这里只是举个例子。

public static void main(String[] args){
    {
        byte[] placeholder = new byte[64*1024*1024];
    }
    System.gc();
}

此次 GC 并不会回收该 64MB 内存，因为该变量的引用对应的 reference 类型的变量槽依然在局部变量表中，垃圾回收算法判断该处依然持有该引用，将其判断为不可回收。

public static void main(String[] args){
    {
        byte[] placeholder = new byte[64*1024*1024];
    }
    int a = 0;
    System.gc();
}

此时该 64MB 内存会被回收，因为编译时编译器判断 placeholder 数组变量与 a 变量处于不同作用域，采用复用变量槽的形式，在执行到 int a = 0; 时，此时局部变量表中 placeholder 对应的 reference 类型的变量槽已经被复用为 int 类型的。因此 垃圾回收算法 会判断该处不存在指向那块内存的引用，将其回收。

局部变量表是出于栈帧中的，是该方法运行时生成的，因此其中的变量如果没赋初值，则是完全不能使用的，这点与类成员变量不同。因此局部变量必须赋初值！

8.2.2 操作数栈

操作数栈 (Operand Stack) 常称为操作栈。其最大深度也在编译时被写入 Code 属性的 max_stacks 数据项。栈中每一个元素都可以是任意 Java 数据类型，32 位数据类型占栈容量为 1，64 位数据占用为 2 。

操作数栈服务于字节码指令，例如字节码指令 iadd 作用为取出栈顶两数 相加后 将结果入栈。（ 该指令只能用于 int 相加 ）

另外在概念模型中，两个不同栈帧作为不同方法的虚拟机栈的元素，是完全相互独立的。但是在 大多虚拟机的实现里都会进行一些优化处理，令两个栈帧出现一部分重叠。让下面栈帧的部分操作数 栈与上面栈帧的部分局部变量表重叠在一起，这样做不仅节约了一些空间，更重要的是在进行方法调 用时就可以直接共用一部分数据，无须进行额外的参数复制传递了

image20210718095505803.png

8.2.3 动态链接

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方 法调用过程中的动态连接（Dynamic Linking）。通过第6章的讲解，我们知道Class文件的常量池中存 有大量的符号引用，字节码中的方法调用指令就以常量池里指向方法的符号引用作为参数。这些符号 引用一部分会在类加载阶段或者第一次使用的时候就被转化为直接引用，这种转化被称为静态解析。 另外一部分将在每一次运行期间都转化为直接引用，这部分就称为动态连接。

8.2.4 方法返回地址

  1. 正常调用完成
  2. 异常调用完成

无论何种方法，在方法退出之后，都必须返回到最初方法被调用时的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层主调方法的执行状态。 一般来说，方法正常退出时，主调方法的 PC 计数器的值就可以作为返回地址，栈帧中很可能会保存这 个计数器值。而方法异常退出时，返回地址是要通过异常处理器表来确定的，栈帧中就一般不会保存这部分信息。

8.3 方法调用

方法调用的任务位确定被调用方法的版本 。

8.3.1 解析

所有方法调用的目标方法在Class文件里面都是一个常量池中的符 号引用，在类加载的解析阶段，会将其中的一部分符号引用转化为直接引用，这种解析能够成立的前 提是：方法在程序真正运行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不 可改变的。换句话说，调用目标在程序代码写好、编译器进行编译那一刻就已经确定下来。这类方法 的调用被称为解析（Resolution）。

在 Java 语言中符合要求的方法主要有 静态方法 和 私有方法两大类，一般会在类加载阶段进行解析。

调用不同类型的方法，字节码指令集里设计了不同的指令。在Java虚拟机支持以下5条方法调用字 节码指令，分别是：

  • invokestatic。用于调用静态方法。
  • invokespecial。用于调用实例构造器()方法、私有方法和父类中的方法。
  • invokevirtual。用于调用所有的虚方法。
  • invokeinterface。用于调用接口方法，会在运行时再确定一个实现该接口的对象。
  • invokedynamic。先在运行时动态解析出调用点限定符所引用的方法，然后再执行该方法。

前面4 条调用指令，分派逻辑都固化在Java虚拟机内部，而invokedynamic指令的分派逻辑是由用户设定的引 导方法来决定的。

8.3.2 分派

Java 具备 封装、继承和多态 等特征，在方法调用时有可能不是调用该类的方法，而是父类的方法，或者在调用过程中调用父类的方法，这里涉及到方法的分派。

  1. 静态分派 ( 虽然是静态分派，但分派本身就是个动态过程，只有解析调用才是真正意义上的静态 )

所有依赖静态类型来决定方法执行版本的分派动作，都称为静态分派。静态分派的最典型应用表 现就是方法重载。静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机来执行 的，这点也是为何一些资料选择把它归入“解析”而不是“分派”的原因。

  1. 动态分配

在运行期根据实 际类型确定方法执行版本的分派过程称为动态分派。

根据《Java虚拟机规范》， invokevirtual 指令的运行时解析过程大致分为以下几步：

  • 找到操作数栈顶第一个元素的对象的实际类型 C
  • 如果 C 中找到该方法，则进行权限访问，通过则直接调用，否则抛 java.lang.IllegalAccessError 异常
  • 否则，按继承关系从下到上依次对 C 的父类进行搜索和验证
  • 如果始终没找到，则抛出 java.lang.AbstractMethodError
  1. 单分派与多分派

宗量：方法的接收者与方法的参数

单分派：根据一个宗量对目标方法进行选择

多分派：根据多于一个宗量对目标方法进行选择

Java 语言是一门静态多分派、动态单分派的语言。

在静态分派阶段，根据方法的接收者和参数进行分派，这里的接收者指的是静态类型。

在动态分配阶段，此时方法的参数已经不会影响结果，因为方法参数在编译期已经确定，此时唯一存在的问题是调用父类的方法还是子类的方法，因此此时只根据方法的接收者进行分派。

  1. 虚拟机动态分派的实现

动态分派在运行时需要查询类型的元数据，虚拟机一般情况下会使用虚方法表来提升性能。

虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方 法表中的地址入口和父类相同方法的地址入口是一致的，都指向父类的实现入口。

Java 对象里的方法默认就是虚方法。此外，为了提升性能，虚拟机还会使用各种手段优化，比如：类型继 承关系分析（Class Hierarchy Analysis，CHA）、守护内联（Guarded Inlining）、内联缓存（Inline Cache）等多种非稳定的激进优化

8.4 动态类型语言支持

8.4.1 动态类型语言

动态类型语言：类型检查主体过程在运行期进行。

静态类型语言：类型检查主体过程在编译器进行。

8.4.2 Java 与动态类型

JDK 7 时 JSR-292 提案中 invokedy namic 指令以及 java.lang.invoke 包出现为 Java 在虚拟机层面提供了动态类型的支持。

8.4.3 java.lang.invoke 包

public class Main {

    static class ClassA {
        public void println(String s){
            System.out.println(s);
        }
    }

    private static MethodHandle getPrintlnMH(Object reveiver) throws Throwable{
        MethodType mt = MethodType.methodType(void.class, String.class);
        return lookup().findVirtual(reveiver.getClass(), "println", mt).bindTo(reveiver);
    }

    public static void main(String[] args) throws Throwable {
        getPrintlnMH(new ClassA()).invoke("d");
    }

}
  • Reflection ：模拟 Java 代码层次的方法调用
  • MethodHandle ：模拟字节码层次的方法调用（ 可用于其他编译成字节码的语言 ）

8.4.4 invokedynamic 指令 (pass)

8.5 基于栈的字节码解释执行引擎

8.5.1 解释执行

image20210719103831133.png

8.5.2 基于栈的指令集与基于寄存器的指令集

Javac 编译器输出的字节码指令流，基本上是一种基于栈的指令集架构（Instruction Set Architecture，ISA），字节码指令流里面的指令大部分都是零地址指令，它们依赖操作数栈进行工 作。与之相对的另外一套常用的指令集架构是基于寄存器的指令集，最典型的就是 x86 的二地址指令 集，如果说得更通俗一些就是现在我们主流 PC 机中物理硬件直接支持的指令集架构，这些指令依赖寄 存器进行工作。

基于栈的指令集：代码紧凑，可移植性好，执行较慢

基于寄存器的指令集：效率高，受硬件约束（寄存器的数量和编号）

8.5.3 基于栈的解释器执行过程 (pass)

第九章 类加载及执行子系统的案例与实战

9.2 案例分析

9.2.1 Tomcat：正统的类加载架构

image20210719165959553.png

9.2.2 OSGi：灵活的类加载器架构

9.2.3 字节码生成技术与动态代理

Proxy::newProxyInstance()方法会自动生成名为 $Proxy0.class 的代理类，并讲生成的字节码数组交给指定的类加载器加载，并返回一个实例。