JVM运行的整体流程

笔记：依据视频教程学习后，纯看配图，使用的个人语言的书写（有水印的配图进行了自己绘制）

目前版本：1.0

宏观来看，JVM的不同操作系统的实现，使得Java经过一次编译后的.class字节码文件，能够在不同的平台上运行

印证了流程很广泛的一句话——“一次编译，处处运行”

其实不仅仅是Java语言，其他的语言，只要仅编译器编译后符合JVM所定义的字节码文件的格式规范，就能在Java虚拟机上运行：

JVM的作用

Java虚拟机就是二进制字节码文件的运行时环境，负责装载字节码到其内部，解释or编译为对应操作系统平台的机器指令执行。

JVM架构图

注：此图非常重要，要非常熟悉。

上图较为简易的描述了JVM的工作流程：

  1. 从一个class字节码文件开始
  2. 首先经过类加载子系统的加载
  3. 然后把加载后的信息保存进入运行时数据区
  4. 运行时数据区的内存结构划分为不同的结构——方法区用于存放类的方法信息；堆中主要用于保存对象、字符串常量等信息；程序计数器仅用于保存程序要执行的下一条指令信息；本地方法栈中保存的是一些Java的核心类库的实现（一般用C/C++实现）；虚拟机栈中是一个个栈帧，栈帧保存了当前执行方法的所需信息（比如使用到的对象的引用、基本数据类型的值、String的引用）。
  5. 执行引擎负责具体的执行过程；本地方法接口从本地方法库加载方法的实现、然后被本地方法栈调用。

ps：描述不一定准确

更加详细的架构图如下，可供复习使用：

JVM架构模型

JVM是基于栈的架构模型，不妨与另一种（基于寄存器的架构模型）进行对比，来说明其特点。

栈这种结构，联系数据结构与算法所学的知识，无非“进栈”、“出栈”、“后进先出”等特点

那么基于这些特点，其每一条指令就非常小，因为无需指定指令所对应的位置（因为对栈的操作就是在栈顶）；而基于寄存器的，每一条指令就显得长一些，因为它不光要指出指令的具体操作，还要明确操作的位置。举个简单例子：

同样执行2+3，基于栈架构所用指令（JVM为例）如下：

1
2
3
4
5
6
7
8
iconst_2 //常量2入栈
istore_1
iconst_3 // 常量3入栈
istore_2
iload_1
iload_2
iadd //常量2/3出栈，执行相加
istore_0 // 结果5入栈

基于寄存器架构（80x86汇编语言举例）举例如下：

1
2
mov ax,2 //将ax寄存器的值设为1
add ax,3 //使ax寄存器的值加3

可见，基于栈架构的所用指令数量会更多，即使其每一条指令很简单

那么JVM为什么要采用栈的架构呢？总结如下：

  1. 基于栈架构，跨平台性更好。因为不同平台CPU架构不同，所以不能用基于寄存器架构的
  2. 虽然经过汇编后，相比于寄存器架构方式指令更多、运行效率更低，但是考虑到跨平台性和可移植性，JVM选择了栈架构的设计

类加载子系统（Class Loader SubSystem）

总括：Class Loader SubSystem的作用

类加载子系统只负责将class文件中的类的信息加载到JVM中，加载的类信息存放于一块称为方法区的内存空间，除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

它起了一个创造模板的作用，详细些：class文件中存储了一些类的模板信息（比如定义了哪些字段、有哪些方法、实现了哪些接口、父类是谁等），然后类加载子系统把这些模板的信息读取进来（到JVM中）

这些“模板信息”存放于方法区中（JDK8前叫做永久代，在堆中；JDK8后改为云空间，在系统内存中）

类加载过程

1 加载（Loading）

非自己语言

加载：

  1. 通过一个类的全限定名获取定义此类的二进制字节流

  2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

  3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

加载class文件的方式：

  1. 从本地系统中直接加载
  2. 通过网络获取，典型场景：Web Applet
  3. 从zip压缩包中读取，成为日后jar、war格式的基础
  4. 运行时计算生成，使用最多的是：动态代理技术
  5. 由其他文件生成，典型场景：JSP应用从专有数据库中提取.class文件，比较少见
  6. 从加密文件中获取，典型的防Class文件被反编译的保护措施

