JVM_虚拟机执行子系统

最新推荐文章于 2022-08-01 16:45:23 发布

Giagor

最新推荐文章于 2022-08-01 16:45:23 发布

阅读量997

点赞数

文章标签： java虚拟机

本文链接：https://blog.csdn.net/giagor/article/details/121940621

版权

本篇为《深入理解Java虚拟机第3版》读书笔记

文中，《Java虚拟机规范》简称《规范》

类文件结构

平台无关性和语言无关性的基石：Java虚拟机和字节码存储格式

平台无关性：Java虚拟机可以运行在各种不同的硬件平台和操作系统上，这些虚拟机都可以载入和执行同一种平台无关的字节码，从而实现程序的“一次编译，到处运行”
语言无关性：Java虚拟机不与包括Java语言在内的任何程序语言绑定，它只与“Class文件”这种特定的二进制文件格式所关联，Class文件中包含了Java虚拟机指令集、符号表以及若干其他辅助信息

在Java发展的过程中，Class文件结构一直处于一个相对比较稳定的状态，Class文件的各个数据项目严格按照顺序紧凑地排列在文件之中，中间没有添加任何分隔符。Class文件格式如下

magic：魔数
minor_version/major_version：版本号
constant_pool_count/constant_pool：常量池相关
access_flags：访问标志
this_class：类索引
super_class：父类索引
interfaces_count/interfaces：接口相关
fields_count/fields：字段相关
methods_count/methods：方法相关
attributes_count/attributes：属性相关

部分属性

属性_Code属性：

其中「code」一栏，表示的就是字节码指令

属性_ConstantValue属性：

ConstantValue属性的作用是通知虚拟机自动为静态变量赋值。只有被static关键字修饰的变量（类变量）才可以使用这项属性。类似“int x=123”和“static int x=123”这样的变量定义在Java程序里面是非常常见的事情，但虚拟机对这两种变量赋值的方式和时刻都有所不同。对非static类型的变量（也就是实例变量）的赋值是在实例构造器()方法中进行的；而对于类变量，则有两种方式可以选择：在类构造器()方法中或者使用ConstantValue属性。目前Oracle公司实现的Javac编译器的选择是，如果同时使用final和static来修饰一个变量（按照习惯，这里称“常量”更贴切），并且这个变量的数据类型是基本类型或者java.lang.String的话，就将会生成ConstantValue属性来进行初始化；如果这个变量没有被final修饰，或者并非基本类型及字符串，则将会选择在()方法中进行赋值。

使用ConstantValue属性进行初始化，发生在「类加载过程-准备阶段」，后面有提到

虽然有final关键字才更符合“ConstantValue”的语义，但《Java虚拟机规范》中没有强制要求字段必须设置ACC_FINAL标志，只要求有ConstantValue属性的字段必须设置ACC_STATIC标志而已，对final关键字的要求是Javac编译器自己加入的限制。而对ConstantValue的属性值只能限于基本类型和String这点，其实并不能算是什么限制，这是理所当然的结果。因为此属性的属性值只是一个常量池的索引号，由于Class文件格式的常量类型中只有与基本属性和字符串相对应的字面量，所以就算ConstantValue属性想支持别的类型也无能为力。ConstantValue属性的结构如表6-23所示。

JVM_虚拟机执行子系统_3

从数据结构中可以看出ConstantValue属性是一个定长属性，它的attribute_length数据项值必须固定
为2。constantvalue_index数据项代表了常量池中一个字面量常量的引用，根据字段类型的不同，字面
量可以是CONSTANT_Long_info、CONSTANT_Float_info、CONSTANT_Double_info、CONSTANT_Integer_info和CONSTANT_String_info常量中的一种。

属性_Synthetic属性：

Synthetic属性代表此字段或者方法并不是由Java源码直接产生的，而是由编译器自行添加的。所有由不属于用户代码产生的类、方法及字段都应当至少设置Synthetic属性或者ACC_SYNTHETIC标志位中的一项，唯一的例外是实例构造器“()”方法和类构造器“()”方法。

属性_Signature属性：

Signature属性是在JDK5新增的，任何类、接口、初始化方法或成员的泛型签名如果包含了类型变量（Type Variable）或参数化类型（ParameterizedType），则Signature属性会为它记录泛型签名信息。

之所以要专门使用这样一个属性去记录泛型类型，是因为Java语言的泛型采用的是擦除法实现的伪泛型，字节码（Code属性）中所有的泛型信息编译（类型变量、参数化类型）在编译之后都通通被擦除掉。使用擦除法的好处是实现简单，运行期也能够节省一些类型所占的内存空间。但坏处是运行期就无法像C#等有真泛型支持的语言那样，将泛型类型与用户定义的普通类型同等对待，例如运行期做反射时无法获得泛型信息。Signature属性就是为了弥补这个缺陷而增设的，现在Java的反射API能够获取的泛型类型，最终的数据来源也是这个属性。

类加载机制

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

与那些在编译时需要进行连接的语言不同，在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略让Java语言进行提前编译会面临额外的困难，也会让类加载时稍微增加一些性能开销，但是却为Java应用提供了极高的扩展性和灵活性，Java天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。

后面提到的「Class文件」并非特指某个存在于具体磁盘中的文件，而应当是一串二进制字节流，无论其以何种形式存在，包括但不限于磁盘文件、网络、数据库、内存或者动态产生等。

类的生命周期

类的生命周期会经历「加载、验证、准备、解析、初始化、使用、卸载」七个阶段
图中列出的各个步骤，并不是说一个阶段完成后，才能开始下一个阶段，这些阶段有一些是互相交叉地混合进行的，会在一个阶段执行的过程中调用、激活另一个阶段。但是「加载、验证、准备、初始化、卸载」这五个阶段开始的顺序是确定的，类型的加载过程必须按照这种顺序按部就班地开始，「解析」阶段既有可能在「初始化」之前开始，也可能在「初始化」之后再开始，在「初始化」阶段之后再开始，是为了支持Java语言的运行时绑定特性

