[JVM]超详细JVM系列文（1）：整体结构+类加载子系统+运行时数据区—程序计数器、栈（多图长文）

JVM整体结构与概述

#多图长文预警#
介绍了JVM中其中各个模块的结构与功能（主要包括类装载子系统、运行是数据区中的程序计数器与栈）。按照Java代码执行的流程，从类装载器子系统出发，剖析其各个子模块的结构与功能。结合Java语言中的相关设计思路（变量的初始化、存储；对象的生命周期、方法的调用）、OOP（继承、多态），在JVM进行追根溯源，解释其本质。
后续博文将介绍运行时数据区中堆、方法区，垃圾回收与调优等。

首先是JVM的结构图。

更加详细版：

Java代码执行流程

JVM的架构模型

Java编译器输入的指令流基本上是一种基于栈的指令架构，另外一种指令集架构则是基于寄存器的指令集架构

具体来说，这两种架构之间的区别：

• 基于栈式架构的特点
  • 设计和实现更加简单，适用于资源受限的系统；
  • 避开了寄存器的分配难题：使用零地址指令方式分配
  • 指令流中的指令大部分是零地址指令，其执行过程依赖于操作栈。指令集更小，编译器更容易实现。
  • 不需要硬件支持，可移植性更好，更好实现跨平台
• 基于寄存器架构的特点
  • 典型的应用是x86的二进制指令集：传统PC以及Android的Davlik虚拟机
  • 指令集架构则完全依赖硬件，可移植性差
  • 性能优秀和执行更高效；
  • 花费更少的指令去完成一项操作。
  • 在大部分情况下，基于寄存器架构的指令集往往都是以一地址指令，二地址指令和三地址指令为主。而基于栈式架构的指令集都是以零地址指令为主

小结：

由于跨平台性的设计，Java的指令都是根据栈来设计的。不同平台CPU架构不同，所以不能设计为基于寄存器的。

优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令。

JVM的生命周期

1. 虚拟机的启动

   Java虚拟机的启动是通过引导类加载器(bootstrap Class Loader)创建一个初始类（initial class）来完成的，这个类是由虚拟机的具体实现指定的。

2. 虚拟机的执行

   • 一个运行中的Java虚拟机有着一个清晰的任务：执行Java程序
   • 程序开始执行时他才运行，程序结束时他就停止
   • 执行一个所谓的Java程序的时候，真真正正在执行的是一个叫做Java虚拟机的进程。

3. 虚拟机的退出

   有如下几种情况：

   • 程序正常执行结束
   • 程序在执行过程中遇到了异常或错误而异常终止
   • 由于操作系统出现错误而导致Java虚拟机进程终止
   • 某线程调用Runtime类或System类的exit方法，或Runtime类的halt方法，并且Java安全管理器也允许exit或halt操作
   • 另外，JNI（Java Native Interface）规范描述了用JNI Invocation API来加载或卸载虚拟机时，Java虚拟机的退出情况

JVM发展历程

Sun classic VM

• 96年Java1.0版本时，Sun公司发布了一款叫Sun Classic VM的虚拟机。他是世界上第一款商用Java虚拟机。JDK1.4时被淘汰。
• 这款虚拟机内部只提供解释器
• 如果使用JIT编译器，就需要进行外挂。但是一旦使用了JIT编译器，JIT就会接管虚拟机的执行系统。解释器就不再工作。解释器和编译器不能配合工作。
• 现在HotSpot内置了此虚拟机。

下图是解释器和JIT的工作模式

只提供解释器，效率低下，因为要逐行进行解释。而有了JIT，会把多次使用的代码（热点代码）翻译成本地机器指令缓存起来。

Sun公司的 HotSpot VM

目前HotSpot占有绝对的市场地位。