2 链接（Linking）

非自己语言

分为三个子阶段：验证、准备、解析

2.1 验证（Verification）

  1. 目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求（e.g.开头的：CAFEBABE），保证被加载类的正确性，不会危害虚拟机自身安全
  2. 主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。

2.2 准备（Preparation）

  1. 为类变量（static变量）分配内存并且设置该类变量的默认初始值，即零值
  2. 这里不包含用final修饰的static，因为final在编译的时候就会分配好了默认值，准备阶段会显式初始化
  3. 注意：这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中

举例

代码：变量a在准备阶段会赋初始值，但不是1，而是0，在初始化阶段会被赋值为 1

1
2
3
4
5
6
7
8
public class HelloApp {
    private static int a = 1;//prepare：a = 0 ---> initial : a = 1


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

2.3 解析（Resolution）

  1. 将常量池内的符号引用转换为直接引用的过程

  2. 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行

  3. 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄

  4. 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等

3 初始化（Initialization）

即方法的调用——在此时发生

  1. 创建类的实例
  2. 访问某个类或接口的静态变量，或者对该静态变量赋值
  3. 调用类的静态方法
  4. 反射（比如：Class.forName(“com.yukino.User”)）
  5. 初始化一个类的子类
  6. Java虚拟机启动时被标明为启动类的类
  7. JDK7开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化

除了以上七种情况，其他使用Java类的方式都被看作是对类的被动使用，都不会导致类的初始化，即不会执行初始化阶段（不会调用 clinit() 方法和 init() 方法）

类加载器分类

非自己语言

  1. JVM严格来讲支持两种类型的类加载器 。分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）
  2. 从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
  3. 无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示

JDK1.8中源码继承关系图

ExtClassLoader（Launcher内部类）——扩展类加载器

AppClassLoader（Launcher内部类）——应用类加载器（也成系统类加载器）

JDK1.9及之后的

注意继承于BuiltinClassLoader了，不再是URLClassLoader

PlatformClassLoader（Launcher内部类）——平台类加载器

AppClassLoader（Launcher内部类）——应用类加载器

虚拟机自带的加载器

非自己语言

启动类加载器

启动类加载器（引导类加载器，Bootstrap ClassLoader）

  1. 这个类加载使用C/C++语言实现的，嵌套在JVM内部
  2. 它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
  3. 并不继承自java.lang.ClassLoader，没有父加载器
  4. 加载扩展类和应用程序类加载器，并作为他们的父类加载器
  5. 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

扩展类加载器

扩展类加载器（ExtClassLoader）

  1. Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
  2. 派生于ClassLoader类
  3. 父类加载器为启动类加载器
  4. 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载

系统类加载器

应用程序类加载器（也称为系统类加载器，AppClassLoader）

  1. Java语言编写，由sun.misc.LaunchersAppClassLoader实现
  2. 派生于ClassLoader类
  3. 父类加载器为扩展类加载器
  4. 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
  5. 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
  6. 通过classLoader.getSystemclassLoader()方法可以获取到该类加载器

用户自定义类加载器

什么时候需要自定义类加载器？

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。那为什么还需要自定义类加载器？

  1. 隔离加载类（比如说我假设现在Spring框架，和RocketMQ有包名路径完全一样的类，类名也一样，这个时候类就冲突了。不过一般的主流框架和中间件都会自定义类加载器，实现不同的框架、中间件之间是隔离的）
  2. 修改类加载的方式
  3. 扩展加载源（还可以考虑从数据库中加载类，路由器等等不同的地方）
  4. 防止源码泄漏（对字节码文件进行解密，自己用的时候通过自定义类加载器来对其进行解密）

如何自定义类加载器？