关于什么时候开始第一个阶段「加载」，《规范》并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握，对于「初始化」阶段，《规范》则是严格规定了有且只有六种情况必须立即对类进行「初始化」（而「加载、验证、准备」自然需要在此之前开始）：

遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。能够生成这四条指令的典型Java代码场景有：
- 使用new关键字实例化对象的时候
- 读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候
- 调用一个类型的静态方法的时候
使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化
当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类
当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化
当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化

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

书上有个例子挺好的，关于static final的

/**
* 被动使用类字段演示三：
* 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化
**/
public class ConstantClass {
    static {
        System.out.println("ConstantClass init!");
    }

    public static final String HELLOWORLD = "hello world";
}

public class NotInitialization {
    public static void main(String[] args) {
        System.out.println(ConstantClass.HELLOWORLD);
    }
}

输出结果：hello world

在编译阶段通过常量传播优化，已经将此常量的值“helloworld”直接存储在NotInitialization类的常量池中，以后NotInitialization对常量ConstClass.HELLOWORLD的引用，实际都被转化为NotInitialization类对自身常量池的引用了。也就是说，实际上NotInitialization的Class文件之中并没有ConstClass类的符号引用入口，这两个类在编译成Class文件后就已不存在任何联系了。

接口的加载过程与类加载过程稍有不同，书P266.

类加载的过程

加载

这个是「类加载」的第一个阶段，完成三件事情

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

这个阶段的"通过一个类的全限定名来获取定义此类的二进制字节流"，既可以使用Java虚拟机里内置的引导类加载器来完成，也可以由用户自定义的类加载器去完成，开发人员通过定义自己的类加载器去控制字节流的获取方式

加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，比如「文件格式验证」是基于二进制字节流进行的，只有通过了「文件格式验证」，字节流才被允许进入Java虚拟机内存的方法区中进行存储

验证

该阶段的目的是确保Class文件的字节流中包含的信息符合《规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全

从代码量和耗费的执行性能的角度上讲，验证阶段的工作量在虚拟机的类加载过程中占了相当大的比重，验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证和符号引用验证

文件格式验证

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

是否以魔数0xCAFEBABE开头
主、次版本号是否在当前Java虚拟机接受范围之内
…(书P269)

该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证之后，这段字节流才被允许进入Java虚拟机内存的方法区中进行存储，所以后面的三个验证阶段全部是基于方法区的存储结构上进行的，不会再直接读取、操作字节流了。

元数据验证

该阶段对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要求，可能包括的验证点如下

这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）
这个类的父类是否继承了不允许被继承的类（被final修饰的类）
…书P269

该验证阶段的主要目的是对类的元数据信息进行语义校验，保证不存在与《Java语言规范》定义相悖的元数据信息

字节码验证

该阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的，这阶段会对类的方法体（Class文件中的Code属性）进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为，例如

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

由于数据流分析和控制流分析的高度复杂性，Java虚拟机的设计团队为了避免过多的执行时间消耗在字节码验证阶段中，在JDK 6之后的Javac编译器和Java虚拟机里进行了一项联合优化，把尽可能多的校验辅助措施挪到Javac编译器里进行。具体做法是给方法体Code属性的属性表中新增加了一项名为StackMapTable的新属性，这项属性描述了方法体所有的基本块（Basic Block，指按照控制流拆分的代码块）开始时本地变量表和操作栈应有的状态，在字节码验证期间，Java虚拟机就不需要根据程序推导这些状态的合法性，只需要检查StackMapTable属性中的记录是否合法即可。这样就将字节码验证的类型推导转变为类型检查，从而节省了大量校验时间

到了JDK7，对于主版本号大于50（对应JDK6）的Class文件，使用类型检查来完成数据流分析校验则是唯一的方式

符号引用验证

这个阶段的校验行为发生在「解析」阶段，「解析」阶段是虚拟机将符号引用转化为直接引用的时候

符号引用和直接引用的概念：JVM里的符号引用如何存储？- 知乎.

参考RednaxelaFX的回答，文章没完全看懂，但有了个大概的概念

符号引用：在Class文件里的的实态是，带有类型（tag） / 结构（符号间引用层次）的字符串，用文本形式来表示引用关系
直接引用：是JVM所能直接使用的形式，它既可以表现为直接指针，也可能是其它形式，关键点不在于形式是否为“直接指针”，而是在于JVM是否能“直接使用”这种形式的数据

书P273对符号引用和直接引用的描述

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

对于「符号引用验证」，个人理解该阶段的目的是去检查，Class文件的常量池中的各种符号引用所指向的资源是否缺少、是否可访问到，本阶段通常需要校验下列内容

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

「符号引用验证」的主要目的是确保解析行为能正常执行.

准备

该阶段是为类变量（静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段

注意几点

进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中
设置类变量初始值有两种情况
- 第一种：在「类文件结构-部分属性-Code属性」的笔记里，提到什么情况下变量会有ConstantValue属性，如果该类变量有对应的ConstantValue属性，那么在「准备」阶段，就使用ConstantValue为变量进行初始化，后面的中就不用在为该类变量赋值了
- 第二种：变量没有对应的ConstantValue属性，这种情况下就在「准备」阶段为静态变量赋零值，在后面的类构造方法，才会为静态变量赋程序定义的值

解析

解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程，可以在类被加载器加载时就对常量池中的符号引用进行解析，也可以等到一个符号引用将要被使用(一些字节码指令如getfield、getstatic…)前才去解析它，取决于虚拟机的实现。

解析阶段要对可访问性进行检查，即前面提到的「符号引用验证」，在JDK9引入模块化后，还需考虑模块间的访问权限，书P274.

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这7类符号引用进行，分别对应于常量池的CONSTANT_Class_info、CON-STANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info、CONSTANT_Dyna-mic_info和CONSTANT_InvokeDynamic_info 8种常量类型，对于这8种常量，书上先讲解了前4种引用的解析过程，分别是