• JDK8等默认的虚拟机都是HotSpot。本系列文默认介绍的都是Hotspot。相关机制也是HotSpot
• 名称中的HotSpot指的就是它的热点代码探测技术
  • 通过计数器找到最具有编译价值的代码，触发即时编译或栈上替换
  • 通过编译器与解释器协同工作，在最优化的程序响应时间与最佳执行性能中取得平衡

BEA的JRockit

• 专注与服务器端的应用
  • 它可以不太关注程序启动速度，因此JRockit内部不包含解析器实现，全部代码都靠即时编译器编译后执行
• 大量的行业基准测试显示，JRockit JVM是世界上最快的JVM
  • 使用JRockit产品，客户已经体验到了显著的性能提高（一些超过了70%）和硬件成本的减少（50%）
• 优势：全面的Java运行时解决方案组合
  • JRockit面向延迟敏感型应用的解决方案JRockit Real Time提供以毫秒或微秒级的JVM响应时间，适合财务、军事指挥、电信网络的需要

类加载子系统

类加载器与类的加载过程

• 类加载器子系统负责从文件或者网络中加载Class文件，class文件在文件开头有特定的文件标识
• ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定
• 加载的类信息存放在一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

1. class file 存在于本地硬盘上，可以理解为设计师在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
2. class file 加载到JVM中，被称为DNA元数据模板，放在方法区
3. 在.class文件 => JVM => 最终成为元数据模板，此过程就要一个运输工具（类装载器 ClassLoader） 扮演一个快递员的角色。

更为详细地来说，Class Loader加载class file 可分为如下流程

加载Loading过程

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

补充：加载.class文件的方式

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

链接Linking过程

验证（Verify）

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

准备（Prepare）

• 为类变量分配内存并且设置该类变量的默认初始值，即零值
• 这里不包含分配内存给用final修饰的static，因为final在编译时就会分配了，准备阶段会显示初始化
• **这里不会为实例变量分配初始化，**类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。

解析（Resolve）

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

• 事实上，解析操作往往会伴随着JVM在执行完初始化之后在执行
• 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。
  直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
• 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info, CONSTANT_Fieldref_info, CONSTANT_Methodref_info等

在后面的运行时数据区的方法调用部分我们还会谈到：

在类的加载的解析阶段，会将一部分符号引用转化为直接引用，这种解析能成立的前提是：方法在程序运行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。。。

初始化过程

• 初始化阶段就是执行类构造器方法< Clinit >()的过程
• 此方法不需要定义，是javac 编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来
• 构造器方法中指令按语句在源文件中出现的顺序执行
• <clinit>() 不同于类的构造器。（构造器是虚拟机视角下的<init>()）
• 若该类具有父类，JVM会保证子类的<Clinit>（）执行前，父类的<Clinit>（）已经执行完毕
• 虚拟机必须保证一个类的<Clinit>（）方法在多线程下被同步加锁

实验：

public class ClassInitTest {
    private static  int num = 1;
    
    static {
        num = 2;
        number = 20;
        System.out.println(num);
//        System.out.println(number); // error： 非法的前向引用
    }
    
    private static int number = 10; //Linking中Prepare： number = 0 --> initial: 20 --> 10