  1. 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
  2. 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass()方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findclass()方法中
  3. 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findclass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

关于ClassLoader

ClassLoader是一个抽象类，其后所有的类加载器都继承自ClassLoader（JDK8的启动类加载器除外）

（JDK9之后的BootClassLoader又间接继承与ClassLoader了）

方法名称 描述
getParent() 返回该类加载器的超类加载器
loadClass(String name) 加载名称为name的类，返回结果为java.lang.Class类的示例
findClass(String name) 查找名称为name的类，返回结果为java.lang.Class类的示例
findLoadedClass(String name) 查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的示例
defineClass(String name,byte[] b,int off, int len) 把字节数组b中的内容转换为一个Java类，返回结果为java.lang.Class类的示例
resolveClass(Class<?> e) 连接指定的一个Java类

获取ClassLoader的途径

获取当前类的ClassLoader clazz.getClassLoader()
获取当前线程上下文的ClassLoader Thread.currentThread().getContextClassLoader()
获取系统的ClassLoader ClassLoader.getSystemClassLoader()
获取调用者的ClassLoader DriverManager.getCallerClassLoader()

双亲委派机制

双亲委派机制原理

Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式

  1. 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
  2. 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
  3. 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。
  4. 父类加载器一层一层往下分配任务，如果子类加载器能加载，则加载此类，如果将加载任务分配至系统类加载器也无法加载此类，则抛出异常

双亲委派机制优势

  1. 避免类的重复加载

  2. 保护程序安全，防止核心API被随意篡改

    • 自定义类：自定义java.lang.String 没有被加载。
    • 自定义类：java.lang.ShkStart（报错：阻止创建 java.lang开头的类）

沙箱安全机制

  1. 自定义String类时：在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java.lang.String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的String类。
  2. 这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

如何判断两个class对象是否相同？

在JVM中表示两个class对象是否为同一个类存在两个必要条件：

  1. 类的全类名一致

  2. 加载这个类的ClassLoader实例对象一致

    换句话说，在JVM中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的

对类加载器的引用

  1. JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的
  2. 如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中
  3. 当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的

运行时数据区（Runtime Data Area）

通过之前的：类的加载->验证->准备->解析->初始化，就会使用执行引擎对类进行使用，同时执行引擎还会使用到运行时数据区中的数据

概述

运行时数据区与内存

  1. 内存是非常重要的系统资源，是硬盘和CPU的中间仓库及桥梁，承载着操作系统和应用程序的实时运行。JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略，保证了JVM的高效稳定运行。不同的JVM对于内存的划分方式和管理机制存在着部分差异。结合JVM虚拟机规范，来探讨一下经典的JVM内存布局。

  2. 我们通过磁盘或者网络IO得到的数据，都需要先加载到内存中，然后CPU从内存中获取数据进行读取，也就是说内存充当了CPU和磁盘之间的桥梁

JVM 线程

  1. 线程是一个程序里的运行单元。JVM允许一个应用有多个线程并行的执行
  2. 在Hotspot JVM里，每个线程都与操作系统的本地线程直接映射
    • 当一个Java线程准备好执行以后，此时一个操作系统的本地线程也同时创建。Java线程执行终止后，本地线程也会回收
  3. 操作系统负责将线程安排调度到任何一个可用的CPU上。一旦本地线程初始化成功，它就会调用Java线程中的run()方法

JVM 系统线程

  • 如果你使用jconsole或者是任何一个调试工具，都能看到在后台有许多线程在运行。这些后台线程不包括调用public static void main(String[])的main线程以及所有这个main线程自己创建的线程。

  • 这些主要的后台系统线程在Hotspot JVM里主要是以下几个：

  1. 虚拟机线程：这种线程的操作是需要JVM达到安全点才会出现。这些操作必须在不同的线程中发生的原因是他们都需要JVM达到安全点，这样堆才不会变化。这种线程的执行类型括"stop-the-world"的垃圾收集，线程栈收集，线程挂起以及偏向锁撤销
  2. 周期任务线程：这种线程是时间周期事件的体现（比如中断），他们一般用于周期性操作的调度执行
  3. GC线程：这种线程对在JVM里不同种类的垃圾收集行为提供了支持
  4. 编译线程：这种线程在运行时会将字节码编译成到本地代码
  5. 信号调度线程：这种线程接收信号并发送给JVM，在它内部通过调用适当的方法进行处理

程序计数器（PC Register）