类或接口的解析
字段解析
方法解析
接口方法解析

对于后4种，因为和动态语言的支持有关，放在第8章介绍

初始化

这里在Java语言的环境下进行讨论

初始化阶段就是执行类构造器()方法的过程。()并不是程序员在Java代码中直接编写的方法，它是Javac编译器的自动生成物

摘抄书P277

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

类加载器

「类加载的过程-加载」阶段的"通过一个类的全限定名来获取定义此类的二进制字节流"，实现这个动作的代码称为「类加载器」

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

这里所指的"相等"，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括了使用instanceof关键字做对象所属关系判定等各种情况。

这里演示不同的类加载器对instanceof关键字运算的结果的影响

public class ClassLoaderTest {
    public static void main(String[] args) throws Exception {
        ClassLoader myLoader = new ClassLoader() {
            @Override
            public Class<?> loadClass(String name) throws ClassNotFoundException {
                try{
                    //ClassLoaderTest.class
                    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 obj = myLoader.loadClass("clazz.classloading.ClassLoaderTest").
            						newInstance();

        System.out.println(obj.getClass());
        System.out.println(obj instanceof clazz.classloading.ClassLoaderTest);
 	    System.out.println(obj.getClass().equals(
           				 Class.forName("clazz.classloading.ClassLoaderTest")));
    }
}

输出结果

class clazz.classloading.ClassLoaderTest
false
false

instanceof返回了false：这是因为Java虚拟机中同时存在了两个ClassLoaderTest类，一个是由虚拟机的应用程序类加载器所加载的，另外一个是由我们自定义的类加载器加载的，虽然它们都来自同一个Class文件，但在Java虚拟机中仍然是两个互相独立的类，做对象所属类型检查时的结果自然为false

equals返回了false：既然在Java虚拟机中表现为两个互相独立的类，那么代表类的Class对象，当然也不是同一个对象

这段代码是书P280给出的一个例子，但是这段代码在自定义类加载器时重写的是loadClass，而不是重写findClass，这样做不是很好，后面会提到

双亲委派模型

自JDK 1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构，尽管这套架构在Java模块化系统出现后有了一些调整变动，但其主体结构依然未改变，这里先讨论模块化之前的三层类加载器架构

先上图

启动类加载器（Bootstrap Class Loader）：前面已经介绍过，这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可

怎么委派？

启动类加载器和引导类加载器是一个意思.

扩展类加载器（Extension Class Loader）：这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。根据“扩展类加载器”这个名称，就可以推断出这是一种Java系统类库的扩展机制，JDK的开发团队允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能，在JDK9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件
应用程序类加载器（Application Class Loader）：这个类加载器由sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystem-ClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

类加载器的继承架构如下

这时候的启动类加载器还是用C++语言实现的，没有对应的Java类

JDK 9之前的Java应用都是由这三种类加载器互相配合来完成加载的，用户也可以通过继承"应用程序类加载器"，自定义类加载器，进行功能的拓展，典型的如增加除了磁盘位置之外的Class文件来源(从网络中获取类的二进制字节流等)。双亲委派模型是并不是一个具有强制性约束力的模型，而是Java设计者们推荐给开发者的一种类加载器实现的最佳实践。

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承的关系来实现的，而是通常使用组合关系来复用父加载器的代码

后面解析源码的时候，会提到如何通过组合关系来复用父加载器的代码

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

接下来通过分析ClassLoader的loadClass源码，来探究是如何通过组合关系实现双亲委派模型的

    public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
    }

    //调用到了这里，resolve参数应该是表示是否要对该类执行「解析」操作
    protected synchronized Class<?> loadClass(String name, boolean resolve) throws         ClassNotFoundException{
        // 首先，检查请求的类是否已经被加载过了
        Class c = findLoadedClass(name);
        if (c == null) {
            try {
                //判断parent是否为空	
                if (parent != null) {
                    //如果不为空，先尝试用父类加载器加载
                	c = parent.loadClass(name, false);
                } else {
                    /*
                    * 如果为空，则尝试用启动类加载器加载，一般只有扩展类加载器的parent为空,
                    * 会走到这个分支，其余的类加载器的parent一般不会为null
                    * 注意：JDK9之前，启动类加载器采用C++实现，没有对应的Java类，所以启动类
                    * 加载器没有"parent是否为null"之说，这里findBootstrapClassOrNull就是
                    * 扩展类加载器尝试去使用启动类加载器加载
                    */
                	c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 如果父类加载器抛出ClassNotFoundException
                // 说明父类加载器无法完成加载请求
            }
            if (c == null) {
                // 在父类加载器无法加载时
                // 再调用本身的findClass方法来进行类加载
                c = findClass(name);
            }
        }

        if (resolve) {
            resolveClass(c);
        }   
        return c;
    }

这里先不考虑自定义类加载器的问题，先从类加载器的三层架构出发

在代码中出现了parent，这也是ClassLoader，应用程序类加载器的parent是扩展类加载器，扩展类加载的parent是null，启动类加载器没有对于的Java类，即

这里先解释loadClass中调用到的几个方法

findLoadedClass：

    /**
    * 如果这个类加载器(ClassLoader)被虚拟机标记为，已经加载过一个Class(这个Class的名字为name)，那么
    * 就返回该Class，否则返回null
    */
	protected final Class<?> findLoadedClass(String name) {
        if (!checkName(name))
            return null;
        return findLoadedClass0(name);
    }

findBootstrapClassOrNull：

    /**
    * 尝试用启动类加载器加载，如果启动类加载器加载成功，返回成功加载的Class，如果加载失败，则返回null
    * 一般是扩展类加载器的parent为空，当有类加载的请求为委派到扩展类加载器的时候，扩展类加载器会通过
    * 调用这个方法，先去请求父类加载器(启动类加载器)进行加载
    */
	Class<?> findBootstrapClassOrNull(String name) {
        if (!checkName(name)) return null;

        return findBootstrapClass(name);
    }

findClass：

    /**
    * 这个方法会尝试去找一个Class(这个Class的名字为name)，如果找到的话，会尝试去加载这个Class，
    * 如果没找到则抛出ClassNotFoundException异常.
    */
	protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }

如果是一个遵循双亲委派模型的自定义的类加载器，官方推荐是去实现findClass这个方法，这个方法的调用时机是在loadClass中，如果父类加载器尝试调用findClass，并且加载Class失败时，会抛出ClassNotFoundException，这时候自身的findClass就会被调用，自己尝试去加载Class

如果这里听得有点模糊，没关系，后面有例子演示

loadClass方法的一个整体思路：先检查请求加载的类型是否已经被加载过，如果已经被加载过，那么就return这个Class，如果没有被加载过，那么就执行下面的步骤

若此时类加载器不是扩展类加载器，那么parent不为null，那么调用父类加载器的loadClass方法，将加载请求委派给父类加载器
若此时类加载器是扩展类加载器，那么parent为null，则调用findBootstrapClassOrNull让启动类加载器尝试去加载，假如启动类加载器加载失败，会返回null，这时扩展类加载器才调用自己的findClass()方法尝试进行加载。

现在举两个例子，以便更好的理解上面双亲委派模型的执行流程

一、现在要加载一个Class，这个Class是由启动类加载器负责加载的(之前还没有加载过这个Class)，那么执行流程是

调用Application Class Loader的loadClass方法

Application Class Loader
	findLoadedClass -> null
	parent -> Extension Class Loader
	调用parent.loadClass
	
Extension Class Loader	
	findLoadedClass -> null
	parent -> null
	调用findBootstrapClassOrNull(name)

findBootstrapClassOrNull触发启动类加载器进行加载，加载成功，返回Class，return Class
	
Extension Class Loader
	...
	c != null，父类类加载器加载成功，return c
	
Application Class Loader
	...
	c != null，父类类加载器加载成功，return c

二、现在要加载一个Class，这个Class应该是应用程序类加载器负责加载的(之前还没有加载过这个Class)，那么执行流程是

调用Application Class Loader的loadClass方法

Application Class Loader
	findLoadedClass -> null
	parent -> Extension Class Loader
	调用parent.loadClass
	
Extension Class Loader	
	findLoadedClass -> null
	parent -> null
	调用findBootstrapClassOrNull(name)
	
findBootstrapClassOrNull触发启动类加载器进行加载，加载失败，return null
	
Extension Class Loader
	...
	c == null
	findClass尝试进行类加载，加载失败，抛出异常ClassNotFoundException
	
Application Class Loader
	...
	try...catch...捕捉异常
	findClass尝试进行类加载，加载成功，return c

通过上面的执行流程的分析，已经可以大致理解双亲委派模型的执行流程了，可以看出里面有一点递归的味道，当需要自定义类加载器的时候，就继承ClassLoader，重写findClass方法，类似下面这样

	ClassLoader loader = new ClassLoader() {
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            ...
        }
    };

这时候自定义类加载器有没有父加载器呢？有的，观察ClassLoader的构造方法