    public static void main(String[] args) {
        System.out.println(ClassInitTest.num);  //2
        System.out.println(ClassInitTest.number);//10

    }

注意：尽管看上去number声明定义并立刻赋值为10，但是实际上：

1. number是先在链接中的准备阶段被分配内存并设置为初始值 0
2. 在初始化阶段按照static块顺序依次赋值为20 和 10

注意：第8行是怎么回事呢？

声明的变量number在后面，在前面的静态代码块中可以为其赋值，但是不能调用它

类加载器ClassLoader分类与各类别介绍

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

注意的是：引导类加载器通过 获取加载器的方法调用时返回的是null

下面在细说一下这几种加载器：

• 虚拟机自带的加载器
  • 启动类加载器（引导类加载器， BootStrap ClassLoader）
    • 这个类加载使用C/C++语言实现，嵌套在JVM内部。（这就是我获取不到的原因？）
    • 它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar 、resource.jar 或 sun.boot.class.path路径下的内容），用于提供JVM自身需要的类，（改进有点像Linux的boot引导模块hhh）
    • 并不继承自java.lang.ClassLoader，无父加载器
    • 出于安全考虑，Bootstrap启动类加载器只加载包含名为java、javax、sun开头的类
  • 拓展类加载器（Extendsion ClassLoader）
    • Java语言编写，由 sun.misc.Launcher$ExtCLassLoader 实现
    • 派生于ClassLoader类
    • 父类加载器为启动类加载器
    • 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的 jre/lib/ext子目录下加载类库。如果用户创建的JAR放在此目录下，也会自动扩展类加载器加载。
  • 应用程序类加载器（系统类加载器 AppCLassLoader）
    • Java语言编写，由sun.misc.Launcher$AppClassLoader 实现
    • 派生于ClassLoader类
    • 父类加载器为扩展类加载器
    • 它负责加载环境变量classpath或系统属性 java.class.path 指定路径下的类库
    • 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
    • 通过ClassLoader#getSystemClassLoader() 可以获取到该类加载器

• 用户自定义类加载器
  • 在Java的日常开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们可以自定义类加载器，来定制类的加载方式。
  • 为何要自定义类加载器？
    • 隔离加载类
    • 修改类加载的方式
    • 扩展加载源
    • 防止源码泄露

获取ClassLoader的途径

public class ClassLoaderTest2 {
    public static void main(String[] args) {
        try {
            //1
            ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
            System.out.println(classLoader);
            //2
            ClassLoader classLoader1 = Thread.currentThread().getContextClassLoader();
            System.out.println(classLoader1);
            //3
            ClassLoader classLoader2 = ClassLoader.getSystemClassLoader().getParent();
            System.out.println(classLoader2);

        }catch (ClassNotFoundException e){
            e.printStackTrace();
        }
    }
}

双亲委派机制

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

工作原理

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

优势：

• 避免类的重复加载
• 保护程序安全，防止核心API被随意篡改

沙箱安全机制

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

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

• 类的完整名必须一致，包括包名
• 加载这个类的ClassLoader（指ClassLoader实例化对象）必须相同

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

对类加载器的引用

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

类的主动使用和被动使用

Java程序对类的使用方式分为：主动使用和被动使用

• 主动使用包括下述情况：

  • 创建类实例

  • 访问某个类或接口的静态变量，或者对该静态变量赋值

  • 调用类的静态方法

  • 初始化一个类的子类

  • Java虚拟机启动时被标明为启动类的类

  • JDK7开始提供的动态语言支持：

    java.lang.invoke.MethodHandle 实例的解析结果

