五、java虚拟机夯实基础--虚拟机字节码执⾏引擎

虚拟机”是⼀个相对于“物理机”的概念，这两种机器都有代码执⾏能⼒，其区别是物理机的执⾏引擎是直接建⽴在处理器、缓存、指令集和操作系统层⾯上的，⽽虚拟机的执⾏引

擎则是由软件⾃⾏实现的，因此可以不受物理条件制约地定制指令集与执⾏引擎的结构体

系，能够执⾏那些不被硬件直接⽀持的指令集格式。

1运⾏时栈帧结构

Java虚拟机以⽅法作为最基本的执⾏单元，“栈帧”(Stack Frame)则是⽤于⽀持虚拟机进⾏⽅法调⽤和⽅法执⾏背后的数据结构，它也是虚拟机运⾏时数据区中的虚拟机栈

(Virtual Machine Stack)的栈元素。栈帧存储了⽅法的局部变量表、操作数栈、动态连接

和⽅法返回地址等信息。每⼀个⽅法从调⽤开始⾄执⾏结束的过程，都对应着⼀个栈帧在

虚拟机栈⾥⾯从⼊栈到出栈的过程。

⼀个栈帧需要分配多少内存，并不会受到程序运⾏期变量数据的影响，⽽仅仅取决于程序源码和具体的虚拟机实现的栈内存布局形式(编译时已决定，并写⼊到⽅法表的Code属性中)

⼀个线程中的⽅法调⽤链可能会很⻓，以Java程序的⻆度来看，同⼀时刻、同⼀条线程⾥⾯，在调⽤堆栈的所有⽅法都同时处于执⾏状态。⽽对于执⾏引擎来讲，在活动线程

中，只有位于栈顶的⽅法才是在运⾏的，只有位于栈顶的栈帧才是⽣效的，其被称为“当

前栈帧”(Current Stack Frame)，与这个栈帧所关联的⽅法被称为“当前⽅法”(Current Method)。 典型的栈帧结构如下⻚图所示

1.1局部变量表:

局部变量表(Local Variables Table)是⼀组变量值的存储空间，⽤于存放⽅法参数和⽅法内部定义的局部变量。在Java程序被编译为Class⽂件时，就在⽅法的Code属性的max_locals数据项中确定了该⽅法所需分配的局部变量表的最⼤容量。局部变量表的容量以变量槽(Variable Slot)为最⼩单位。

⼀个变量槽可以存放⼀个32位以内的数据类型，Java中占⽤不超过32位存储空间的数据

类型有boolean、byte、char、short、int、float、reference和returnAddress这8种类型。 第7种reference类型表示对⼀个对象实例的引⽤，《Java虚拟机规范》既没有说明它的⻓度，也没有明确指出这种引⽤应有怎样的结构。但是⼀般来说，虚拟机实现⾄少都应当能通过这个引⽤做到两件事情，⼀是从根据引⽤直接或间接地查找到对象在Java堆中的数据存放的起始地址或索引，⼆是根据引⽤直接或间接地查找到对象所属数据类型在⽅法区中的存储的类型信息，否则将⽆法实现《Java语⾔规范》中定义的语法约定。

对于64位的数据类型，Java虚拟机会以⾼位对⻬的⽅式为其分配两个连续的变量槽空间。

如果⼀个局部变量定义了但没有赋初始值，那它是完全不能使⽤的。

1.2操作数栈:

操作数栈(Operand Stack)也常被称为操作栈，它是⼀个后⼊先出(Last In First Out，

LIFO)栈 。

在概念模型中，两个不同栈帧作为不同⽅法的虚拟机栈的元素，是完全相互独⽴的。但是在⼤多虚拟机的实现⾥都会进⾏⼀些优化处理，令两个栈帧出现⼀部分重叠。让下⾯栈帧

的部分操作数栈与上⾯栈帧的部分局部变量表重叠在⼀起，这样做不仅节约了⼀些空间，

更重要的是在进⾏⽅法调 ⽤时就可以直接共⽤⼀部分数据，⽆须进⾏额外的参数复制传

递了。

1.3动态连接:

每个栈帧都包含⼀个指向运⾏时常量池中该栈帧所属⽅法的引⽤，持有这个引⽤是为了⽀