    protected ClassLoader() {
        this(checkCreateClassLoader(), null, getSystemClassLoader());
    }

    private ClassLoader(Void unused, String name, ClassLoader parent) {
        this.name = name;
        this.parent = parent;
        this.unnamedModule = new Module(this);
        if (ParallelLoaders.isRegistered(this.getClass())) {
            parallelLockMap = new ConcurrentHashMap<>();
            package2certs = new ConcurrentHashMap<>();
            assertionLock = new Object();
        } else {
            // no finer-grained lock; lock on the classloader instance
            parallelLockMap = null;
            package2certs = new Hashtable<>();
            assertionLock = this;
        }
        this.nameAndId = nameAndId(this);
    }

这里的getSystemClassLoader()获取到的就是我们的应用程序类加载器，之后如果要通过loader，进行类加载，就调用loader.loadClass就可以了。

前面自定义类加载器的时候(也就是书P280给出的例子)，是通过重写loadClass方法实现的，这种做法其实不是很好，因为直接重写loadClass，就没有很好地遵循双亲委派模型，官方建议是重写findClass，按照loadClass方法的逻辑，如果父类加载失败，会自动调用自己的findClass方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的

上面源码分析中，loadClass是参照书本P284的(因为jdk11中的源码复杂了一点)，然后其他方法的源码来自于jdk11

双亲委派模型的好处：使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。如果程序中有一个系统自带的java.lang.Object，和一个自己写的java.lang.Object，这时候程序可以正常编译，但是由于双亲委派模型的规则，自己写的那个java.lang.Object永远不会被加载运行。

反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。双亲委派模型对于保证Java程序的稳定运作极为重要。

在JDK9，出现了模块化后，三层类加载器、双亲委派的类加载架构有了一些调整变动

这里有了BootClassLoader的存在，启动类加载器现在是在Java虚拟机内部和Java类库共同协作实现的类加载器，尽管有了BootClassLoader这样的Java类，但为了与之前的代码保持兼容，所有在获取启动类加载器的场景（譬如Object.class.getClassLoader()）中仍然会返回null来代替，而不会得到BootClassLoader的实例。

此时的类加载委派关系如下

更多的这里就不分析了，书上对于这里也没有讲得很清楚.

参考

java ClassLoader源码剖析和双亲委派模型实现_- CSDN博客.

变量赋值的总结

这里对「对象的成员变量、使用static修饰的类变量、使用static final修饰的常量」的赋值，进行一个总结，这一块之前的笔记中都找得到，但是记得有点零散，这里总结一下。

对象的成员变量

首先是对象的成员变量，这个可以从「JVM_自动内存管理-HotSpot虚拟机对象探秘-对象的创建」的笔记中，找到答案：

在Java中，使用关键字new，即可创建一个对象，在虚拟机中，该对象的创建需要经历下面的过程

虚拟机遇到一条new指令的字节码时，先检查该指令的参数能否在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那么就执行相应的类加载过程
为新生对象分配内存，对象所需的内存大小在类加载完成后便可完全确定，分配内存有两种方法
- 指针碰撞：Java堆中的内存是绝对规整的情况下
- 空闲列表：Java堆中的内存并不是规整的

选择哪种分配方式由Java堆是否规整决定，Java堆是否规整由所采用的垃圾收集器是否带有空间压缩整理的能力决定

在为对象分配内存的时候，要考虑并发情况，使得内存可以正常分配，有两种可选方案

第一种方案：对分配内存空间的动作进行同步处理
第二种方案：每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲(TLAB)，哪个线程要分配内存，就现在线程的本地缓冲区中分配，只有本地缓冲区用完了，分配新的缓存区时才需要同步锁定

为分配到的内存空间初始化零值(不包括对象头)，保证在Java代码中，可以不赋初始值就使用对象的实例字段(访问到这些字段的数据类型所对应的零值)
设置对象头的信息，根据虚拟机当前运行状态的不同，比如是否启用偏向锁等，对象头会有不同的设置方式
执行Class文件中的()方法，即通过构造函数对对象进行初始化。到了这里，一个对象就算完全被构造出来了

例如下面这个类，创建对象的时候

public class TestClass {
    private int m = 2;