    REF_getStatic, REF_putStatic, REF_invlkeStatic 句柄对应的类没用初始化，则初始化

• 除了上述七种情况，其他使用Java类的方式都被看作是对类的 被动调用 ，都不会造成类的初始化

运行时数据区

著名结构图 （完整的在前面）

更为详细的版本：

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

Java虚拟机定义了若千种程序运行期间会使用到的运行时数据区，其中有一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与线程一一对应的，这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。

如下图：

灰色的为单线程私有的，红色的为多个线程共享。即：

• 每个线程：独立包括程序计数器、栈、本地栈。
• 线程间共享：堆、堆外内存（永久代或元空间、代码缓存）

线程

操作系统能够进行运算资源调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。

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

精灵（守护）线程 Daemon Thread：

当一个应用程序的所有非精灵（用户）线程停止运行时，即使仍有精灵线程还在运行，该应用程序也将终止，反过来，只要还有非精灵线程在运行，应用程序就不会停止。可以通过setDaemon(boolean on)来设置某线程为精灵线程。用isDaemon（）来判断某线程是否为精灵线程或守护线程。注意：要想设置一个线程为精灵守护线程，setDaemon必须在start前调用。

简言之， 只要当前JVM实例中尚存在任何一个非守护线程没有结束，守护线程就全部工作；只有当最后一个非守护线程结束时，守护线程随着JVM一同结束工作。
Daemon的作用是为其他线程的运行提供便利服务，守护线程最典型的应用就是 GC (垃圾回收器)，它就是一个很称职的守护者。

好了，了解了基本概述与结构，下面我们来分别康康运行时数据区的各个部分。

程序计数器（PC寄存器）

JVM中的程序计数寄存器（Program Counter Register）中，Register的命名源于CPU的寄存器，寄存器存储指令相关的现场信息。CPU只有把数据装载到寄存器才能运行。

这里并非广义上所指的物理寄存器，获取将其翻译为PC计数器更为贴切**。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟，。**

PC寄存器作用： PC寄存器用来存储指向下一条指令的地址，也即将要执行的指令代码。由执行引擎读取下一条指令

PC寄存器的特点：

• 他是一块很小的内存空间，几乎可以忽略不计。也是运行速度最快的存储区域。
• 在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的周期保持一致
• 任何时间一个线程都只有一个方法在执行，也就是所谓的***当前方法***。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址；或者，如果是在执行native方法，则是未指定值（undefined）
• 他是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
• 字节码解释器工作就是通过改变这个计数器的值来选取下一条需要执行的字节码指令
• 他是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域

使用举例

两个常见问题

1.使用PC寄存器存储字节码指令有什么用呢？为啥使用PC寄存器记录当前线程的执行地址？

​ 因为CPU需要不停地切换各个线程，这时候切换回来后，就得知道接着从哪开始继续执行。JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令。

2.PC寄存器为啥设计成线程私有的？

我们都知道所谓的多线程在一个特定的时间段内只会执行其中某一个线程的方法，CPU会不停地做任务切换，这样必然导致经常中断或恢复，如何保证分毫无差呢? 为了能够准确地记录各个线程正在执行的当前字节码指令地址，最好的办法自然是为每一个线程都分配一个PC寄存器，这样一来各个线程之间便可以进行独立计算，从而不会出现相互干扰的情况。

由于CPU时间片轮限制，众多线程在并发执行过程中，任何一个确定的时刻，一个处理器或者多核处理器中的一个内核，只会执行某个线程中的一条指令。

这样必然导致经常中断或恢复，如何保证分毫无差呢?每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器在各个线程之间互不影响。

虚拟机栈

概述

​ Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at the same time as the thread. A Java Virtual Machine stack stores frames (§2.6). A Java Virtual Machine stack is analogous to the stack of a conventional language such as C: it holds local variables and partial results, and plays a part in method invocation and return. Because the Java Virtual Machine stack is never manipulated directly except to push and pop frames, frames may be heap allocated. The memory for a Java Virtual Machine stack does not need to be contiguous.

由于跨平台性的设计，Java的指令都是根据栈来设计的。不同平台CPU架构不同，所以不能设计为基于寄存器的。

优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令。

不少Java开发人员一提到Java内存结构，就会非常粗粒度地将JVM中的内存区理解为仅有Java堆和Java栈。

栈是运行时的单位，而堆是存储的单位

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

• Java虚拟机栈是什么?

  Java虚拟机栈(Java Virtual Machine stack)，早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧(Stack Frame) ，对应着一 次次的Java方法调用。

  是线程私有的

• 生命周期
  生命周期和线程–致。

• 作用
  主管Java程序的运行，它保存方法的局部变量(8种基本数据类型、对象的引用地址)、部分结果，并参与方法的调用和返回。

  局部变量 vs成员变量(或属性)