  1. JVM中的程序计数寄存器（Program Counter Register）中，Register的命名源于CPU的寄存器，寄存器存储指令相关的现场信息。CPU只有把数据装载到寄存器才能够运行。
  2. 这里，并非是广义上所指的物理寄存器，或许将其翻译为PC计数器（或指令计数器）会更加贴切（也称为程序钩子），并且也不容易引起一些不必要的误会。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟。
  3. 它是一块很小的内存空间，几乎可以忽略不计。也是运行速度最快的存储区域。
  4. 在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期保持一致。
  5. 任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址；或者，如果是在执行native方法，则是未指定值（undefned）。
  6. 它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
  7. 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
  8. 它是唯一一个在Java虚拟机规范中没有规定任何OutofMemoryError情况的区域。

PC寄存器的作用，一言以蔽之：

PC寄存器用来存储指向下一条指令的地址。由执行引擎读取下一条指令，并执行该指令。

本地方法接口+本地方法库

简单地讲，一个Native Method是一个Java调用非Java代码的接囗

因此，在定义一个native method时，并不提供实现体（有些像定义一个Java interface），因为其实现体是由非java语言在外面实现的。

本地接口的作用是融合不同的编程语言为Java所用，初衷是融合C/C++程序。

本地方法栈

就是用于调用本地方法接口的

  1. Java虚拟机栈于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。
  2. 本地方法栈，也是线程私有的。
  3. 允许被实现成固定或者是可动态扩展的内存大小（在内存溢出方面和虚拟机栈相同）
    • 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个stackoverflowError 异常。
    • 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么Java虚拟机将会抛出一个outofMemoryError异常。
  4. 本地方法一般是使用C语言或C++语言实现的。
  5. 它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。

虚拟机栈

栈管运行，堆管存储

即：栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。堆解决的是数据存储的问题，即数据怎么放，放哪里

虚拟机栈是什么？

  • 虚拟机栈（VM Stack）。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次的Java方法调用，栈是线程私有的

  • 虚拟机栈的生命周期

    • 生命周期和线程一致，也就是线程结束了，该虚拟机栈也销毁了

  • 虚拟机栈的作用

    • 主管Java程序的运行，它保存方法的局部变量（8 种基本数据类型、对象的引用地址）、部分结果，并参与方法的调用和返回。
    • 局部变量，它是相比于成员变量来说的（或属性）
    • 基本数据类型变量 VS 引用类型变量（类、数组、接口）

虚拟机栈的特点

  • 栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。

  • JVM直接对Java栈的操作只有两个：

    • 每个方法执行，伴随着进栈（入栈、压栈）
    • 执行结束后的出栈工作

  • 对于栈来说不存在垃圾回收问题

    • 栈不需要GC，但是可能存在OOM

虚拟机栈的异常

面试题：栈中可能出现的异常？

  • Java 虚拟机规范允许Java栈的大小是动态的或者是固定不变的。

    • 如果采用固定大小的Java虚拟机栈，那每一个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量，Java虚拟机将会抛出一个StackoverflowError 异常。

    • 如果Java虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那Java虚拟机将会抛出一个 OutofMemoryError 异常。

栈的存储单位

栈中存储什么？

  1. 每个线程都有自己的栈，栈中的数据都是以栈帧（Stack Frame）的格式存在
  2. 在这个线程上正在执行的每个方法都各自对应一个栈帧（Stack Frame）。
  3. 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息。

栈运行原理

  1. JVM直接对Java栈的操作只有两个，就是对栈帧的压栈和出栈，遵循先进后出（后进先出）原则

  2. 在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的。这个栈帧被称为当前栈帧（Current Frame），与当前栈帧相对应的方法就是当前方法（Current Method），定义这个方法的类就是当前类（Current Class）

  3. 执行引擎运行的所有字节码指令只针对当前栈帧进行操作。

  4. 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前帧。

  1. 不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧之中引用另外一个线程的栈帧。
  2. 如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。
  3. Java方法有两种返回函数的方式。
    • 一种是正常的函数返回，使用return指令。
    • 另一种是方法执行中出现未捕获处理的异常，以抛出异常的方式结束。
    • 但不管使用哪种方式，都会导致栈帧被弹出。

栈帧的内部结构

每个栈帧中存储着：