    public int inc() {
        return m + 1;
    }

}

在上面的第3步中，会将m初始化为0；然后在第5步会执行执行Class文件中的()方法，在()里面会执行m = 2的赋值，然后再执行TestClass的构造函数里的逻辑

类变量/常量

「JVM_虚拟机执行子系统-类文件结构-部分属性-属性-ConstantValue属性」的笔记中：

ConstantValue属性的结构如表6-23所示。

JVM_虚拟机执行子系统_3

接着引用自「JVM_虚拟机执行子系统-类加载机制-准备」的笔记

设置类变量初始值有两种情况
- 第一种：在「类文件结构-部分属性-Code属性」的笔记里，提到什么情况下变量会有ConstantValue属性，如果该类变量有对应的ConstantValue属性，那么在「准备」阶段，就使用ConstantValue为变量进行初始化，后面的中就不用在为该类变量赋值了
- 第二种：变量没有对应的ConstantValue属性，这种情况下就在「准备」阶段为静态变量赋零值，在后面的类构造方法，才会为静态变量赋程序定义的值

常量传播优化

引用自「JVM_虚拟机执行子系统-类加载机制」的一个例子

书上有个例子挺好的，关于static final的

/**
* 被动使用类字段演示三：
* 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化
**/
public class ConstantClass {
    static {
        System.out.println("ConstantClass init!");
    }