持⽅法调⽤过程中的动态连接(Dynamic Linking)。通过第6章的讲解，我们知道Class⽂件的常量池中存有⼤量的符号引⽤，字节码中的⽅法调⽤指令就以常量池⾥指向⽅法的符

号引⽤作为参数。这些符号引⽤⼀部分会在类加载阶段或者第⼀次使⽤的时候就被转化为

直接引⽤，这种转化被称为静态解析。 另外⼀部分将在每⼀次运⾏期间都转化为直接引

⽤，这部分就称为动态连接。

1.4 ⽅法返回地址

当⼀个⽅法开始执⾏后，只有两种⽅式退出这个⽅法。

第⼀种⽅式是执⾏引擎遇到任意⼀个⽅法返回的字节码指令，这种退出⽅法的⽅式称为“正常调⽤完成”(Normal Method Invocation Completion)。

第二种退出⽅式是在⽅法执⾏的过程中遇到了异常，并且这个异常没有在⽅法体内得到妥善处理。⽆论是Java虚拟机内部产⽣的异常，还是代码中使⽤athrow字节码指令产⽣的异常，只要在本⽅法的异常表中没有搜索到匹配的异常处理器，就会导致⽅法退出，这种退出⽅法的⽅式称为“异常调⽤完成(Abrupt Method Invocation Completion)”。⼀个⽅法使⽤异常完成出⼝的⽅式退出，是不会给它的上层调⽤者提供任何返回值的。

⽆论采⽤何种退出⽅式，在⽅法退出之后，都必须返回到最初⽅法被调⽤时的位置，程序能继续执⾏，⽅法返回时可能需要在栈帧中保存⼀些信息，⽤来帮助恢复它的上层主调

⽅法的执⾏状态。⼀般来说，⽅法正常退出时，主调⽅法的PC计数器的值就可以作为返

回地址，栈帧中很可能会保存这个计数器值。⽽⽅法异常退出时，返回地址是要通过异常处理器表来确定的，栈帧中就⼀般不会保存这部分信息。

⽅法调⽤

⽅法调⽤阶段唯⼀的任务就是确定被调⽤⽅法的版本 (即调⽤哪⼀个⽅法) ，⼀切⽅法调⽤在Class⽂件⾥⾯存储的都只是符号引⽤，⽽不是⽅法在实际运⾏时内存布局中的⼊⼝地址(也就是之前说的直接引⽤)。

解析:

所有⽅法调⽤的⽬标⽅法在Class⽂件⾥⾯都是⼀个常量池中的符号引⽤。⽅法在程序真正运⾏之前就有⼀个可确定的调⽤版本，并且这个⽅法的调⽤版本在运⾏期是不可改变

的。换句话说，调⽤⽬标在程序代码写好、编译器进⾏编译那⼀刻就已经确定下来。这类

⽅法的调⽤被称为解析(Resolution)。

在Java语⾔中符合“编译期可知，运⾏期不可变”这个要求的⽅法，主要有静态⽅法和私有⽅法两⼤类，前者与类型直接关联，后者在外部不可被访问，这两种⽅法各⾃的特点决定了它们都不可能通过继承或别的⽅式重写出其他版本，因此它们都适合在类加载阶段进⾏解析。

2.JAVA内存模型与线程

2.1CPU硬件缓存

现代CPU处理器为了缓解CPU处理速度与IO设备之间速度不匹配的关系，在二者之间加入了多层高速缓存，作为内存与处理器之间的缓冲，将运算数据复制进缓存中，计算后，重新从缓存写入主存中。

2.2JAVA内存模型

2.1主存与内存

2.2 内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从 工作内存同步回主内存这一类的实现细节，Java内存模型中定义了以下8种操作来完成。Java虚拟机实 现时必须保证下面提及的每一种操作都是原子的、不可再分的。lock（锁定）、unlock（解锁）、read（读取）、load（载入）、use（使用）、assign（赋值）、store（存储）、write（写入）。

基于理解难度和严谨性考虑，最新的JSR-133文档中，已经放弃了采用这8种操作去定义Java内存模 型的访问协议，缩减为4种（仅是描述方式改变了，Java内存模型并没有改变）

2.3 对于volatile型变量的特殊规则

当一个变量被定义成volatile之后，它将具备两项特性：（1）保证此变量对所有线程的可见性，（2）禁止指令重排性。