  • 局部变量表（Local Variables）

  • 操作数栈（Operand Stack）（或表达式栈）

  • 动态链接（Dynamic Linking）（或指向运行时常量池的方法引用）

  • 方法返回地址（Return Address）（或方法正常退出或者异常退出的定义）

  • 一些附加信息

并行每个线程下的栈都是私有的，因此每个线程都有自己各自的栈，并且每个栈里面都有很多栈帧，栈帧的大小主要由局部变量表 和 操作数栈决定的

局部变量表

认识局部变量表

概念

  1. 局部变量表也被称之为局部变量数组或本地变量表
  2. 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型、对象引用（reference），以及returnAddress返回值类型。
  3. 由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
  4. 局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。
  5. 方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。
    • 对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。
    • 进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
  6. 局部变量表中的变量只在当前方法调用中有效。
    • 在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。
    • 当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

关于slot的理解

  1. 参数值的存放总是从局部变量数组索引 0 的位置开始，到数组长度-1的索引结束。
  2. 局部变量表，最基本的存储单元是slot（变量槽），局部变量表中存放编译期可知的各种基本数据类型（8种），引用类型（reference），returnAddress类型的变量。
  3. 在局部变量表里，32位以内的类型只占用一个slot（包括returnAddress类型），64位的类型占用两个slot（1ong和double）。
    • byte、short、char在储存前被转换为int，boolean也被转换为int，0表示false，非0表示true
    • long和double则占据两个slot
  4. JVM会为局部变量表中的每一个slot都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值
  5. 当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个slot上
  6. 如果需要访问局部变量表中一个64bit的局部变量值时，只需要使用前一个索引即可。（比如：访问long或double类型变量）
  7. 如果当前帧是由构造方法或者实例方法创建的，那么该对象引用this将会存放在index为0的slot处，其余的参数按照参数表顺序继续排列。（this也相当于一个变量）

可见除double、long类型占2个slot外，其余类型均占1个slot

slot的重复利用

栈帧中的局部变量表中的槽位是可以重用的，如果一个局部变量过了其作用域，那么在其作用域之后申明新的局部变量变就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。

静态变量与局部变量的对比

1
2
3
4
5
6
7
8
变量的分类：
1、按照数据类型分：① 基本数据类型  ② 引用数据类型
2、按照在类中声明的位置分：
  2-1、成员变量：在使用前，都经历过默认初始化赋值
       2-1-1、类变量: linking的prepare阶段：给类变量默认赋值
              ---> initial阶段：给类变量显式赋值即静态代码块赋值
       2-1-2、实例变量：随着对象的创建，会在堆空间中分配实例变量空间，并进行默认赋值
  2-2、局部变量：在使用前，必须要进行显式赋值的！否则，编译不通过。
  1. 参数表分配完毕之后，再根据方法体内定义的变量的顺序和作用域分配。
  2. 我们知道成员变量有两次初始化的机会**，**第一次是在“准备阶段”，执行系统初始化，对类变量设置零值，另一次则是在“初始化”阶段，赋予程序员在代码中定义的初始值。
  3. 和类变量初始化不同的是，局部变量表不存在系统初始化的过程，这意味着一旦定义了局部变量则必须人为的初始化，否则无法使用。

补充说明

  1. 在栈帧中，与性能调优关系最为密切的部分就是前面提到的局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递。

  2. 局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。

操作数栈

操作数栈的特点

  1. 每一个独立的栈帧除了包含局部变量表以外，还包含一个后进先出（Last - In - First -Out）的 操作数栈，也可以称之为表达式栈（Expression Stack）

  2. 操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈（push）和 出栈（pop）

  • 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈，
  • 比如：执行复制、交换、求和等操作

操作数栈的作用

  1. 操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。

  2. 操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这时方法的操作数栈是空的。

  3. 每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的Code属性中，为maxstack的值。

  4. 栈中的任何一个元素都是可以任意的Java数据类型