  基本数据变量 vs引用类型变量(类、数组、接口)

栈帧就是一个一个的方法

• 栈的特点(优点)
  • 栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。
  • JVM直接对Java栈的操作只有两个:
    1. 每个方法执行，伴随着进栈(入栈、压栈)
    2. 执行结束后的出栈工作I
  • 对于栈来说不存在垃圾回收问题

栈中可能出现的异常

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

• 如果采用固定大小的Java虚拟机栈，那每个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量，Java 虚拟机将会抛出一个StackOverflowError异常。
• 如果Java虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那Java虚拟机将会抛出一个 OutofMemoryError 异常。

实验

栈中存储什么？

• 每个线程都有自己的栈，栈中的数据都是以栈帧（Stack Frame）的格式存在。

• 在这个线程上正在执行的每个方法都各自对应一个栈帧

• 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息

• JVM直接对Java栈的操作只有两个，就是对栈帧的压栈和出栈，遵循“先进后出”/“后进先出”原则。

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

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

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

栈运行原理注意

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

栈帧的内部结构

每个栈帧中存储着: （加粗为重点）

• 局部变量表(Local Variables)
• 操作数栈(operand stack) ( 或表达式栈)
• 动态链接(Dynamic Linking) (或指向运 行时常量池的方法引用)
• 方法返回地址(Return Address) (或方法正常退出或者异常退出的定义)
• 一些附加信息
  

下面来挨个康康这些结构叭~

局部变量表 local variables

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

关于Slot的理解

局部变量表的容量以变量槽（Variable Slot）为基本存储单位。参数值得存放总是在局部变量数组的index0开始，到数组长度-1的索引结束。

虚拟机规范并未明确指明一个Slot应占的内存空间大小应占的空间大小，只是很导向性地说到每个Slot应该能存放一个 boolean、 byte、 char、 short、 int 、float 、 reference 或 returnAddress 类型的数据。这8种数据类型都可以用32为或更小的物理内存来存放。 具体来看， byte 、short、char在存储前被转换为int，boolean也被转换为int，0为false。

那么64位类型的 long 和 double呢？ 当然是占用两个slot。

上面的reference类型表示 对一个对象实例的引用，虚拟机规范并未说明它的长度，也没说明这种引用应该有怎样的结构。但一般来说，虚拟机实现至少应该通过这个引用做到两点：

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

JVM会为局部变量表中的每一个Slot都分配 一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值

当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个slot上

• 如果需要访问局部变量表中一个64bit的局部变量值时，只需要使用前一个索引即可。(比如:访问long或double类 型变量)
• 如果当前帧是由构造方法或者实例方法创建的，那么该对象引用this将会存放在index为0的slot处，其余的参数按照参数表顺序继续排
  列。

slot的重复使用

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

举例：静态变量与局部变量的对比

我们知道类变量表有两次初始化的机会，第一次在 准备阶段， 执行系统初始化，对类变量设置0值，另一次则是在 初始化 阶段，赋予程序员在代码中定义的初始值。

和类变量初始化不同的是，局部变量表不存在系统初始化的过程，这意味着一旦定义了局部变量就必须认为地初始化，否则无法使用

public void test(){
    int i;
    System.out.println(i);
}

这样的代码是错误的，没有赋值不能够使用。

补充：变量的分类：

• 按照数据类型分：

1. 基本数据类型

   2. 引用数据类型

• 按照在类中声明的位置分：

1. 成员变量：在使用前都经历过默认初始化赋值

   • 类变量：linking的prepare阶段：给类变默认赋值 ==> initination ：给类变量显示赋值即静态代码块显示赋值

• 实例变量：随着对象的创建，会在堆空间中分配实例变量空间，并进行默认赋值

2. 局部变量：在使用前，必须进行显示赋值！否则编译不通过。

操作数栈

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

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

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

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

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

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

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

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

操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈(push)和出栈(pop)操作来完成一次数据访问。

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

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

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

代码追踪