    public static final String HELLOWORLD = "hello world";
}

public class NotInitialization {
    public static void main(String[] args) {
        System.out.println(ConstantClass.HELLOWORLD);
    }
}

输出结果：hello world

虚拟机字节码执行引擎

在不同的虚拟机实现中，执行引擎在执行字节码的时候，通常会有解释执行（通过解释器执行）和编译执行（通过即时编译器产生本地代码执行）两种选择，也可能两者兼备，还可能会有同时包含几个不同级别的即时编译器一起工作的执行引擎。但从外观上来看，所有的Java虚拟机的执行引擎输入、输出都是一致的：输入的是字节码二进制流，处理过程是字节码解析执行的等效过程，输出的是执行结果

运行时栈帧结构

Java虚拟机以方法作为最基本的执行单元，栈帧是用于支持虚拟机进行方法调用和方法执行背后的数据结构，方法的调用开始到执行结束，对应着栈帧在虚拟机栈里面的入栈到出栈的过程

栈帧包含：局部变量表、操作数栈、动态连接、方法返回地址和一些额外的附加信息

一个线程中的方法调用链可能会很长

从Java程序的角度来看：同一时刻、同一条线程里面，在调用堆栈的所有方法都同时处于执行状态
从执行引擎的角度来看：在活动线程中，只有位于栈顶的方法才是在运行的，只有位于栈顶的栈帧才是生效的，其被称为"当前栈帧"，与这个栈帧所关联的方法被称为"当前方法"，执行引擎所运行的所有字节码指令都只针对当前栈帧进行操作

栈帧的概念结构

既然虚拟机基本的执行单元是方法，方法背后的数据结构是栈帧，那么接下来就了解下栈帧的各个部分~~

局部变量表

用于存放方法参数和方法内部定义的局部变量，容量以变量槽为最小单位，规定

一个变量槽可以存放一个boolean、byte、char、short、int、float、reference或returnAddress类型的数据
long和double使用两个连续的变量槽空间存储

这里的returnAddress并不是方法的返回地址，而是为字节码指令jsr、jsr_w和ret服务的，某些很古老的Java虚拟机曾经使用这几条指令来实现异常处理时的跳转，但现在也已经全部改为采用异常表来代替了

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

为了尽可能节省栈帧耗用的内存空间，局部变量表中的变量槽是可以重用的，方法体中定义的变量，其作用域并不一定会覆盖整个方法体，如果当前字节码PC计数器的值已经超出了某个变量的作用域，那这个变量对应的变量槽就可以交给其他变量来重用。不过，这样的设计除了节省栈帧空间以外，还会伴随有少量额外的副作用，例如在某些情况下变量槽的复用会直接影响到系统的垃圾收集行为。

操作数栈

操作数栈是一个后入先出栈，32位数据类型所占的栈容量为1，64位数据类型所占的栈容量为2

Java虚拟机的解释执行引擎被称为"基于栈的执行引擎"，这里的"栈"就是操作数栈

当一个方法刚刚开始执行的时候，这个方法的操作数栈是空的，在方法的执行过程中，会有各种字节码指令往操作数栈中写入和提取内容，也就是出栈和入栈操作。譬如在做算术运算的时候是通过将运算涉及的操作数栈压入栈顶后调用运算指令来进行的，又譬如在调用其他方法的时候是通过操作数栈来进行方法参数的传递。举个例子，例如整数加法的字节码指令iadd，这条指令在运行的时候要求操作数栈中最接近栈顶的两个元素已经存入了两个int型的数值，当执行这个指令时，会把这两个int值出栈并相加，然后将相加的结果重新入栈

操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，在编译程序代码的时候，编译器必须要严格保证这一点，在类校验阶段的数据流分析中还要再次验证这一点。再以上面的iadd指令为例，这个指令只能用于整型数的加法，它在执行时，最接近栈顶的两个元素的数据类型必须为int型，不能出现一个long和一个float使用iadd命令相加的情况。

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

动态连接

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接

不知道这和动态连接有什么关系？？

方法返回地址

一个方法开始执行后，有两种方式退出这个方法

正常调用完成：方法正常执行完，可以有返回值
异常调用完成：方法执行过程中遇到了异常，方法内部没有妥善处理异常，这种退出方式不会给上层调用者提供任何返回值

关于如何恢复上一个方法的调用位置，不知道书上再说什么？？

附加信息

《Java虚拟机规范》允许虚拟机实现增加一些规范里没有描述的信息到栈帧之中，例如与调试、性能收集相关的信息，这部分信息完全取决于具体的虚拟机实现，这里不再详述。在讨论概念时，一般会把动态连接、方法返回地址与其他附加信息全部归为一类，称为栈帧信息。

方法调用

任务：确定被调用方法的版本，即确定调用哪一个方法。下面要介绍到的「解析」和「分派」都是确定调用哪一个方法的过程，解析可以在编译器的时候就确定（类加载的时候就把符号引用转化为直接引用），分派要在运行的时候才能最终确定调用到哪一个方法。

自己理解：

“非虚方法”–解析阶段确定调用哪一个方法

“虚方法”–运行的时候才能最终确定调用到哪一个方法

Java对象里面的方法默认(即不使用final修饰，不使用static修饰)都是虚方法

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

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

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

解析

方法调用的「解析」，与类加载阶段的「解析」注意区分

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

这类方法在类加载的时候，就会把方法的符号引用解析为该方法的直接引用，称为"非虚方法"，"非虚方法"有下面5种

所有被invokestatic和invokespecial指令调用的方法，都可以在解析阶段中确定唯一的调用版本，有「静态方法、私有方法、实例构造器、父类方法」4种
还有一个例外，就是使用invokevirtual指令调用的，并且被final修饰的方法，因为它也无法被覆盖，没有其他版本的可能，所以可以在解析阶段中确定唯一的调用版本

除了"非虚方法"，其它方法称为"虚方法"

解析调用一定是个静态的过程，在编译期间就完全确定，在类加载的解析阶段就会把涉及的符号引用全部转变为明确的直接引用，不必延迟到运行期再去完成

Java对象里面的方法默认(即不使用final修饰，不使用static修饰)都是虚方法

分派

分派（Dispatch）调用则要复杂许多，按照调用的过程来划分

可能是静态
可能是动态

按照分派依据的宗量数来划分

单分派
多分派

这两类分派方式两两组合就构成了静态单分派、静态多分派、动态单分派、动态多分派4种分派组合情况，而Java是一门静态多分派、动态单分派的语言

据我的理解，一个实例方法的调用应该是分为两个过程

一、编译阶段中编译器的选择过程，即静态分派的过程

二、运行阶段中虚拟机的选择，即动态分派过程

静态分派

静态分派的典型应用是方法重载

以下面的例子来讲解

public class StaticDispatch {
    static abstract class Human{

    }

    static class Man extends Human{

    }

    static class Woman extends Human{

    }

    public void sayHello(Human guy){
        System.out.println("hello guy!");
    }

    public void sayHello(Man guy){
        System.out.println("hello gentleman!");
    }

    public void sayHello(Woman guy){
        System.out.println("hello lady!");
    }

    public static void main(String[] args) {
        Human man = new Man();
        Human woman = new Woman();
        StaticDispatch sr = new StaticDispatch();
        sr.sayHello(man);
        sr.sayHello(woman);
    }
}

hello guy!
hello guy!

先讲解两个概念

Human man = new Man();

等号左边的Human：称为变量的**“静态类型”**，或者叫"外观类型"

等号右边的Man：称为变量的**“实际类型”**，或者叫"运行时类型"

静态类型和实际类型在程序中都可能会发生变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的；而实际类型变化的结果在运行期才可确定，编译器在编译程序的时候并不知道一个对象的实际类型是什么。如下

// 实际类型变化
Human human = (new Random()).nextBoolean() ? new Man() : new Woman();

// 静态类型变化
sr.sayHello((Man) human)
sr.sayHello((Woman) human)

对象human的实际类型是可变的，到底是Man还是Woman，必须等到程序运行到这行的时候才能确定。而human的静态类型是Human，也可以在使用时（如sayHello()方法中的强制转型）临时改变这个类型，但这个改变仍是在编译期是可知的，两次sayHello()方法的调用，在编译期完全可以明确转型的是Man还是Woman。

回到上面的代码中，都是调用到了参数为Human guy的方法