    • 32bit的类型占用一个栈单位深度
    • 64bit的类型占用两个栈单位深度

  5. 操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一次数据访问。只不过操作数栈是用数组这个结构来实现的而已

  6. 如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。

  7. 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译器期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。

  8. 另外，我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。

操作数栈字节码示例

1
2
3
4
5
6
7
8
9
public void testAddOperation() {
    //byte、short、char、boolean：都以int型来保存
    byte i = 15;
    int j = 8;
    int k = i + j;

   // int m = 800;

}

对应字节码指令

1
2
3
4
5
6
7
8
9
 0 bipush 15
 2 istore_1
 3 bipush 8
 5 istore_2
 6 iload_1
 7 iload_2
 8 iadd
 9 istore_3
10 return

详细运行过程如下：

栈顶缓存技术

栈顶缓存技术：Top Of Stack Cashing

  1. 前面提过，基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派（instruction dispatch）次数（也就是你会发现指令很多）和导致内存读/写次数多，效率不高。

  2. 由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题，HotSpot JVM的设计者们提出了栈顶缓存（Tos，Top-of-Stack Cashing）技术，将栈顶元素全部缓存在物理CPU的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率。

  3. 寄存器的主要优点：指令更少，执行速度快，但是指令集（也就是指令种类）很多

动态链接

动态链接（或指向运行时常量池的方法引用）

  1. 每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接（Dynamic Linking），比如：invokedynamic指令

  2. 在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在class文件的常量池里。比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用

符号引用，指向的为——方法名、方法参数、返回值类型等信息，而直接引用就是指向了实际要执行的方法信息（例如符号引用指向的是接口中定义的方法，然后直接引用就是指向其实现类的实现方法？）

为什么要用常量池呢？

  1. 因为在不同的方法，都可能调用常量或者方法，所以只需要存储一份即可，然后记录其引用即可，节省了空间。

  2. 常量池的作用：就是为了提供一些符号和常量，便于指令的识别

方法的调用

静态链接与动态链接

在JVM中，将符号引用转换为调用方法的直接引用与方法的绑定机制相关

  • 静态链接：

当一个字节码文件被装载进JVM内部时，如果被调用的目标方法在编译期确定，且运行期保持不变时，这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接

  • 动态链接：

如果被调用的方法在编译期无法被确定下来，也就是说，只能够在程序运行期将调用的方法的符号转换为直接引用，由于这种引用转换过程具备动态性，因此也被称之为动态链接。

早期绑定与晚期绑定

静态链接与动态链接针对的是方法。早期绑定和晚期绑定范围更广。早期绑定涵盖了静态链接，晚期绑定涵盖了动态链接。

静态链接和动态链接对应的方法的绑定机制为：早期绑定（Early Binding）和晚期绑定（Late Binding）。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程，这仅仅发生一次。

  • 早期绑定

早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。

  • 晚期绑定

如果被调用的方法在编译期无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式也就被称之为晚期绑定。

多态与绑定

  1. 随着高级语言的横空出世，类似于Java一样的基于面向对象的编程语言如今越来越多，尽管这类编程语言在语法风格上存在一定的差别，但是它们彼此之间始终保持着一个共性，那就是都支持封装、继承和多态等面向对象特性，既然这一类的编程语言具备多态特性，那么自然也就具备早期绑定和晚期绑定两种绑定方式。

  2. Java中任何一个普通的方法其实都具备虚函数的特征，它们相当于C++语言中的虚函数（C++中则需要使用关键字virtual来显式定义）。如果在Java程序中不希望某个方法拥有虚函数的特征时，则可以使用关键字final来标记这个方法。

虚方法与非虚方法

虚方法与非虚方法的区别

  1. 如果方法在编译期就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法。
  2. 静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法。
  3. 其他方法称为虚方法。

子类对象的多态的使用前提：

  1. 类的继承关系
  2. 方法的重写

虚拟机中调用方法的指令