    public  void testAddOperation(){
        byte i = 15;
        int j =8 ;
        int k = i + j;
    }

 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

1. 首先执行偏移地址为0的指令，bipush指令的作用是将单字节的整型常量值（-128 ~ 127）推入操作数栈顶，跟随有一个参数，指明推送的常量值，这里是15.

2. 执行偏移地址为2的指令，istrore_1指令的作用是将操作数栈顶的整型数值出栈并存放到第1个局部变量Slot（第0个放this了）。后续的2条指令也是做同样的事情，也就是在对应代码中i，j赋值为15和8.

3. 执行地址为6的指令，iload_1指令的作用是将局部变量表第一个Slot中的整型值复制到操作数栈顶

4. 执行7，iload_2指令的执行过程与iload_1类似，把第二个Slot的整型值入栈。
   

5. 执行偏移地址为7的指令，iadd指令的作用是将操作数栈中头两个元素出栈，做整型加法，然后把结果重新入栈。在iadd指令执行完成后，栈中原有的15和8出栈，和23入栈。注意，在iadd时，需要执行引擎的帮忙，将其翻译为机器指令

6. 执行9：istore_3指令把栈顶的23存放在第3个局部变量Slot中。

栈顶缓存

前而提过，基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派(instruction dispatch) 次数和内存读/写次数。

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

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

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

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

方法调用

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

• 静态链接：

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

• 动态链接：

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

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

• 早期绑定：

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

• 晚期绑定

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

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

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

虚方法、非虚方法

如果方法在编译期就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法。

虚拟机中提供了以下几条方法调用指令：

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

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

关于invokedynamic指令

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

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

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

分派

这里专门用一些笔墨来介绍分派调用。分派调用过程将会揭示多态性特征的一些最基本的体现，如 重载 和 重写 在Java虚拟机中时如何实现的，这里主要关心的是虚拟机如何确定正确的目标方法。

1. 静态分派

   看下面代码：

   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 Man!");
       }
   
       public void sayHello(Woman guy){
           System.out.println("Hello Woman!");
       }
   
       public static void main(String[] args) {
           Human man = new Man();
           Human woman = new Woman();
           StaticDispatch sr = new StaticDispatch();
           sr.sayHello(man);	//Hello guy!
           sr.sayHello(woman); //Hello guy!
       }
   }
   
   

   运行结果都是 Hello guy! 。先看两概念：

   Human man = new Man();
   

   上面代码中：Human 称为变量的 静态类型 ，后面的Man称之为实际类型。静态类型和实际类型在程序中都可以发生一些变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的；而实际类型变化的结果在运行期才可决定，编译器在编译程序时并不会知道一个对象的实际类型是什么。

   在上面的例子中，main里面两次调用sayHello方法，在方法接收者已经确定方法时对象”sr“的前提下，使用哪个重载版本，就完全取决于传入参数的数量和数据类型。

   代码刻意定义了两个静态类型相同但实际类型不同的变量，但虚拟机（准确来说是编译器） 在重载时是通过参数的静态类型而不是实际类型作为判定依据的。并且静态类型是在编译期可知的，因此，编译阶段，Javac编译器会根据参数的静态类型确定重载版本。所以选择了sayHello(Human)作为目标。

   所以依赖静态类型来定位方法执行版本的分派动作称为静态分派。静态分派的典型应用是方法重载。静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机执行的。

   另外，编译器虽然能确定出方法的重载版本，但很多情况下这个重载版本并不是唯一的，往往只能确定一个”更加合适的“版本，产生这种模糊结论的主要原因是字面量不需要定义，所以字面量没有显示的静态类型，他的静态类型只能通过语言上的规则去理解和推断。《深入理解虚拟机（第二版）》P249展示了重载方法匹配的优先级。

   简言之，重载自动转型按照 char -> int -> long -> float -> double 的顺序转型进行匹配。但不会匹配到 byte 和 short 类型的重载，因为char到byte或short的转型是不安全的。