    public void sayHello(Human guy){
        System.out.println("hello guy!");
    }

这里调用哪个方法版本，是以参数的静态类型而不是实际类型作为判定依据的，因此编译器就可以完成该判断，在编译阶段，Javac根据静态类型决定了使用哪个重载版本，选择sayHello(Human)作为调用目标，把这个方法的符号引用写到main()方法里的两条invokevirtual指令的参数中，如下

//Java代码
sr.sayHello(man);
sr.sayHello(woman);

//Javap分析字节码，得出上面的代码对应的字节码指令
26: invokevirtual #13                 // Method sayHello:(Lengine/StaticDispatch$Human;)V
31: invokevirtual #13                 // Method sayHello:(Lengine/StaticDispatch$Human;)V

所有依赖静态类型来决定方法执行版本的分派动作，都称为静态分派。静态分派的最典型应用表现就是方法重载。静态分派发生在编译阶段，确定静态分派的动作实际上是由编译器完成，而不是由虚拟机来执行的。

个人理解：这里确定Method sayHello:(Lengine/StaticDispatch$Human;)V是静态分派做的事，后面invokevirtual指令执行的时候，涉及到动态分派做的事情，通过静态分派和后面提到的动态分派，最终确定方法的调用版本

另外要注意，解析与分派这两者之间的关系并不是二选一的排他关系，它们是在不同层次上去筛选、确定目标方法的过程。例如前面说过静态方法会在编译期确定、在类加载期就进行解析，而静态方法显然也是可以拥有重载版本的，选择重载版本的过程也是通过静态分派完成的，整个过程可能既涉及到解析，又涉及到分派

动态分派

动态分派的典型应用是方法重写

以下面的例子进行讲解

public class DynamicDispatch {
    static abstract class Human {
        protected abstract void sayHello();
    }

    static class Man extends Human {
        @Override
        protected void sayHello() {
            System.out.println("man say hello");
        }
    }

    static class Woman extends Human {
        @Override
        protected void sayHello() {
            System.out.println("woman say hello");
        }
    }

    public static void main(String[] args) {
        Human man = new Man();
        Human woman = new Woman();
        man.sayHello();
        woman.sayHello();
        man = new Woman();
        man.sayHello();
    }
}

man say hello
woman say hello
woman say hello

上面三个调用sayHello()方法对应的字节码指令如下

17: invokevirtual #6                  // Method engine/DynamicDispatch$Human.sayHello:()V
21: invokevirtual #6                  // Method engine/DynamicDispatch$Human.sayHello:()V 
33: invokevirtual #6                  // Method engine/DynamicDispatch$Human.sayHello:()V

这里确定Method engine/DynamicDispatch$Human.sayHello:()V是一个静态分派的过程

接着看invokevirtual指令的执行过程

找到操作数栈顶的第一个元素所指向的对象的实际类型，记作C
如果在类型C中找到与常量中的描述符和简单名称都相符的方法，则进行访问权限校验，如果
通过则返回这个方法的直接引用，查找过程结束；不通过则返回java.lang.IllegalAccessError异常
否则，按照继承关系从下往上依次对C的各个父类进行第二步的搜索和验证过程
如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常

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

个人理解：这里整个方法的调用过程，其实也是静态分派和动态分派配合来完成的

单分派和多分派

这里既讲清楚了单分派和多分派的概念，又把前面的静态分派和动态分派串起来了

方法的接收者与方法的参数统称为方法的宗量。根据分派基于多少种宗量，可以将分派划分为

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

以一个例子讲解

public class Dispatch {
    static class QQ {
    }

    static class _360 {
    }

    public static class Father {
        public void hardChoice(QQ arg) {
            System.out.println("father choose qq");
        }

        public void hardChoice(_360 arg) {
            System.out.println("father choose 360");
        }
    }

    public static class Son extends Father {
        public void hardChoice(QQ arg) {
            System.out.println("son choose qq");
        }

        public void hardChoice(_360 arg) {
            System.out.println("son choose 360");
        }
    }

    public static void main(String[] args) {
        Father father = new Father();
        Father son = new Son();
        father.hardChoice(new _360());
        son.hardChoice(new QQ());
    }
}

father choose 360
son choose qq

一、首先关注静态分派过程

这是编译阶段中编译器的选择过程，选择目标方法的依据有两点：

静态类型是Father还是Son
方法参数是QQ还是360

这次选择结果的最终产物是产生了两条invokevirtual指令，两条指令的参数分别为常量池中指向
Father::hardChoice(360)及Father::hardChoice(QQ)方法的符号引用。

因为是根据两个宗量进行选择，所以Java语言的静态分派属于多分派类型。

二、关注动态分派的过程

这是运行阶段中虚拟机的选择，在执行son.hardChoice(new QQ())对应的invokevirtual指令时，虚拟机会根据Father son的实际类型是Father还是Son，来决定调用哪个方法

因为只有一个宗量作为选择依据，所以Java语言的动态分派属于单分派类型。

虚方法表

动态分派是执行非常频繁的动作，而且动态分派的方法版本选择过程需要运行时在接收者类型的方法元数据中搜索合适的目标方法，因此，Java虚拟机实现基于执行性能的考虑，真正运行时一般不会如此频繁地去反复搜索类型元数据。面对这种情况，一种基础而且常见的优化手段是为类型在方法区中建立一个虚方法表（vtable），结构如下

虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方法表中的地址入口和父类相同方法的地址入口是一致的，都指向父类的实现入口。如果子类中重写了这个方法，子类虚方法表中的地址也会被替换为指向子类实现版本的入口地址。在图8-3中，Son重写了来自Father的全部方法，因此Son的方法表没有指向Father类型数据的箭头。但是Son和Father都没有重写来自Object的方法，所以它们的方法表中所有从Object继承来的方法都指向了Object的数据类型。

一个好例子

这个例子来自于书P311，主要说明两个内容

字段没有多态性
对象的构造方法的执行内容及顺序

例子如下

public class FieldHasNoPolymorphic {
    static class Father{
        public int money = 1;

        public Father() {
            money = 2;
            showMeTheMoney();
        }

        public void showMeTheMoney(){
            System.out.println("I am father,I have "+money);
        }
    }

    static class Son extends Father{
        public int money = 3;

        public Son(){
            money = 4;
            showMeTheMoney();
        }

        @Override
        public void showMeTheMoney() {
            System.out.println("I am Son,I have "+money);
        }
    }