1. 所有线程可见性

虽然被volatile定义的变量满足所有线程立刻可见性，但是在不符合以下两条规则的运算场景中，我们仍然要通过加锁 （使用synchronized、java.util.concurrent中的锁或原子类）来保证原子性：

1. 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。

2. 变量不需要与其他的状态变量共同参与不变约束。

Java里面的运算操作符并非原子操作， 这导致volatile变量的运算在并发下一样是不安全的.

问题就出在自增运算“race++”之中,volatile关键字保证了race的值在此时是正确的，但是在执行iconst_1、iadd这 些指令的时候，其他线程可能已经把race的值改变了，而操作栈顶的值就变成了过期的数据，所以 putstatic指令执行后就可能把较小的race值同步回主内存之中。

(2)禁止指令重排序优化

普通的变量仅会保证在该方法的执行过程 中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的 执行顺序一致。因为在同一个线程的方法执行过程中无法感知到这点，这就是Java内存模型中描述的 所谓“线程内表现为串行的语义”（Within-Thread As-If-Serial Semantics）。

volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢上一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此，大多数场景下volatile的总开销仍然要比锁来得更低。我们在volatile与锁中选择的唯一判断依 据仅仅是volatile的语义能否满足使用场景的需求。

2.4 原子性、可见性与有序性

2.5 Happens-Before原则

“先行发生”（Happens-Before）的原则。这个原则非常重要，它是判断数据是否存在竞争，线程是 否安全的非常有用的手段。依赖这个原则，我们可以通过几条简单规则一揽子解决并发环境下两个操 作之间是否可能存在冲突的所有问题。

先行发生是Java内存模型中定义的两项操作之间的偏序关系，比如说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B 观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。如：

假设线程A中的操作“i=1”先行发生于线程B的操作“j=i”，那我们就可以确定在线程B的操作执行后，变量j的值一定是等于1，得出这个结论的依据有两个：一是根据先行发生原则，“i=1”的结果可以被观察到；二是线程C还没登场，线程A操作结束之后没有其他线程会修改变量i的值。现在再来考虑 线程C，我们依然保持线程A和B之间的先行发生关系，而C出现在线程A和B的操作之间，但是C与B没 有先行发生关系，那j的值会是多少呢？答案是不确定！1和2都有可能，因为线程C对变量i的影响可能 会被线程B观察到，也可能不会，这时候线程B就存在读取到过期数据的风险，不具备多线程安全性。

下面是Java内存模型下一些“天然的”先行发生关系，这些先行发生关系无须任何同步器协助就已 经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出 来，则它们就没有顺序性保障，虚拟机可以对它们随意地进行重排序。

程序次序规则（Program Order Rule）：在一个线程内，按照控制流顺序，书写在前面的操作先行发生于书写在后面的操作。注意，这里说的是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。

管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是“同一个锁”，而“后面”是指时间上的先后。

volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后。

线程启动规则（Thread Start Rule）：Thread对象的start()方法先行发生于此线程的每一个动作。

线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread::join()方法是否结束、Thread::isAlive()的返回值等手段检测线程是否已经终止执行。

线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程 的代码检测到中断事件的发生，可以通过Thread::interrupted()方法检测到是否有中断发生。

对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize()方法的开始。

传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

Java语言无须任何同步手段保障就能成立的先行发生规则有且只有上面这些。

我们依次分析一下先行发生原则中的各项规则。由于两个方法分别由线程A和B调用，不在一个线程中，所以程序次序规则在这里不适用；由于没有同步块，自然就不会发生lock和unlock操作，所以管程锁定规则不适用；由于value变量没有被volatile关键字修饰，所以volatile变量规则不适用；后面的线程启动、终止、中断规则和对象终结规则也和这里完全没有关系。因为没有一个适用的先行发生规则，所以最后一条传递性也无从谈起，因此我们可以判定，尽管线程A在操作时间上先于线程B，但是 无法确定线程B中getValue()方法的返回结果，换句话说，这里面的操作不是线程安全的。

3线程的实现（非常重要）

线程是Java里面进行处理器资源调度的最基本单位。

实现线程主要有三种方式：使用内核线程实现（1：1实现），使用用户线程实现（1：N实现）， 使用用户线程加轻量级进程混合实现（N：M实现）。

1. 内核线程实现

