如果我们把核心类库的API比作数学公式的话，那么Java虚拟机的知识就好比公式的推导过程。

JVM与Java体系结构

JVM：跨语言的平台

• 随着Java7的正式发布，Java虚拟机的设计者们通过JSR-292规范基本实现再Java虚拟机平台上运行非Java语言编写的程序。

• Java虚拟机根本不关心运行在其内部的程序到底是使用何种编程语言编写的，它只关心“字节码”文件。也就是说Java虚拟机拥有语言无关性，并不会单纯地与Java语言“终身绑定”，只要其他编程语言的编译结果满足并包含Java虚拟机的内部指令集、符号表以及其他的辅助信息，它就是一个有效的字节码文件，就能够被虚拟机所识别并装载运行。

字节码

• 我们平时说的Java字节码，指的是用Java语言编译成的字节码。准确的说任何能在JVM平台上执行的字节码格式都是一样的。所以应该统称为：JVM字节码。

• 不同的编译器，可以编译出相同的字节码文件，字节码文件也可以在不同的JVM上运行。

• Java虚拟机与Java语言并没有必然的联系，它只与特定的二进制文件格式—class文件格式所关联，class 文件中包含了Java虚拟机指令集（或者称为字节码、Bytecodes）和符号表，还有一些其他辅助信息。

多语言编程

• Java平台上的多语言混合编程正成为主流，通过特定领域的语言去解决特定领域的问题是当前软件开发应对日趋复杂的项目需求的一个方向。

• 试想一下，在一个项目之中，并行处理用clojure语言编写，展示层使用JRuby/Rails，中间层则是Java，每个应用层都将使用不同的编程语言来完成，而且，接口对每一层的开发者都是透明的，各种语言之间的交互不存在任何困难，就像使用自己语言的原生API一样方便，因为它们最终都运行在一个虚拟机之上。

• 对这些运行于Java虚拟机之上、Java之外的语言，来自系统级的、底层的支持正在迅速增强，以JSR-292为核心的一系列项目和功能改进（如Davinci Machine项目、Nashorn引擎、InvokeDynamic指令、java. lang.invoke包等)，推动Java虚拟机从“Java语言的虚拟机”向“多语言虚拟机”的方向发展。

Java发展的重大事件

虚拟机与Java虚拟机

虚拟机

• 所谓虚拟机(Virtual Machine)，就是一台虚拟的计算机。它是一款软件，用来执行一系列虚拟计算机指令。大体上，虚拟机可以分为系统虚拟机和程序虚拟机。
• 大名鼎鼎的Visual Box，VMware就属于系统虚拟机，它们完全是对物理计算机的仿真，提供了一个可运行完整操作系统的软件平台。
• 程序虚拟机的典型代表就是Java虚拟机，它专门为执行单个计算机程序而设计，在Java虚拟机中执行的指令我们称为Java字节码指令。

• 无论是系统虚拟机还是程序虚拟机，在上面运行的软件都被限制于虚拟机提供的资源中。

Java虚拟机

• Java虚拟机是一台执行Java字节码的虚拟计算机，它拥有独立的运行机制,其运行的Java字节码也未必由Java语言编译而成。

• JVM平台的各种语言可以共享Java虚拟机带来的跨平台性、优秀的垃圾回器，以及可靠的即时编译器。

• Java技术的核心就是Java虚拟机（JVM，Java virtual Machine） ,因为所有的Java程序都运行在Java虚拟机内部。

JVM的整体结构

• HotSpot VM 是市面上高性能虚拟机的代表作之一

• 它采用解释器与即时编译器并存的架构

• 在今天，Java程序的运行性能早已脱胎换骨，已经达到了可以和C/C++程序一较高下的地步

Java代码执行流程

JVM的架构模型