    public static void main(String[] args) {
        Father gay = new Son();
        System.out.println("The gay has "+gay.money);
    }
}

I am Son,I have 0
I am Son,I have 4
The gay has 2

首先这里分析一下构造函数会做哪些事情，Son的构造方法的字节码指令如下

0: aload_0
1: invokespecial #1      // Method engine/FieldHasNoPolymorphic$Father."<init>":()V
4: aload_0
5: iconst_3
6: putfield      #2      // Field money:I
9: aload_0
10: iconst_4
11: putfield      #2     // Field money:I
14: aload_0
15: invokevirtual #3     // Method showMeTheMoney:()V
18: return

第1条：调用父类Father的构造方法
第5、6条：为成员变量money赋值3，这个是程序在定义成员变量的时候想要给money赋的值
第10、11条：为成员变量money赋值4，这个是程序在构造函数中显示指定的money = 4
第15条：调用自身的showMeTheMoney方法

然后看一下Father的构造方法的字节码指令

0: aload_0
1: invokespecial #1            // Method java/lang/Object."<init>":()V
4: aload_0
5: iconst_1
6: putfield      #2            // Field money:I
9: aload_0
10: iconst_2
11: putfield      #2           // Field money:I
14: aload_0
15: invokevirtual #3           // Method showMeTheMoney:()V
18: return

第1条：调用父类Object的构造方法
第5、6条：为成员变量money赋值1，这个是程序在定义成员变量的时候想要给money赋的值
第10、11条：为成员变量money赋值2，这个是程序在构造函数中显示指定的money = 2
第15条：调用showMeTheMoney方法，但是这里其实是一次虚方法调用，实际执行的版本是Son::showMeTheMoney()方法

接下来解释上面的运行结果

I am Son,I have 0
I am Son,I have 4
The gay has 2

I am Son,I have 0：这里是Son在执行构造方法的时候，会先调用Father的构造方法，Father的构造方法里面调用了showMeTheMoney()，实际调用到的是Son::showMeTheMoney()，而Son的money此时的值还是0，所以输出了I am Son,I have 0
I am Son,I have 4：这个就是在Son的构造函数里，执行了money = 4后，自己调用了showMeTheMoney，所以输出了I am Son,I have 4
The gay has 2：这里是因为main中执行了System.out.println("The gay has "+gay.money);，这里要讲的是「字段没有多态性」的内容

在Java里面只有虚方法存在，字段永远不可能是虚的，换句话说，字段永远不参与多态，哪个类的方法访问某个名字的字段时，该名字指的就是这个类能看到的那个字段。当子类声明了与父类同名的字段时，虽然在子类的内存中两个字段都会存在，但是子类的字段会遮蔽父类的同名字段。main()的System.out.println("The gay has "+gay.money);，通过静态类型访问到了父类中的money，输出的money是2

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

许多Java虚拟机的执行引擎在执行Java代码的时候都有解释执行（通过解释器执行）和编译执行（通过即时编译器产生本地代码执行）两种选择，在这里，我们讨论在概念模型下的Java虚拟机解释执行字节码时，执行引擎是如何工作的

这里强调“概念模型”，是因为实际的虚拟机实现与概念模型中执行过程的差异很大，但结果却能保证是一致的

解释执行

大部分的程序代码转换成物理机的目标代码或虚拟机能执行的指令集之前，都需要下面的各个步骤

下面的那条分支，即程序源码 -> 词法分析 -> 单词流 -> 语法分析 -> 抽象语法树 -> 优化器 -> 中间代码 -> 生成器 -> 目标代码，就是传统编译原理中程序代码到目标机器代码的生成过程

中间的那条分支，即程序源码 -> 词法分析 -> 单词流 -> 语法分析 -> 抽象语法树 -> 指令流 -> 解释器 -> 解释执行，是解释执行的过程

对于一门具体语言的实现来说：

词法、语法分析以至后面的优化器和目标代码生成器都可以选择独立于执行引擎，形成一个完整意义的编译器去实现，这类代表是C/C++语言
也可以选择把其中一部分步骤（如生成抽象语法树之前的步骤）实现为一个半独立的编译器，这类代表是Java语言
又或者把这些步骤和执行引擎全部集中封装在一个封闭的黑匣子之中，如大多数的JavaScript执行引擎。

在Java语言中，Javac编译器完成了程序代码经过词法分析、语法分析到抽象语法树，再遍历语法树生成线性的字节码指令流的过程。因为这一部分动作是在Java虚拟机之外进行的，而解释器在虚拟机的内部，所以Java程序的编译就是半独立的实现。

基于栈/寄存器的指令集

两种常用的指令集架构

基于栈的指令集架构：这种指令流中的指令通常都是不带参数的，使用操作数栈中的数据作为指令的运算输入，指令的运算结果也存储在操作数栈之中，依赖操作数栈进行工作
基于寄存器的指令集架构：指令依赖寄存器进行工作，依赖于寄存器来访问和存储数据

Javac编译器输出的字节码指令流，基本上是一种基于栈的指令集架构，字节码指令流里面的指令大部分都是零地址指令，它们依赖操作数栈进行工作

这两种指令集架构的优缺点：书P329

基于栈的解释器执行过程

这里主要描述了虚拟机里字节码是如何执行的，书P329~书P334有图解过程，非常棒！！

参考

《深入理解Java虚拟机第3版》
书P250提到的类型注解：Java8中的类型注解浅析 CSDN博客.

附：

ASCII图：ASCII码图.
某个文件路径打开cmd：当前文件目录下打开CMD-百度经验 .
cmd中Javap提示找不到类：idea中配置javap找不到类的问题回复.

Giagor

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JVM_虚拟机执行子系统

本篇为《深入理解Java虚拟机第3版》读书笔记文中，《Java虚拟机规范》简称《规范》类文件结构平台无关性和语言无关性的基石：Java虚拟机和字节码存储格式平台无关性：Java虚拟机可以运行在各种不同的硬件平台和操作系统上，这些虚拟机都可以载入和执行同一种平台无关的字节码，从而实现程序的“一次编译，到处运行”语言无关性：Java虚拟机不与包括Java语言在内的任何程序语言绑定，它只与“Class文件”这种特定的二进制文件格式所关联，Class文件中包含了Java虚拟机指令集、符号表以及.
复制链接

扫一扫