1.2 规范与实现：怎么读 JVMS 这张解剖图谱
1.2 规范与实现：怎么读 JVMS 这张解剖图谱
本节摘要：Java 虚拟机规范（JVMS）定义了所有实现必须遵守的硬约束：class 文件格式与指令集；而 GC 算法、JIT 策略等运行细节则是规范刻意留白的区域。本节教你按需查规范、用 javap 对照验证，并划清全书讨论"规范层"与"实现层"的用语边界。
上一节盘点了三台"型号不同"的机器，本节回答一个自然追问：凭什么说它们跑的是同一种 Java？答案是一份文档——The Java Virtual Machine Specification，业界常缩写为 JVMS。它就像医疗器械的行业标准：规定这台机器必须能处理哪些标本（class 文件格式）、必须会做哪些基本动作（指令集）、以及动作的语义（每个指令执行前后的效果）。至于用机械臂还是人手完成动作，规范不管。全书的行文都会沿用这条边界线：说到"规范要求"时，任何实现都跑不掉；说到"HotSpot 怎么做"时，换一家实现可能就不成立。
规范管什么、放开什么
把 JVM 技术栈分层来看，哪层被规范焊死、哪层留给实现自由发挥，一目了然：
图 1-2：从规范到实现的分层透视图
规范层最硬的两块是 class 文件格式与指令集。class 文件格式精确到字节：魔数、版本号、常量池、访问标志、字段表、方法表、属性表，顺序和编码都不能错——所以 class 文件能被任何合规实现加载。指令集则定义了两百多个操作码（从加载存储到方法调用、异常抛出），每个操作码的语义有严格定义。
而规范明确放开的清单同样值得背下来：它不规定垃圾回收算法（只说最终要回收不可达对象）、不规定对象在堆里怎么布局、不规定 JIT 是否存在（早期某些嵌入式 JVM 就是纯解释器）。理解这份"留白清单"，你就能解释很多现象：为什么同一份字节码在不同收集器下停顿差别巨大？因为 GC 在留白区。为什么某段代码换个 JVM 版本就快了？因为 JIT 策略也在留白区。
按需查规范：三步定位法
通读 JVMS 是不现实的，正确姿势是当词典查。以"static 字段什么时候被赋值"为例，走三步：
第一步，按主题猜章节。加载、链接、初始化的时机约束在规范"Loading, Linking, and Initializing"一章；class 文件格式独立成章；指令集单独一章。目录先扫一遍，心里就有地图了。
第二步，读约束条款，注意规范特有的措辞。"must"是硬约束，"may"是实现自由，"must not"是禁区。比如规范说静态字段在"类初始化"阶段被赋值，而初始化的触发时机由一组明确的规则约束（首次主动使用：new、读写静态字段、反射调用等）——这就是第三章 3.1 节"类加载五阶段"的规范出处。
第三步，用工具对照验证。规范说 class 常量池长什么样，那就不妨亲眼看一个：
public class SpecPeek { private static final String GREETING = "hello-spec"; public static void main(String[] args) { System.out.println(GREETING.length()); } }
编译后用 javap 反汇编，对照规范里的 class 文件结构逐项认领：
$ javap -v SpecPeek | head -n 30 Classfile /work/SpecPeek.class Last modified 2024-03-02; size 489 bytes MD5 checksum 6f3a12c9e2b8d4a1c0f9e7d5b3a1c2e4 minor version: 0 major version: 61 Constant pool: #1 = Methodref #4.#15 // java/lang/Object."<init>":()V #2 = String #3 // hello-spec #3 = Utf8 hello-spec #4 = Class #16 // SpecPeek #5 = Fieldref #4.#17 // SpecPeek.GREETING:Ljava/lang/String; ...
major version: 61 对应 Java SE 17——规范里有一张版本号对照表，每一个 JDK 版本都能查到自己的编号，加载器据此拒绝过新的 class 文件（低版本 JVM 报 UnsupportedClassVersionError 的根源）。Constant pool 的每条目类型（Methodref、String、Utf8）也都能在规范"class 文件格式"一章找到字段级定义。规范读起来枯燥，但配上 javap 这类"实物标本"，每一节都有了对照物。
规范之外：Java SE 文档与实现文档的分工
新手常把三份文档混为一谈，分工其实很清楚。JVMS 管虚拟机行为；Java 语言规范（JLS）管语言语义，比如 volatile 与 final 的内存语义写在 JLS 的线程章节，第七章讲 JMM 时引用的是它；而某个具体实现的文档（HotSpot 的参数手册、GC 调优指南）管"这台机器怎么开"——-XX 参数全在这一层，规范对它们一无所知。
这也是排查跨环境问题的一个基本判断法：同一段字节码在两家实现上行为不一致，若涉及内存可见性或异常语义，先怀疑自己误读了规范（大概率是并发语义理解有偏差）；若只是性能数字不同，那是留白区的正常现象，不值得惊讶。
💡 关键直觉：把规范当"判例法"读——它不告诉你某台机器某天为什么慢，但它规定了一切合规机器共同的底线行为。当你需要论证"这段代码在任何 JVM 上都该这么跑"时，唯一可信的论据就是规范原文的条款编号。
要点回顾
- JVMS 是品类标准：class 文件格式与指令集被焊死，保证一次编译到处运行；GC、JIT、对象布局全在留白区；
- 三份文档各有分工：JVMS 管虚拟机行为，JLS 管语言语义（含内存语义），实现文档管参数与工具；
- 按需三步查规范：扫目录定位章节、区分 must 与 may 的措辞、用 javap 拿实物对照；
- 版本号藏在 class 头部：major version 决定能否被加载，UnsupportedClassVersionError 的病根在此；
- 跨环境排错的分层判断：行为不一致查规范层理解，性能不一致归实现层差异。
至此第一章完工：你认识了机器的三种型号，也拿到了官方图谱的读法。第二章正式开刀，从堆开始逐一切开运行时数据区——解剖台上最核心的躯干部分。