  • 普通指令：
  1. invokestatic：调用静态方法，解析阶段确定唯一方法版本
  2. invokespecial：调用<init>方法、私有及父类方法，解析阶段确定唯一方法版本
  3. invokevirtual：调用所有虚方法
  4. invokeinterface：调用接口方法
  • 动态调用指令

invokedynamic：动态解析出需要调用的方法，然后执行

前四条指令固化在虚拟机内部，方法的调用执行不可人为干预。而invokedynamic指令则支持由用户确定方法版本。其中invokestatic指令和invokespecial指令调用的方法称为非虚方法，其余的（final修饰的除外）称为虚方法。

关于 invokedynamic 指令

  1. JVM字节码指令集一直比较稳定，一直到Java7中才增加了一个invokedynamic指令，这是Java为了实现【动态类型语言】支持而做的一种改进。

  2. 但是在Java7中并没有提供直接生成invokedynamic指令的方法，需要借助ASM这种底层字节码工具来产生invokedynamic指令。直到Java8的Lambda表达式的出现，invokedynamic指令的生成，在Java中才有了直接的生成方式。

  3. Java7中增加的动态语言类型支持的本质是对Java虚拟机规范的修改，而不是对Java语言规则的修改，这一块相对来讲比较复杂，增加了虚拟机中的方法调用，最直接的受益者就是运行在Java平台的动态语言的编译器。

动态语言和静态语言

  1. 动态类型语言和静态类型语言两者的区别就在于对类型的检查是在编译期还是在运行期，满足前者就是静态类型语言，反之是动态类型语言。

  2. 说的再直白一点就是，静态类型语言是判断变量自身的类型信息；动态类型语言是判断变量值的类型信息，变量没有类型信息，变量值才有类型信息，这是动态语言的一个重要特征。

1
Java：String info = "mogu blog";     		(Java是静态类型语言的，会先编译就进行类型检查)
1
JS：var name = "shkstart";    var name = 10;	（运行时才进行检查）   
Python: info = 130.5 (运行时才检查)
Java语言中方法重写的本质
  1. 找到操作数栈顶的第一个元素所执行的对象的实际类型，记作C。
  2. 如果在类型C中找到与常量中的描述符合简单名称都相符的方法，则进行访问权限校验。
    • 如果通过则返回这个方法的直接引用，查找过程结束
    • 如果不通过，则返回java.lang.IllegalAccessError 异常
  3. 否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程。
  4. 如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。

上面这个过程称为动态分派

IllegalAccessError介绍

  1. 程序试图访问或修改一个属性或调用一个方法，这个属性或方法，你没有权限访问。一般的，这个会引起编译器异常。这个错误如果发生在运行时，就说明一个类发生了不兼容的改变。
  2. 比如，你把应该有的jar包放从工程中拿走了，或者Maven中存在jar包冲突

虚方法表

  1. 在面向对象的编程中，会很频繁的使用到动态分派，如果在每次动态分派的过程中都要重新在类的方法元数据中搜索合适的目标的话就可能影响到执行效率。因此，为了提高性能，JVM采用在类的方法区建立一个虚方法表（virtual method table）来实现，非虚方法不会出现在表中。使用索引表来代替查找。【上面动态分派的过程，我们可以看到如果子类找不到，还要从下往上找其父类，非常耗时】

  2. 每个类中都有一个虚方法表，表中存放着各个方法的实际入口。

  3. 虚方法表是什么时候被创建的呢？虚方法表会在类加载的链接阶段被创建并开始初始化，类的变量初始值准备完成之后，JVM会把该类的虚方法表也初始化完毕。

举例

如下图所示：如果类中重写了方法，那么调用的时候，就会直接在该类的虚方法表中查找

再比如：

  • son在调用toString的时候，Son没有重写过，Son的父类Father也没有重写过，那就直接调用Object类的toString。那么就直接在虚方法表里指明toString直接指向Object类。

  • 下次Son对象再调用toString就直接去找Object，不用先找Son–>再找Father–>最后才到Object的这样的一个过程。

方法返回地址

  1. 存放调用该方法的pc寄存器的值。一个方法的结束，有两种方式：

    • 正常退出：正常执行完成