• 基于栈式架构的特点
• 设计和实现更简单，适用于资源受限的系统；
• 避开了寄存器的分配难题:使用零地址指令方式分配。
• 指令流中的指令大部分是零地址指令，其执行过程依赖于操作栈。指令集更小，编译器容易实现。 不需要硬件支持，可移植性更好，更好实现跨平台

• 基于寄存器架构的特点
• 典型的应用是x86的二进制指令集:比如传统的Pc以及Android的Davlik虚拟机。
• 指令集架构则完全依赖硬件，可移植性差
• 性能优秀和执行更高效;
• 花费更少的指令去完成一项操作。 在大部分情况下，基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主，而基于栈式架构的指令集却是以零地址指令为主。

JVM的生命周期

虚拟机的启动

虚拟机的执行

• 一个运行中的Java虚拟机有着一个清晰的任务：执行Java程序

• 程序开始执行时他才运行，程序结束时他就停止

• 执行一个所谓的Java程序的时候，真真正正的执行的是一个叫做Java虚拟机的进程

虚拟机的退出

• 程序正常执行结束

• 程序在执行过程中遇到了异常或错误而异常终止

• 由于操作系统出现错误而导致Java虚拟机进程终止

• 某线程调用Runtime类或system类的exit方法，或 Runtime类的halt方法，并且Java安全管理器也允许这次exit或halt操作。

• 除此之外，JNI ( Java Native Interface)规范描述了用JNI Invocation API来加载或卸载Java虚拟机时，Java虚拟机的退出情况。

JVM发展历程

Sun Classic VM

• 早在1996年Java1.o版本的时候，sun公司发布了一款名为Sun Classic VM的Java虚拟机，它同时也是世界上第一款商用Java虚拟机，JDK 1.4时完全被淘汰。

• 这款虚拟机内部只提供解释器。

• 如果使用JIT编译器，就需要进行外挂。但是一旦使用了JIT编译器，JIT就会接管虚拟机的执行系统。解释器就不再工作。解释器和编译器不能配合工作。

• 现在hotspot内置了此虚拟机。

Exact VM

• 为了解决上一个虚拟机问题，jdk1.2时，sun提供了此虚拟机。

• Exact Memory Management：准确式内存管理
• 也可以叫Non-Conservative/Accurate Memory Management
• 虚拟机可以知道内存中某个位置的数据具体是什么类型。

• 具备现代高性能虚拟机的雏形
• 热点探测
• 编译器与解释器混合工作模式

• 只在Solaris平台短暂使用，其他平台上还是classic vm
• 英雄气短，终被Hotspot虚拟机替换

HotSpot VM

• Hotspot历史
• 最初由一家名为“Longview Technologies”的小公司设计
• 1997年，此公司被Sun收购；2009年，Sun公司被甲骨文收购。
• JDK1.3时，HotSpot VM成为默认虚拟机

• 目前Hotspot占有绝对的市场地位，称霸武林。
• 不管是现在仍在广泛使用的JDK6，还是使用比例较多的JDK8中，默认的虚拟机都是HotSpot Sun/Oracle JDK和 Open JDK的默认虚拟机

• 从服务器、桌面到移动端、嵌入式都有应用。

• 名称中的HotSpot指的就是它的热点代码探测技术。
• 通过计数器找到最具编译价值代码，触发即时编译或栈上替换
• 通过编译器与解释器协同工作，在最优化的程序响应时间与最佳执行性能中取得平衡

JRockit

• 专注于服务器端应用
• 它可以不太关注程序启动速度，因此JRockit内部不包含解析器实现，全部代码都靠即时编译器编译后执行。