2. 动态分派

   动态分派和多态性的另一个体现——重写（Override） 有着密切联系。看下面代码：

   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();; //Man say Hello
          woman.sayHello();//woman say Hello
   
          man = new Woman();
          man.sayHello();; //woman say Hello
      }
   
   }
   
   

   大家对这个结果十分同意了，多态嘛。导致这个现象的原因在于这两个变量的实际类型不同，Java虚拟机是如何根据实际类型来分派方法执行版本的呢？来康康字节码文件：

     public static void main(java.lang.String[]);
       descriptor: ([Ljava/lang/String;)V
       flags: ACC_PUBLIC, ACC_STATIC
       Code:
         stack=2, locals=3, args_size=1
            0: new           #2                  // class /jvm/DynamicDispatch$Man
            3: dup
            4: invokespecial #3                  // Method /jvm/DynamicDispatch$Man."<init>":()V
            7: astore_1
            8: new           #4                  // class /jvm/DynamicDispatch$Woman
           11: dup
           12: invokespecial #5                  // Method /jvm/DynamicDispatch$Woman."<init>":()V
           15: astore_2
           16: aload_1
           17: invokevirtual #6                  // Method /jvm/DynamicDispatch$Human.sayHello:()V
           20: aload_2
           21: invokevirtual #6                  // Method /jvm/DynamicDispatch$Human.sayHello:()V
           24: new           #4                  // class /jvm/DynamicDispatch$Woman
           27: dup
           28: invokespecial #5                  // Method /jvm/DynamicDispatch$Woman."<init>":()V
           31: astore_1
           32: aload_1
           33: invokevirtual #6                  // Method /jvm/DynamicDispatch$Human.sayHello:()V
           36: return
         LineNumberTable:
           line 25: 0
           line 26: 8
           line 27: 16
           line 28: 20
           line 30: 24
           line 31: 32
           line 32: 36
   

   0到15行字节码是准备动作，作用好似建立man和woman的内存空间、调用Man和Woman类型的实例构造器，将这两个实例的引用存放在第1、2个局部变量表Slot之中，这个动作也就对应了代码中的：

   Human man  = new Man();
   Human woman = new Woman();
   

   接下来的16到21句是关键，16、20两句分别把刚刚创建的两个对象引用压到了栈顶，这两个对象时将要执行sayHello()方法的所有者，称为接收者（Receiver）；17和21句是方法调用指令，这两条调用指令单从字节码角度来看，无论是指令（都是invokevirtual）还是参数（注释显示了这是Human.sayHello()的符号引用）完全一样的，但是这两句指令最终执行的目标方法并不相同。原因就在于invokevirtual指令的多态查找过程，invokevirtual指令的运行时解析过程大致分为以下几个步骤：

   1）找到操作数栈顶的第一个元素指向的对象的实际类型，记做C

   2）如果在类型C中找到与常亮中的描述符和简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回java.lang.IllegalAccessError异常。

   3）否则，按照继承关系从下往上以此对C的各个父类进行第二步的搜索和验证过程。

   4）如果失踪没有找到合适的方法则抛出java.lang.AbstractMethodError异常。

   由于invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型，所以两次调用中的invokevirtual指令吧常量池中的类方法符号引用解析到了不同的直接引用上，这个过程就是Java语言中重写的本质。我们把这种在运行期根据实际类型确定执行方法执行版本的分派过程称为动态分派。

补充：动态类型语言和静态类型语言

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

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

Java：		 String info = “hello”；
JS：		 var name = "heloo";
Python: 		info = 130.5;

虚方法表

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

虚方法表中存放着各个方法的实际入口地址。如果某方法在子类中没有被重写，那么子类的虚方法表里面的地址入口和父类相同方法的地址入口时一致的，都指向父类的实现入口。如果子类中重写了这个方法，子类方法表中的地址将会替换为指向子类实现版本的入口地址。

方法返回地址 Return Address

存放调用该方法的PC寄存器的值。

一个方法的结束，有两种方式：

• 正常执行完成
• 出现未处理的异常，非正常退出

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

当一个方法开始执行后，只有两种方式可以退出这个方法:

1. 执行引擎遇到任意-一个方法返回的字节码指令(return) ，会有返回值传递给上层的方法调用者，简称正常完成出口;

   • 一个方法在正常调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定。
   • 在字节码指令中，返回指令包含ireturn (当返回值是boolean、byte、char.short和int类型时使用)、lreturn、 freturn、 dreturn 以及areturn,另外还有一个return指令供声明为void的方法、实例初始化方法、类和接口的初始化方法使用。

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

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

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

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

一些附加信息

虚拟机规范允许具体的虚拟机实现增加一些规范里没有描述的信息加到栈帧中，例如调试相关的信息，这部分取决于具体虚拟机的实现。

本地方法接口

现在我们先暂时跳出运行时数据区，先来看看虚拟机的另外一个组成部分：本地方法接口

什么是本定方法？

简单地讲，一个Native Method就是一个Java调用非Java代码的接口。一个Native Method是这样一个Java方法:该方法的实现由非Java语言实现，比如C.这个特征并非Java所特有，很多其它的编程语言都有这一机制，比如在C++中, 你可以用extern "C"告 知C++编译器去调用-一个C的函数。

“A native method is a Java method whose implementation isprovided by non-java code.”

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

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

文章实在是有点长，小结一下介绍了些啥：

• JVM整体结构与概述

  • 结构图、
  • 执行流程
  • 架构模型
    • 基于栈的指令集架构
    • 基于寄存器的指令集架构
  • 生命周期：启动、执行、退出
  • 发展历程

• 类加载子系统

  • 类加载器与类的加载过程
  • 加载Loading过程、方式：二进制字节流 --> 字节流代表的静态存储结构转化为运行时数据结构 --> 在内存中胜出一个代表这个类的 java.lang.Class对象
  • 链接Linking过程：
    • 验证: 确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全
    • 准备：为类变量分配内存并且设置该类变量的默认初始值，即零值
    • 解析：将常量池的符号引用转换为直接引用
  • 初始化Initialization过程：执行类构造器方法<Clint>的过程
  • 类加载器ClassLoader分类与各类别介绍、获取ClassLoader的途径
    • 启动类加载器（引导类加载器， BootStrap ClassLoader）
    • 拓展类加载器（Extendsion ClassLoader）
    • 应用程序类加载器（系统类加载器 AppCLassLoader）
    • 用户自定义加载器
  • 双亲委派机制、沙箱安全机制
  • 类的主动使用和被动使用

• 运行时数据区

  • 结构、概述：内存布局规定了Java在运行过程中内存申请、分配、管理的策略，保证了JVM的高效稳定运行。一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与线程一一对应的，这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。

  • 程序计数器

    • 作用： 指向下一条指令的地址，也即将要执行的指令代码。由执行引擎读取下一条指令
    • 特点：是一小块空间，运行速度贼快。线程私有。任何时间一个线程只有一个方法在执行

  • 虚拟机栈

    • 是什么，栈帧。生命周期：和线程一致。作用：主管Java程序的运行，它保存方法的局部变量(8种基本数据类型、对象的引用地址)、部分结果，并参与方法的调用和返回。特点：快速有效的分配存储方式，访问速度仅次于程序计数器。不存在垃圾回收问题

    • 栈中的存储：栈帧。栈帧内部结构：

      • 局部变量表(Local Variables) 。 Slot的理解
      • 操作数栈(operand stack) ( 或表达式栈)
      • 动态链接(Dynamic Linking) (或指向运 行时常量池的方法引用)
      • 方法返回地址(Return Address) (或方法正常退出或者异常退出的定义)
      • 一些附加信息

    • 方法调用

      • 虚方法非虚方法

      • 分派。

        ​ 静态分派 --> 静态类型 --> 重载
        ​ 动态分派 --> 实际类型 --> 重写 --> 多态

      • 虚方法表

  • 本地方法接口

在下一篇文章中，我们将回到运行时数据区中主要介绍堆、垃圾回收等相关知识。敬请期待~