第1题（第八章·8.1 概述）
请说明虚拟机字节码执行引擎的概念模型 ：它的输入、处理过程、输出 分别是什么？并解释解释执行与**即时编译（JIT）**如何在同一"统一外观（Facade）"下协同存在。
- 概念模型：执行引擎对外呈统一外观 ；输入 为字节码二进制流，处理过程 为字节码解析执行的等效过程，输出为执行结果。
- 解释与JIT的关系：不同JVM可仅解释 或仅JIT ，也可二者并存协作（甚至多级JIT），对外仍保持一致的输入/输出外观。
第2题（第八章·8.2 运行时栈帧结构）
请列出一个运行时栈帧 包含的四个核心组成部分 （逐条给出其作用：一句话/项），并说明这些结构的规模在编译期 如何被确定（提示：与 Code 属性中的度量有关）。
- 栈帧四要素及作用：局部变量表 用于承载形参与方法体内局部变量；操作数栈 是LIFO运算栈，承载指令的操作数与中间结果并用于方法参数传递；动态连接 持有到运行时常量池 的引用以在调用过程中将符号引用转为直接引用；方法返回地址用于方法正常或异常退出后恢复上层调用点继续执行。
- 规模确定：在编译期 已分析出所需的**局部变量表大小（
max_locals）与 操作数栈深度（max_stack）**并写入Code属性，栈帧内存分配仅取决于源码与虚拟机栈布局。
第3题（第八章·8.2.1 局部变量表）
请解释变量槽（Slot）的含义与可存放的数据类型集合 ；说明 long/double 在槽位占用上的特殊性；再说明 max_locals 是如何由同时存活的最大局部变量数量与类型 计算得到，以及作用域结束后槽位重用的编译期策略。
1）什么是 Slot？支持哪些数据类型？是否规定了字节大小？
- 局部变量表的容量以变量槽（Variable Slot）为最小计量单位。规范没有固定一个 Slot 必须占用多少字节；只要求"每个 Slot 能存放以下任一类型的数据"。这样做给不同位宽/实现留出了余地（例如 64 位 VM 可用对齐/补白保持外观一致）。
- Slot 可直接存放的8类 数据：
boolean、byte、char、short、int、float、reference、returnAddress（前 6 类为 ≤32 位数值；reference是对象引用；returnAddress较少见，服务于已被异常表取代的早期跳转指令jsr/jsr_w/ret）。
2）64 位类型如何占槽？有什么校验限制？
long/double属于 64 位类型，以高位对齐方式占用两个连续 Slot ；索引 N 指向第一个槽，同时会占用 N 与 N+1 两个槽。- 不允许半槽访问 ：对这两个相邻槽中任意一个进行"单独"访问的字节码在类加载校验阶段就会被判错并抛出异常。
3）如何通过索引访问局部变量表？this 在哪？
- 局部变量表通过从 0 开始的整数索引 访问；32 位数据用单一索引访问一个槽，64 位数据使用一对相邻槽（N 与 N+1）。
- 实例方法 调用时，索引 0 的槽用于隐式参数
this；其后依形参列表顺序依次占用槽位，然后才是方法体内局部变量。
4）max_locals 如何确定？有无"按需复用"策略？
- 不能简单把方法里出现过的变量数累加为
max_locals。编译器会按变量作用域 对槽位进行复用 ：当某个局部变量的作用域结束 后，其占用的槽位可被后续变量复用。最终max_locals由同一时刻同时存活的最大变量数量与类型 共同决定（注意long/double要占 2 槽）。 - 异常处理参数 （
catch块的异常对象）等方法入参/局部变量也在局部变量表中。
5）槽位复用对 GC 的实际影响（易踩坑点）
- 为节省栈帧空间，槽位可重用 ；但这会带来轻微副作用 ：若一个引用变量离开作用域但其槽位尚未被新变量覆盖 ，JVM 可能仍认为该引用"可达"，从而影响 GC 回收时机 （书中通过
placeholder示例和System.gc()输出对比演示了这一点）。
实战建议（编译期/代码层面的可操作做法）
- 缩小变量作用域 ：将临时对象的声明放入更小的代码块中，尽快让其超出作用域 ，使编译器更容易复用槽位并让引用早日失效（有助 GC）。
- 覆盖旧引用 ：在大对象仅作一次性缓冲时，复用变量或显式赋
null（语义允许时）以覆盖旧槽位内容，避免"悬挂引用"影响回收。原理即"槽位未被覆盖时仍可能被视为可达"。 - 评估
long/double带来的槽位压力 ：热路径上大量 64 位临时量会增大max_locals，从而加大栈帧占用；可通过拆分表达式/延后求值降低同一时刻"同时存活"的 64 位变量数。 - 理解
this的槽位占用 ：实例方法的this固占索引 0；对高参数个数的方法，合理参数顺序可减少临时量、压低max_locals。
小结（一屏记忆）
- Slot ：最小计量单位，大小未固定；能放 8 类 ≤32 位数据或对象引用/返回地址。
- 64 位 ：
long/double占 2 槽（高位对齐），禁止半槽访问。 - 索引与
this：从 0 开始；实例方法的this在索引 0。 max_locals：由同时存活的最大变量集合 决定；作用域结束后可复用槽。
第四题（第八章·8.2.2 操作数栈）
请说明操作数栈（Operand Stack）的LIFO 特性 、与方法 Code 属性中 max_stack 的关系，以及 32 位/64 位数据 在栈深度上的占用差异；并用字节码序列 iconst_1, iconst_1, iadd, istore_0 描述一次整型加法在操作数栈 ↔ 局部变量表之间的流转。
-
角色/特性 ：操作数栈是LIFO 结构，只允许在栈顶 读写元素；方法执行期间，各条字节码通过对栈顶入栈/出栈来完成运算与参数传递。
-
max_stack关系 ：最大栈深度在编译期 计算，并写入Code的max_stack字段；编译器的数据流分析与类校验阶段会确保运行时不会超过该上限。 -
容量占用 ：操作数栈元素可为任意 Java 基本类型（含
long/double）或引用；32 位数据占 1 、64 位数据占 2 个栈容量单元。 -
示例流转 （
iconst_1, iconst_1, iadd, istore_0）：iconst_1：压入常量 1 → 栈：[1]；iconst_1：再压入 1 → 栈：[1, 1]；iadd：弹出 两个int相加，压回结果 → 栈：[2]；istore_0：弹出 结果写入局部变量表槽 0。
第4题（第八章·8.2.2 栈帧重叠共享优化）
请解释栈帧重叠共享（caller/callee 重叠）在多数 JVM 实现中的做法：它让调用者的操作数栈 与被调用者的局部变量表 出现部分重叠 的目的与收益是什么？这种优化为何既能节省空间 又能减少实参与形参的复制成本？
- 在概念模型中，不同方法的两个栈帧互不相干 ；但多数 JVM 会让调用者的操作数栈 与被调用者的局部变量表 发生部分重叠 ，既节约空间 ，又减少实参与形参的复制成本。
第5题（第八章·8.2.3 动态连接）
请解释动态连接（Dynamic Linking）与 静态解析（Resolution）的区别：运行时栈帧为何需要持有所属方法的运行时常量池引用 ；哪些方法调用 会在类加载/首次使用 时就解析为直接引用（请列举方法类别并给出理由）。
- 动态连接 vs 静态解析 ：字节码中的方法调用以"指向方法的符号引用 "作为参数；其中一部分 在类加载阶段或首次使用 就转为直接引用 （静态解析），另一部分 则在每次运行期间再转为直接引用（动态连接）。
- 为何要持有常量池引用 ：因为解析/连接都依赖运行时常量池 中的符号引用，故每个栈帧 必须持有其所属方法的运行时常量池引用以支撑调用过程的动态连接。
- 可在解析期就确定唯一目标的方法（非虚方法） ：凡能被
invokestatic、invokespecial调用者，均可在解析阶段确定唯一版本，包含静态方法、私有方法、实例构造器<init>、父类方法 ，再加上**final实例方法**（虽用invokevirtual调用但不可被覆盖），统称非虚方法 ；其符号引用在加载时即可解析为直接引用。
第6题（第八章·8.3 方法调用指令）
请列举并解释 五条方法调用字节码指令：invokestatic、invokespecial、invokevirtual、invokeinterface、invokedynamic 的用途与分派特点 （一句话/条）；同时说明为什么把前四条称为"分派逻辑固化在 JVM 内部 "，而 invokedynamic 的分派逻辑由**引导方法（Bootstrap Method）**决定。
1）invokestatic
- 用途 ：调用静态方法（与类直接关联，不依赖接收者对象）。
- 分派特点 ：目标在解析期即可唯一确定 ，在类加载的解析阶段把符号引用 转成直接引用 ，属于非虚方法调用。
2）invokespecial
- 用途 ：调用实例构造器
<init>、私有方法 、以及父类方法。 - 分派特点 ：与
invokestatic一样，其目标解析期唯一确定 ，属于非虚方法调用。
3）invokevirtual
- 用途 ：调用所有虚方法（可被覆盖的实例方法）。
- 分派特点 ：按接收者的实际类型 在运行期 做动态分派 。例外 ：被
final修饰的实例方法虽用invokevirtual调用，但不可覆盖 、其目标也在加载期即可唯一确定，规范上仍属非虚方法。
4）invokeinterface
- 用途 ：调用接口方法。
- 分派特点 ：在运行期 根据实际的实现类查找并分派到对应实现。
5）invokedynamic
- 用途 ：把"如何寻找目标方法 "的决定权从虚拟机挪到用户侧 （含语言实现者），在运行期动态解析调用点并绑定目标。
- 常量池与引导 ：其操作数不再是
CONSTANT_Methodref_info，而是CONSTANT_InvokeDynamic_info，其中携带引导方法（Bootstrap Method） 、方法类型（MethodType）与名称 ；JVM据此定位并执行引导方法 ，由其返回一个java.lang.invoke.CallSite，再通过 CallSite 的目标完成最终调用。
为何说"前四条分派逻辑固化在 JVM 内部"，而 invokedynamic 由引导方法决定？
invokestatic / invokespecial / invokevirtual / invokeinterface的分派规则 已经由 JVM 规范固定 （静态解析或既定的动态查找流程）；而invokedynamic则把分派逻辑外包给引导方法 ，具体策略由用户/语言运行时决定。
补充：哪些属于"非虚方法"？
- 只要能被
invokestatic、invokespecial调用的方法（静态 、私有 、构造器 、父类方法 ）以及**final实例方法**，其调用点在解析阶段就能确定唯一版本 ，类加载时即可把符号引用解析为直接引用 ，统称非虚方法。
第7题（8.2.4 方法返回地址）
方法有哪两种退出方式 ？"方法返回地址"如何确定？退出时通常会对上层调用者做哪些恢复动作？
- 两种退出方式 ：①正常调用完成 ：遇到相应的返回指令（
ireturn/lreturn/freturn/dreturn/areturn/return），可能携带返回值；②异常调用完成 ：执行中抛出且本方法内无匹配的异常处理器（包括由athrow抛出），无返回值。 - 返回地址来源 ：正常退出时，一般以主调方法的PC计数器值 作为返回地址并保存在栈帧；异常退出时，通过异常处理器表 确定返回地址，栈帧通常不另存此信息。
- 恢复动作 （概念模型）：把当前栈帧出栈；恢复上层方法的局部变量表 与操作数栈；如有返回值，将其压入调用者的操作数栈；调整PC计数器到调用点之后。
第8题（8.2.5 附加信息）
栈帧里除"局部变量表、操作数栈、动态连接、方法返回地址"外，还可能包含哪些附加信息？在讨论概念模型时通常如何归类？
虚拟机实现允许在栈帧中存入与调试/性能收集 相关的附加信息，内容因实现而异。讨论概念模型时，常把动态连接、方法返回地址与此类附加信息 合称为"栈帧信息"。
第9题（8.3 方法调用：调用≠执行）
问： 说明"方法调用 "与"方法执行 "的区别：Class 文件里存的是什么？为何有的调用必须到类加载期/运行期才能确定目标？
方法调用阶段只负责确定被调用方法的版本 （调用哪个方法），不直接讨论其内部执行过程。Class 文件不含链接步骤 ，所有调用在Class中仅保存为符号引用 ，非直接地址。因此，有的调用需要在类加载解析期 ，甚至运行期 才能把符号引用转为直接引用。
第10题（8.3 方法调用指令与返回指令）
列举并简述 5 条方法调用指令；再说明方法返回指令如何按返回值类型区分。
- 调用指令：
invokevirtual（按接收者实际类型 做虚分派）、invokeinterface（按接口实现类 查找）、invokespecial（构造器/私有/父类 方法）、invokestatic（静态方法 ）、invokedynamic（运行时由引导方法决定分派逻辑）。 - 返回指令：按返回值类型区分为
ireturn/lreturn/freturn/dreturn/areturn，以及无返回值的return。
第11题（8.3.1 解析调用与"非虚方法"）
哪些方法在解析阶段 就能把符号引用确定为直接引用 ？它们为何被称为非虚方法 ？
所有能被 invokestatic、invokespecial 调用的方法在解析阶段 即可确定唯一版本：静态方法、私有方法、实例构造器 <init>、父类方法 ；再加上**final 实例方法**（虽用 invokevirtual 调用，但不可覆盖），统称非虚方法 ，其调用目标编译期可知、运行期不可变。
第12题（8.3.2 分派：静态/动态 × 单/多）
解释**静态分派（重载）与 动态分派（重写）**的发生点，并给出"Java 是静态多分派、动态单分派"的结论依据。
- 静态分派 在编译期 选择目标（如重载），依赖调用点的静态类型 与参数静态类型 等多个宗量 ，因此属多分派 ；编译后在常量池中固化为某条
invoke*指令及其目标符号引用。 - 动态分派 在运行期 按接收者的实际类型 选择最终实现（如重写），只有1 个宗量 （接收者实际类型）影响选择，因此属单分派 。据此可得结论："Java 语言（至 Java 12/13 预览）为静态多分派、动态单分派。"
第13题（8.3 动态分派的实现：vtable/itable）
何为虚方法表（vtable）与接口方法表（itable） ？为何要求父/子类同签名方法 在表中索引一致？
由于动态分派极其频繁 ，JVM用方法表避免每次在元数据中线性查找：
- vtable ：类的虚方法表 存放各方法的实际入口地址；若子类未重写，入口与父类一致；若重写，则替换为子类版本。
- itable ：
invokeinterface时使用的接口方法表。 - 索引一致 的理由：当接收者的实际类型变化 时，只需切换到另一张表 ，即可用相同索引定位到对应实现，提高查找性能与实现简洁性。
第14题（8.4.4/8.4.5 invokedynamic 机制）
invokedynamic 在常量池中如何表述？**引导方法（Bootstrap Method）**与 CallSite 在调用过程中的角色是什么？
- 每个
invokedynamic调用点都是动态调用点 ；其参数不再是CONSTANT_Methodref_info，而是CONSTANT_InvokeDynamic_info，其中携带三类关键信息：引导方法 （记录在BootstrapMethods属性里）、方法类型（MethodType）与名称。 - 引导方法 ：签名固定、返回
java.lang.invoke.CallSite对象；JVM按常量池信息定位并执行 引导方法，获取 CallSite ，再通过其目标完成最终调用。 - 反编译可见：Java 源码经工具/编译流程生成
invokedynamic，常量池项如"#123=InvokeDynamic#0:#121"指向第0号引导方法 与某个 NameAndType 条目，最终以 ConstantCallSite 固定目标后通过 dynamicInvoker() 调起目标方法。
第15题（8.4 java.lang.invoke 体系 & 与反射的差异）
简述 java.lang.invoke 的目标 与三大核心概念，并比较 MethodHandle vs Reflection 的定位差异；说明 Java 自 JDK 8 起在哪些特性上实用地 受益于 invokedynamic。
- 目标 ：为"仅靠符号引用确定目标方法"的传统路子之外，提供新的动态确定目标方法机制 ------方法句柄（MethodHandle） 。相关核心还包括 MethodType 与 CallSite。
- MethodHandle vs Reflection ：Reflection 旨在服务 Java 语言本身 ；MethodHandle 的设计目标是服务 JVM 上的所有语言 （含 Java），利于应用JIT级别的调用点优化 （如内联），而反射难以进行此类优化。
- JDK 8 受益点 ：Java 引入 Lambda 表达式 与接口默认方法 后，底层就会利用
invokedynamic来建立调用点并绑定目标。
第16题（8.5.2 栈 vs 寄存器 指令集）
基于栈 与寄存器 的指令集各有哪些优点/缺点 ？"栈顶缓存"优化解决了什么、又未解决什么？
- 栈架构优点 ：更可移植 （不直接依赖硬件寄存器，便于由JVM映射热点数据到物理寄存器）、代码更紧凑 （多为零地址指令）、编译器实现更简单（空间管理主要在栈上）。
- 栈架构缺点 （解释态）：为达成同样语义往往需要更多指令 （入栈/出栈本身构成额外指令），且频繁内存访问使性能受限；JIT 后映射为物理机指令时，上述差异不再关键。
- 栈顶缓存 ：把最常用操作数映射到寄存器 ，减少内存访问；但这只是优化，无法从根本上消除"栈指令多、访存频繁"的结构性问题。
第17题（8.5.2 例：同一语义的两套指令流）
以"1+1"为例，对比栈指令流 与寄存器指令流各自的写法与数据流向。
- 栈式 ：
iconst_1; iconst_1; iadd; istore_0------两个常量依次入栈，iadd出栈相加并压回 结果，istore_0写回局部变量表。 - 寄存器式 （示例为x86 二地址指令）：
mov eax,1; add eax,1------以寄存器为运算与存储中心。
第18题（8.5.3 基于栈的解释器执行过程）
书中通过一段四则运算代码与其 javap 字节码展示了解释器 如何驱动"压栈→运算→回写 "的过程。请概述该示例的目的与要点。
示例以 a=100,b=200,c=300; return (a+b)*c; 为例，通过 javap -v 展示从加载常量/局部变量 、到压栈运算 、再到结果回写 的一条完整链路，帮助读者把Java 源码语义 与零地址栈指令 逐一对照，从而理解解释器是如何依赖操作数栈推进执行的。