      • 执行引擎遇到任意一个方法返回的字节码指令（return），会有返回值传递给上层的方法调用者，简称正常完成出口；
      • 一个方法在正常调用完成之后，究竟需要使用哪一个返回指令，还需要根据方法返回值的实际数据类型而定。
      • 在字节码指令中，返回指令包含：

        • ireturn：当返回值是boolean，byte，char，short和int类型时使用

        • lreturn：Long类型

        • freturn：Float类型

        • dreturn：Double类型

        • areturn：引用类型

        • return：返回值类型为void的方法、实例初始化方法、类和接口的初始化方法

    • 异常退出：出现未处理的异常，非正常退出

      • 在方法执行过程中遇到异常（Exception），并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，简称异常完成出口。

      • 方法执行过程中，抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码

        异常处理表：

        • 反编译字节码文件，可得到 Exception table
        • from ：字节码指令起始地址
        • to ：字节码指令结束地址
        • target ：出现异常跳转至地址为 11 的指令执行
        • type ：捕获异常的类型

  2. 无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，调用者的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过异常表来确定，栈帧中一般不会保存这部分信息。

  3. 本质上，方法的退出就是当前栈帧出栈的过程。此时，需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等，让调用者方法继续执行下去。

  4. 正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值。

一些附加信息

栈帧中还允许携带与Java虚拟机实现相关的一些附加信息。例如：对程序调试提供支持的信息。

栈相关面试题

举例栈溢出的情况？

SOF（StackOverflowError），栈大小分为固定的，和动态变化。如果是固定的就可能出现StackOverflowError。如果是动态变化的，内存不足时就可能出现OOM

调整栈大小，就能保证不出现溢出么？

不能保证不溢出，只能保证SOF出现的几率小

分配的栈内存越大越好么？

不是，一定时间内降低了OOM概率，但是会挤占其它的线程空间，因为整个虚拟机的内存空间是有限的

垃圾回收是否涉及到虚拟栈？

不会

位置 是否有Error 是否存在GC
PC计数器 无 不存在
虚拟机栈 有，SOF 不存在
本地方法栈(在HotSpot的实现中和虚拟机栈一样)
堆 有，OOM 存在
方法区 有 存在

方法中定义的局部变量是否线程安全？

具体问题具体分析

  1. 如果只有一个线程才可以操作此数据，则必是线程安全的。
  2. 如果有多个线程操作此数据，则此数据是共享数据。如果不考虑同步机制的话，会存在线程安全问题。

具体问题具体分析：

  • 如果对象是在内部产生，并在内部消亡，没有返回到外部，那么它就是线程安全的，反之则是线程不安全的。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
/**
 * 面试题：
 * 方法中定义的局部变量是否线程安全？具体情况具体分析
 *
 *   何为线程安全？
 *      如果只有一个线程才可以操作此数据，则必是线程安全的。
 *      如果有多个线程操作此数据，则此数据是共享数据。如果不考虑同步机制的话，会存在线程安全问题。
 */
public class StringBuilderTest {

    int num = 10;

    //s1的声明方式是线程安全的（只在方法内部用了）
    public static void method1(){
        //StringBuilder:线程不安全
        StringBuilder s1 = new StringBuilder();
        s1.append("a");
        s1.append("b");
        //...
    }
    //sBuilder的操作过程：是线程不安全的（作为参数传进来，可能被其它线程操作）
    public static void method2(StringBuilder sBuilder){
        sBuilder.append("a");
        sBuilder.append("b");
        //...
    }
    //s1的操作：是线程不安全的（有返回值，可能被其它线程操作）
    public static StringBuilder method3(){
        StringBuilder s1 = new StringBuilder();
        s1.append("a");
        s1.append("b");
        return s1;
    }
    //s1的操作：是线程安全的（s1自己消亡了，最后返回的只是s1.toString的一个新对象）
    public static String method4(){
        StringBuilder s1 = new StringBuilder();
        s1.append("a");
        s1.append("b");
        return s1.toString();
    }

    public static void main(String[] args) {
        StringBuilder s = new StringBuilder();


        new Thread(() -> {
            s.append("a");
            s.append("b");
        }).start();

        method2(s);

    }

}

To Be Continue