• 大量的行业基准测试显示，JRockit JVM是世界上最快的JVM。
• 使用JRockit产品，客户已经体验到了显著的性能提高（一些超过了70% )和硬件成本的减少(达50%）。

• 优势：全面的Java运行时解决方案组合
• JRockit面向延迟敏感型应用的解决方案JRockit Real Time提供以毫秒或微秒级的JVM响应时间，适合财务、军事指挥、电信网络的需要
• MissionControl服务套件，它是一组以极低的开销来监控、管理和分析生产环境中的应用程序的工具。

• 2008年，BEA被Oracle收购。

• Oracle表达了整合两大优秀虚拟机的工作，大致在JDK 8中完成。整合的方式是在HotSpot的基础上，移植JRockit的优秀特性。

• 高斯林：目前就职于谷歌，研究人工智能和水下机器人

J9

• 全称：IBM Technology for Java Virtual Machine，简称IT4J，内部代号：J9

• 市场定位与HotSpot接近，服务器端、桌面应用、嵌入式等多用途VM

• 广泛用于IBM的各种Java产品。

• 目前，有影响力的三大商用虚拟机之一，也号称是世界上最快的Java虚拟机。

• 2017年左右，IBM发布了开源J9 VM，命名为OpenJ9，交给Eclipse基金会管理，也称为Eclipse OpenJ9

KVM和CDC/CLDC HotSpot

• Oracle在Java ME产品线上的两款虚拟机为：CDC/CLDC HotSpot Implementation VM

• KVM（Kilobyte）是CLDC-HI早期产品

• 目前移动领域地位尴尬，智能手机被Android和ioS二分天下。

• KVM简单、轻量、高度可移植，面向更低端的设备上还维持自己的一片市场
• 智能控制器、传感器
• 老人手机、经济欠发达地区的功能手机

• 所有的虚拟机的原则：一次编译，到处运行。

Azul VM

• 前面三大“高性能Java虚拟机”使用在通用硬件平台上

• 这里Azul VM和BEA Liquid VM是与特定硬件平台绑定、软硬件配合的专有虚拟机
• 高性能Java虚拟机中的战斗机。

• Azul VM是Azul Systems公司在HotSpot基础上进行大量改进，运行于Azul Systems公司的专有硬件Vega系统上的Java虚拟机。

• 每个Azul VM实例都可以管理至少数十个CPU和数百GB内存的硬件资源，并提供在巨大内存范围内实现可控的GC时间的垃圾收集器、专有硬件优化的线程调度等优秀特性。

• 2010年，Azul Systems公司开始从硬件转向软件，发布了自己的ZingJVM，可以在通用x86平台上提供接近于Vega系统的特性。

Liquid VM

• 高性能Java虚拟机中的战斗机。

• BEA公司开发的，直接运行在自家Hypervisor系统上

• Liquid VM即是现在的JRockit VE(Virtual Edition) ，LiquidVM不需要操作系统的支持，或者说它自己本身实现了一个专用操作系统的必要功能，如线程调度、文件系统、网络支持等。

• 随着JRockit虚拟机终止开发，Liquid VM项目也停止了。

Apache Harmony

• Apache也曾经推出过与JDK 1.5和JDK 1.6兼容的Java运行平台Apache Harmony。

• 它是IBM和Intel联合开发的开源JVM，受到同样开源的openJDK的压制，sun坚决不让Harmony获得JCP认证，最终于2011年退役，IBM转而参与OpenJDK

• 虽然目前并没有Apache Harmony被大规模商用的案例，但是它的Java类库代码吸纳进了Android SDK。

Microsoft JVM

• 微软为了在IE3浏览器中支持Java Applets，开发了Microsoft JVM。

• 只能在Windows平台下运行。但确是当时Windows下性能最好的Java VM

• 1997年，Sun以侵犯商标、不正当竞争罪名指控微软成功，赔了Sun很多钱。微软在windowsXP SP3中抹掉了其VM。现在Windows上安装了jdk都是HotSpot。

Taobao JVM

• 由AliJVM团队发布。阿里，国内使用Java最强大的公司，覆盖云计算、金融、物流、电商等众多领域，需要解决高并发、高可用、分布式的复合问题。有大量的开源产品。

• 基于OpenJDK开发了自己的定制版本AlibabaJDK，简称AJDK。是整个阿里Java体系的基石。

• 基于OpenJDK Hotspot VM发布的国内第一个优化、深度定制且开源的高性能服务器版Java虚拟机。
• 创新的GCIH (GC invisible heap ）技术实现了off-heap ，即将生命周期较长的Java对象从heap中移到heap之外，并且Gc不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。
• GCIH 中的对象还能够在多个Java虚拟机进程中实现共享
• 使用crc32指令实现JVM intrinsic降低JNI的调用开销
• PMU hardware 的Java profiling tool 和诊断协助功能
• 针对大数据场景的ZenGc

• taobao vm应用在阿里产品上性能高，硬件严重依赖intel的cpu，损失了兼容性,但提高了性能
• 目前已经在淘宝、天猫上线，把Oracle 官方JVM版本全部替换了。

Dalvik VM

• 谷歌开发的，应用于Android系统，并在Android2.2中提供了JIT，发展迅猛。

• Dalvik VM只能称作虚拟机，而不能称作“Java虚拟机”，它没有遵循Java虚拟机规范

• 不能直接执行Java 的 class 文件

• 基于寄存器架构，不是jvm的栈架构。

• 执行的是编译以后的dex (Dalvik Executable）文件。执行效率比较高。
• 它执行的dex (Dalvik Executable）文件可以通过class文件转化而来，使用Java语法编写应用程序，可以直接使用大部分的Java API等。

• Android 5.0使用支持提前编译(Ahead of Time Compilation，AOT)的ART VM替换Dalvik VM。

Graal VM

• 2018年4月，oracle Labs公开了Graal VM，号称“Run Programs Faster Anywhere”，勃勃野心。与1995年java的”write once，run anywhere"遥相呼应。

• Graal VM在HotSpot VM基础上增强而成的跨语言全栈虚拟机，可以作为“任何语言”的运行平台使用。语言包括: Java、scala、Groovy、Kotlin; C、C++、JavaScript、Ruby、Python、R等

• 支持不同语言中混用对方的接口和对象，支持这些语言使用已经编写媒的本地库文件

• 工作原理是将这些语言的源代码或源代码编译后的中间格式，通过解释器转换为能被Graal VM接受的中间表示。Graal VM提供Truffle工具集快速构建面向一种新语言的解释器。在运行时还能进行即时编译优化，获得比原生编译器更优秀的执行效率。

• 如果说Hotspot有一天真的被取代，Graal VM希望最大。但是Java的软件生态没有丝毫变化。

类加载子系统

JVM架构

类加载器与类的加载过程

类加载器子系统的作用

• 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。

• ClassLoader只负责class文件的加载，全丁它是省可以运仃，则田Execution Engine决定。

• 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射)

类的加载过程

加载

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

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

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

加载.class文件的方式

• 从本地系统中直接加载

• 通过网络获取，典型场景：Web Applet

• 从zip压缩包中读取，成为日后jar，war格式的基础

• 运行时计算生成，使用最多的饿是：动态代理技术

• 由其他文件生成，典型场景：JSP应用

• 从专有数据库中提取.class文件，比较少见

• 从加密文件中获取，典型的防Class文件被反编译的保护措施

链接

验证（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>()已经执行完毕

• 虚拟机必须保证一个类的
()方法在多线程下被同步加锁

类加载器的分类

• JVM支持两种类型的类加载器，分别为引导类加载器（Boostrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）

• 从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器

• 无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示：

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

• 这个类加载使用C/C++语言实现的，嵌套在JVM内部

• 它用来加载Java的核心库(JAVA_HOME/jre/lib/re.jar、resources.jar或sun.boot.class.path路径下的内容)，用于提供JVM自身需要的类

• 并不继承于java.lang.ClassLoader，没有父类加载器

• 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

扩展类加载器（Extension 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种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式

• 为什么要自定义类加载器？
• 隔离加载类
• 修改类加载的方式
• 扩展加载源
• 防止源码泄漏

用户自定义类加载器实现步骤：

1. 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求

2. 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass()方法，从而实现自定义的类加载器，但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑卸载findClass()方法中

3. 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁

关于ClassLoader

获取ClassLoader的途径

双亲委派机制

工作原理

1. 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行

2. 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器

3. 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派机制

优势

• 避免类的重复加载

• 保护程序安全，防止核心API被随意篡改
• 自定义类：java.lang.String
• 自定义类：java.lang,ShkStart
报错：java.lang.SecurityException: Prohibited package name: java.lang

沙箱安全机制

其他

• 在JVM中表示两个class对象是否为同一个类存在两个必要条件：
• 类的完整类名必须一致，包括包名
• 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同

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

运行时数据区概述及线程

概述

线程

• 线程是一个程序里的运行单元。JVM允许一个应用有多个线程并行的执行

• 在HotSpot JVM里，每个线程都与操作系统的本地线程直接映射。
• 当一个Java线程准备好执行以后，此时一个操作系统的本地线程也同时创建。Java线程执行终止后，本地线程也会回收

• 操作系统负责所有线程的安排调度到任何一个可用的CPU上。一旦本地线程初始化成功，它就会调用Java线程中的run()方法

JVM系统线程

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

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

程序计数器(PC寄存器)

PC寄存器介绍

• 它是一块很小的内存空间，几乎可以忽略不计。也是运行速度最快的存储区域

• 在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期保持一致

• 在任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址；或者，如果是在执行native方法，则是未指定值(underfined)

• 它是程序控制流的指示器，分支、循环、跳转、异常处理、县城回复等基础功能都需要依赖这个计数器来完成

• 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令

• 它是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域

两个常见问题

使用PC寄存器存储字节码指令地址有什么用呢？

PC寄存器为什么被设定为线程私有

虚拟机栈

虚拟机栈概述

虚拟机栈出现的背景

内存中的栈和堆

虚拟机栈基本内容

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

• 生命周期
生命周期和线程一致

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

栈的特点

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

• JVM直接堆Java栈的操作只有两个：
• 每个方法执行，伴随着进栈(入栈、压栈)
• 执行结束后的出栈工作

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

栈中可能出现的异常

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

栈的存储单位

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

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

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

栈运行原理

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

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

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

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

• 不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧之中引用另外一个线程的栈帧

• 如果当前方法调用了其他方法，方发返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧使得前一个栈帧重新称为当前栈帧

• Java方法有两种返回函数的方式，一种是正常的函数返回，使用return指令；另外一种是抛出异常。不管使用哪种方式，都会导致栈帧被弹出

栈帧的内部结构

• 局部变量表(Local Variables)

• 操作数栈(Operand Stack)(或表达式栈)

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

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

• 一些附加信息

局部变量表(Local Variables)

• 局部变量表也被称为局部变量数组或本地变量表

• 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型、对象引用(reference)，以及returnAddress类型

• 由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题

• 局部变量表所需的容量大小是在编译器确定下来的，并保存在方法的Code属性的maximun local variables数据项中。在方法运行期间是不会改变局部变量表的大小的

• 方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多

• 局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁

补充说明

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

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

操作数栈(Operand Stack)

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

• 操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈(push)/出栈(pop)
• 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈
• 比如：执行复制、交换、求和等操作

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

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

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

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

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

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

• 栈中的任何一个元素都是可以任意的Java数据类型
• 32bit的类型占用一个栈单位深度
• 64bit的类型占用两个栈单位深度

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

栈顶缓存(Top-of-Stack Cashing)技术

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

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

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

方法的调用：解析与分派

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

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

方法的调用：虚方法和非虚方法

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

• 静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法

• 其他方法称为虚方法

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

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

方法的调用：方法重写的本质

1. 找到操作数栈顶的第一个元素所执行的对象的实际类型，记作C

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

3. 否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程

4. 如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常

方法的调用：虚方法表

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

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

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