使用内核线程实现的方式也被称为1：1实现。内核线程（Kernel-Level Thread，KLT）就是直接由操作系统内核（Kernel，下称内核）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就称为多线程内核 （Multi-Threads Kernel）。

程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口——轻量级进程（Light Weight Process，LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1：1 的关系称为一对一的线程模型，如图12-3所示。

由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使其中某一个轻量级进程在系统调用中被阻塞了，也不会影响整个进程继续工作。轻量级进程也具有它的局限性：首先，由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态（User Mode）和内核态（Kernel Mode）中来回切换。其次，每个 轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈 空间），因此一个系统支持轻量级进程的数量是有限的。

为什么内核线程调度切换起来成本高？

内核线程的调度成本主要来自于用户态与核心态之间的状态转换，而这两种状态转换的开销主要来自于响应中断、保护和恢复执行现场的成本。

假设发生了这样一次线程切换：

处理器要去执行线程A的程序代码时，并不是仅有代码程序就能跑得起来，程序是数据与代码的组合体，代码执行时还必须要有上下文数据的支撑。而这里说的“上下文”，以程序员的角度来看，是方法调用过程中的各种局部的变量与资源；以线程的角度来看，是方法的调用栈中存储的各类信息； 而以操作系统和硬件的角度来看，则是存储在内存、缓存和寄存器中的一个个具体数值。物理硬件的 各种存储设备和寄存器是被操作系统内所有线程共享的资源，当中断发生，从线程A切换到线程B去执行之前，操作系统首先要把线程A的上下文数据妥善保管好，然后把寄存器、内存分页等恢复到线程B挂起时候的状态，这样线程B被重新激活后才能仿佛从来没有被挂起过。这种保护和恢复现场的工作，免不了涉及一系列数据在各种寄存器、缓存中的来回拷贝，当然不可能是一种轻量级的操作。

2.用户线程实现

使用用户线程实现的方式被称为1：N实现。广义上来讲，一个线程只要不是内核线程，都可以认为是用户线程（User Thread，UT）的一种，因此从这个定义上看，轻量级进程也属于用户线程，但轻量级进程的实现始终是建立在内核之上的，许多操作都要进行系统调用，因此效率会受到限制，并不具备通常意义上的用户线程的优点。

狭义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到用户线程的存在及如何实现的。如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，也能够支持规模更大的线程数量，这种进程与用户线程之间1：N的关系称为一对多的线程模型，如图12-4所示。

3.混合实现

将内核线程与用户线程一起使用的实现方式，被称为N：M实现。在这种混合实现下，既存在用户线程，也存在轻量级进程。 用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统支持的轻量级进程则作为用户线程和内核线程之间的桥梁， 这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级进程来完成，这大大降低了整个进程被完全阻塞的风险。在这种混合模式中，用户线程与轻量级进程的数量 比是不定的，是N：M的关系，如图12-5所示，这种就是多对多的线程模型。

4.Java线程的实现

以HotSpot为例，它的每一个Java线程都是直接映射到一个操作系统原生线程来实现的，而且中间没有额外的间接结构，所以HotSpot自己是不会去干涉线程调度的（可以设置线程优先级给操作系统提供调度建议），全权交给底下的操作系统去处理，所以何时冻结或唤醒线程、该给线程分配多少处理器执行时间、该把线程安排给哪个处理器核心去执行等，都是由操作系统完成的，也都是由操作系统全权决定的。

5.Java线程调度

线程调度是指系统为线程分配处理器使用权的过程，调度主要方式有两种，分别是协同式 （Cooperative Threads-Scheduling）线程调度和抢占式（Preemptive Threads-Scheduling）线程调度。

协同式调度：

协同式调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上去。协同式多线程的最大好处是实现简单，而且由于线程要把自己的事情干完后才会进行线程切换，切换操作对线程自己是可知的，所以一般没有什么线程同步的问题。

抢占式调度：

抢占式调度的多线程系统，那么每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定。譬如在Java中，有Thread::yield()方法可以主动让出执行时间，但是如果想要主动获取执行时间，线程本身是没有什么办法的。在这种实现线程调度的方式下，线程的执行时间是系统可控的，也不会有一个线程导致整个进程甚至整个系统阻塞的问题。Java使用的线程调度方式就是抢占式 调度。

6.状态转换