正在切换页面...

多态的实现原理与编译过程

hard多态编译原理字节码JVMinvokevirtualvtable最近更新

"多态"是面向对象的三大特性之一（封装、继承、多态），也是 Java 最强大的抽象机制。我们每天都在写多态的代码，但你有没有想过：当你写下 animal.speak()，JVM 怎么知道要调用 Dog 的 speak() 而不是 Cat 的？这篇文章将从源码到字节码到 JVM 内存结构，彻底讲清楚多态的实现机制。同时，我们还会拆解 Java 编译器 javac 的工作流程——理解编译过程，就能明白为什么编译器能在你运行之前就发现代码中的错误。

多态的两种形态

在深入底层之前，先明确"多态"在 Java 中的两种表现形式。

编译时多态：方法重载（Overloading）

同一个类中方法名相同，但参数列表不同：

public class Calculator {
    int add(int a, int b) { return a + b; }
    double add(double a, double b) { return a + b; }
    int add(int a, int b, int c) { return a + b + c; }
}

Calculator calc = new Calculator();
calc.add(1, 2);       // 调用 add(int, int)
calc.add(1.0, 2.0);   // 调用 add(double, double)

编译器在编译阶段就能根据参数类型和数量确定调用哪个方法，所以叫"编译时多态"（也叫静态分派）。编译后的字节码中，方法的签名已经是确定的。

运行时多态：方法重写（Overriding）

子类重写父类的方法，通过父类引用调用时，实际执行子类的实现：

Animal animal = new Dog();  // 编译时类型是 Animal，运行时类型是 Dog
animal.speak();             // 运行时才能确定调用 Dog.speak()

JVM 在运行时才能根据对象的实际类型决定调用哪个方法，所以叫"运行时多态"（也叫动态分派）。这是多态的核心，也是本文的重点。

比喻：编译时多态就像你去餐厅点菜——菜单（方法名）一样，但你点"小份可乐"还是"大份可乐"，点单时（编译时）就确定了。运行时多态就像快递配送——你下单时写的地址是"张三家"（父类引用），但快递员到了才发现张三搬到了新地址（实际类型），需要送到新地址去。

运行时多态的底层机制

字节码层面：五种 invoke 指令

Java 编译器会根据方法调用的类型，生成不同的字节码指令：

指令	用途	分派方式	示例
`invokestatic`	静态方法	静态（编译时确定）	`Math.max(1, 2)`
`invokespecial`	构造器、private 方法、super 调用	静态（编译时确定）	`super.toString()`
`invokevirtual`	实例方法（类的方法）	动态（运行时确定）	`animal.speak()`
`invokeinterface`	接口方法	动态（运行时确定）	`list.add(x)`
`invokedynamic`	Lambda、方法引用等	动态（引导方法决定）	`() -> {}`

多态的关键在于 invokevirtual 和 invokeinterface——它们在运行时根据对象的实际类型来决定调用哪个方法实现。

让我们看一个具体例子：

Animal animal = new Dog();
animal.speak();

编译后的字节码：

new           #2    // class Dog
dup
invokespecial #3    // Dog.<init>()          ← 调用构造器，编译时确定
astore_1
aload_1
invokevirtual #4   // Animal.speak()        ← 注意：字节码里写的是 Animal

注意最后一行：invokevirtual 引用的是 Animal.speak()，而不是 Dog.speak()。这是因为编译器只知道变量 animal 的静态类型是 Animal。真正调用 Dog.speak() 的决定，要到运行时才做。

JVM 层面：虚方法表（VTable）

JVM 如何在运行时快速找到正确的方法实现？答案是虚方法表（Virtual Method Table，简称 vtable）。

vtable 的结构

当 JVM 加载一个类时，会为这个类创建一个虚方法表。vtable 本质上是一个数组，每个元素是一个指向方法实际代码的指针：

Object 的 vtable:
┌───────────┬──────────────────────┐
│  索引 0   │ → Object.toString()  │
│  索引 1   │ → Object.hashCode()  │
│  索引 2   │ → Object.equals()    │
│  索引 3   │ → Object.finalize()  │
│   ...     │ → ...                │
└───────────┴──────────────────────┘

Animal 的 vtable:
┌───────────┬──────────────────────┐
│  索引 0   │ → Object.toString()  │  ← 继承自 Object
│  索引 1   │ → Object.hashCode()  │  ← 继承自 Object
│  索引 2   │ → Object.equals()    │  ← 继承自 Object
│  索引 3   │ → Object.finalize()  │  ← 继承自 Object
│  索引 4   │ → Animal.speak()     │  ← 新增方法
│  索引 5   │ → Animal.eat()       │  ← 新增方法
└───────────┴──────────────────────┘

Dog 的 vtable:
┌───────────┬──────────────────────┐
│  索引 0   │ → Dog.toString()     │  ← 重写了 Object 的方法
│  索引 1   │ → Object.hashCode()  │  ← 继承
│  索引 2   │ → Object.equals()    │  ← 继承
│  索引 3   │ → Object.finalize()  │  ← 继承
│  索引 4   │ → Dog.speak()        │  ← 重写了 Animal 的方法
│  索引 5   │ → Animal.eat()       │  ← 继承
│  索引 6   │ → Dog.fetch()        │  ← 新增方法
└───────────┴──────────────────────┘

vtable 的关键规则

子类的 vtable 包含父类的所有方法，方法在表中的索引位置与父类保持一致
如果子类重写了某个方法，对应索引位置的指针就指向子类的新实现
如果子类没有重写，该指针仍然指向父类的实现
子类新增的方法追加在 vtable 的末尾

动态分派的执行过程

当 JVM 遇到 invokevirtual Animal.speak() 时，执行以下步骤：

1. 从操作数栈弹出对象引用（objectref）
2. 找到 objectref 指向的实际对象（这里是 Dog 实例）
3. 通过对象头中的类型指针，找到 Dog 的 Class 对象
4. 在 Dog 的 vtable 中查找 speak() 的索引（索引 4）
5. 通过索引 4 找到 → Dog.speak() 的方法指针
6. 执行 Dog.speak() 的代码

因为 vtable 用的是数组索引，所以方法查找的时间复杂度是 O(1)——这就是为什么 Java 的方法调用性能很高。

invokeinterface 与 itable

接口方法的分派与类方法有本质区别。要理解这个区别，首先要想清楚一个问题：为什么接口方法不能直接用 vtable？

为什么接口不能复用 vtable 的固定索引

vtable 之所以快（O(1)），是因为同一个方法在父类和子类的 vtable 中总是占据相同的索引位置。这是单继承保证的——Java 中一个类只能有一个父类，所以继承链是一条直线，索引不会冲突。

但接口不同。一个类可以实现多个接口，不同的类实现接口的顺序也不同：

class Dog implements Runnable, Comparable<Dog> { ... }
class Cat implements Comparable<Cat>, Serializable { ... }

假如 Runnable.run() 在 Dog 的 vtable 里是索引 7，那在 Cat 的 vtable 里呢？Cat 没有实现 Runnable，索引 7 可能是完全不相关的方法。即使两个类都实现了 Comparable，compareTo() 在各自 vtable 中的索引也可能不同——因为它们的继承链不同、方法数量不同。

比喻：vtable 就像一栋大楼的固定楼层分配——3 楼永远是财务部，5 楼永远是技术部。这在只有一栋总部大楼（单继承）时没问题。但接口就像"合作协议"——不同公司（类）可以签不同的合作协议（实现不同接口），你不能假设每家公司都把合作部门放在同一楼层。

所以 JVM 需要一种额外的数据结构来处理接口方法的分派——这就是 itable（Interface Method Table）。

itable 的数据结构

JVM 为每个实现了接口的类维护一个 itable。它是一个两级结构——乍看之下像二维数组，但实际上不是。

准确地说，itable 的内存布局是这样的：

第一级是一个一维数组，每个元素是一个二元组 (接口的Class指针, 方法表的偏移量/指针)
第二级是多个独立的方法指针数组，每个数组对应一个接口，存储该接口中每个方法的实现指针

在 HotSpot JVM 的实现中，这两级实际上是连续分配在一块内存中的——先排列所有接口的条目（第一级），紧接着依次排列每个接口的方法表（第二级）。偏移量就是从 itable 起始地址到对应方法表的字节偏移。

内存中的真实布局（连续的一块内存）：
┌──────────────────────────────────────────────┐
│ 接口条目 0: (Runnable指针,  偏移量 → ────┐)    │  ← 第一级
│ 接口条目 1: (Comparable指针, 偏移量 → ──┐│)    │     （数组）
├──────────────────────────────────────────│┼───┤
│ Runnable 方法表:  run() → Dog.run()  ←──┘│    │  ← 第二级
│ Comparable 方法表: compareTo() → ...  ←───┘    │    （方法表）
└──────────────────────────────────────────────┘

为什么不是二维数组？ 二维数组要求每一行长度相同（或者至少可以通过行列索引直接计算地址）。但不同接口的方法数量不同——Runnable 只有 1 个方法，Comparable 也是 1 个，但 List 有几十个。所以第二级的每个方法表长度各不相同，无法用统一的行列索引来访问。

更精确的类比：itable 像一本字典——第一级是目录页（"Runnable 在第 3 页，Comparable 在第 5 页"），第二级是正文（每个接口的方法列表）。你需要先翻目录找到页码（线性搜索），再翻到对应页面查方法（索引访问）。

下面用更直观的逻辑视角来展示这个结构：

Dog 的 itable:

第一级：接口偏移量表（找到接口对应的方法表）
┌─────────────────┬───────────────────┐
│  接口引用         │  方法表偏移量       │
├─────────────────┼───────────────────┤
│  Runnable       │  → offset 0       │
│  Comparable     │  → offset 1       │
└─────────────────┴───────────────────┘

第二级：每个接口的方法表（存储具体的方法指针）
┌─────────────────────────────────────┐
│  offset 0 (Runnable 的方法表)        │
│  ┌─────────┬───────────────────┐    │
│  │  run()  │ → Dog.run()       │    │
│  └─────────┴───────────────────┘    │
├─────────────────────────────────────┤
│  offset 1 (Comparable 的方法表)      │
│  ┌──────────────┬──────────────┐    │
│  │  compareTo() │ → Dog.compareTo() │
│  └──────────────┴──────────────┘    │
└─────────────────────────────────────┘

对比一下 Cat 的 itable，结构不同但原理一样：

Cat 的 itable:

第一级：
┌─────────────────┬───────────────────┐
│  Comparable     │  → offset 0       │  ← 注意：顺序与 Dog 不同
│  Serializable   │  → offset 1       │
└─────────────────┴───────────────────┘

第二级：
offset 0 → compareTo() → Cat.compareTo()
offset 1 → (Serializable 没有需要分派的方法)

可以看到，Comparable 在 Dog 的 itable 中是 offset 1，在 Cat 的 itable 中是 offset 0——同一个接口在不同类的 itable 中位置不固定，这就是 vtable 索引方案行不通的根本原因。

invokeinterface 的完整查找过程

当 JVM 遇到 invokeinterface Comparable.compareTo() 时，执行以下步骤：

1. 从操作数栈弹出对象引用（objectref）

2. 通过对象头的类型指针，找到对象的实际类（假设是 Dog）

3. 找到 Dog 的 itable

4. 在 itable 的第一级表中，线性搜索目标接口（Comparable）
   ┌─────────────┐
   │  Runnable   │ ← 不是，跳过
   │  Comparable │ ← 找到！偏移量 = 1
   └─────────────┘

5. 用偏移量 1 跳到第二级的 Comparable 方法表

6. 在方法表中找到 compareTo() 的指针 → Dog.compareTo()

7. 执行 Dog.compareTo()

注意第 4 步：线性搜索。这是 invokeinterface 比 invokevirtual 慢的根源——vtable 直接用索引（O(1)），而 itable 需要先遍历接口列表找到目标接口。

invokevirtual vs invokeinterface：性能对比

维度	`invokevirtual`（vtable）	`invokeinterface`（itable）
查找方式	固定索引，直接跳到第 N 项	先线性搜索接口，再找方法
时间复杂度	O(1)	O(K)，K = 实现的接口数
索引稳定性	方法在所有子类中索引相同	接口在不同类中偏移量不同
适用场景	类的实例方法	接口的方法

不过在实际运行中，这个性能差距几乎可以忽略，原因是 JVM 做了大量优化。

JVM 的优化：内联缓存（Inline Cache）

HotSpot JVM 不会每次都傻傻地遍历 itable。它使用一种叫内联缓存（Inline Cache，简称 IC）的技术来加速重复调用：

单态内联缓存（Monomorphic IC）：如果某个调用点（call site）在运行过程中始终调用同一个类的方法，JVM 会缓存这个结果：

// 假设这行代码在循环中执行了 10000 次
animal.speak();

前几次：走完整的 vtable/itable 查找
JVM 发现：每次 animal 都是 Dog → 缓存 (Dog → Dog.speak())
之后的调用：检查类型是不是 Dog？
  是 → 直接调用 Dog.speak()，跳过表查找
  否 → 退化为完整查找（变成多态IC）

多态内联缓存（Polymorphic IC）：如果调用点遇到了少量不同类型（通常 2-4 种），JVM 会缓存所有见过的类型：

缓存：Dog → Dog.speak()
      Cat → Cat.speak()

调用时：检查类型
  是 Dog？→ Dog.speak()
  是 Cat？→ Cat.speak()
  都不是？→ 完整查找

超多态（Megamorphic）：如果调用点遇到的类型太多（超过阈值），JVM 放弃缓存，退化为每次都走完整的 vtable/itable 查找。

在实际应用中，大多数调用点都是单态或少量多态的，所以内联缓存的命中率非常高。这就是为什么理论上 invokeinterface 更慢，但实际性能差距几乎感知不到。

哪些方法不走 vtable？

不是所有方法都需要动态分派：

方法类型	调用指令	能否被重写	是否在 vtable 中
`static` 方法	`invokestatic`	❌	❌
`private` 方法	`invokespecial`	❌	❌
`final` 方法	`invokevirtual`	❌	✅（但不会被覆盖）
构造器	`invokespecial`	❌	❌
普通实例方法	`invokevirtual`	✅	✅

static 和 private 方法在编译时就确定了目标，不需要经过 vtable 查找。final 方法虽然在 vtable 中有条目，但因为不能被重写，JVM 的 JIT 编译器可以直接将其内联，跳过 vtable 查找。

Java 编译过程全解析

理解了多态的运行时机制后，让我们把视角转向编译阶段。javac 编译器将 .java 源文件转换为 .class 字节码文件，这个过程包含多个阶段。理解编译过程，能解答一个常见的困惑：为什么我写了错误的代码，还没运行编译器就能告诉我哪里不对？

编译的整体流程

Java 源码 (.java)
      │
      ▼
┌─────────────┐
│ 1. 词法分析   │ ── 把字符流变成 Token 流
│   (Lexing)    │    识别关键字、标识符、运算符
└──────┬──────┘
      │ Token 流
      ▼
┌─────────────┐
│ 2. 语法分析   │ ── 把 Token 流变成 AST（抽象语法树）
│   (Parsing)   │    检查语法结构是否合法
└──────┬──────┘
      │ AST
      ▼
┌─────────────┐
│ 3. 语义分析   │ ── 给 AST 附加类型信息
│  (Analysis)   │    类型检查、访问控制检查、泛型擦除
└──────┬──────┘
      │ 带属性的 AST
      ▼
┌──────────────┐
│ 4. 注解处理    │ ── 执行注解处理器
│  (Annotation)  │    可能生成新的源文件（回到第 1 步）
└──────┬───────┘
      │
      ▼
┌──────────────┐
│ 5. 脱糖       │ ── 将语法糖转为基础结构
│  (Desugar)    │    泛型擦除、自动装箱、for-each 展开
└──────┬──────┘
      │
      ▼
┌──────────────┐
│ 6. 字节码生成  │ ── 将 AST 转为字节码指令
│  (Generate)   │    生成 .class 文件
└──────────────┘

第一阶段：词法分析（Lexical Analysis）

词法分析器也叫"扫描器"（Scanner），它把源代码的字符流转换为Token 流。

比喻：这就像阅读一本书——你先把连续的字母组合成"单词"，然后才能理解句子的意思。词法分析就是"识别单词"的过程。

// 源代码
public class Hello {
    int x = 42;
}

词法分析后变成一个 Token 序列：

[PUBLIC] [CLASS] [IDENTIFIER:"Hello"] [LBRACE]
[INT] [IDENTIFIER:"x"] [ASSIGN] [INTEGER_LITERAL:42] [SEMICOLON]
[RBRACE]

每个 Token 包含两个信息：类型（关键字、标识符、运算符、字面量等）和值。

词法分析阶段能发现的错误：

非法字符（如在标识符中使用 #）
未闭合的字符串字面量
非法的数字字面量（如 0x 后面没有跟十六进制数字）

第二阶段：语法分析（Syntax Analysis / Parsing）

语法分析器（Parser）将 Token 流组织成抽象语法树（Abstract Syntax Tree，简称 AST）——一种树形数据结构，忠实地反映了代码的层次结构。

ClassDecl: "Hello"
├── Modifiers: [public]
└── Members:
    └── VarDecl: "x"
        ├── Type: int
        └── Init: Literal(42)

语法分析阶段能发现的错误就是我们常见的语法错误：

缺少分号
括号不匹配
非法的语句结构（比如 if 后面没有条件表达式）

public class Hello {
    int x = ;  // ❌ 语法错误：表达式缺失
}

编译器在 Token 流 [ASSIGN] [SEMICOLON] 中发现，= 号后面应该跟一个表达式，但直接遇到了分号——这不符合 Java 的语法规则，于是报告语法错误。

第三阶段：语义分析（Semantic Analysis）

这是编译过程中最关键的阶段。语法分析只检查代码的"形状"是否正确（像不像合法的 Java 代码），语义分析则检查代码的"含义"是否正确（这段代码有没有逻辑问题）。

符号解析（Symbol Resolution）

编译器维护一个符号表（Symbol Table），记录每个标识符的声明信息（类型、作用域、访问修饰符等）。当代码中引用一个变量或方法时，编译器在符号表中查找它的声明：

int x = 10;
System.out.println(y);  // ❌ 语义错误：y 未声明

编译器在符号表中找不到 y 的声明，报错 cannot find symbol。

类型检查（Type Checking）

Java 是静态类型语言——每个变量都有确定的类型，类型的一致性在编译时就要验证：

String s = "hello";
int n = s;       // ❌ 类型不兼容：String 不能赋给 int
int m = s + 1;   // ❌ 不能把 String 和 int 相加得到 int

类型检查还包括：

方法调用时参数类型是否匹配
返回值类型是否与方法声明一致
类型转换是否合法（向下转型需要显式 cast）

访问控制检查

这就是我们在上一篇「访问修饰符的实现原理」中讲到的编译期检查：

class Other {
    void test() {
        Demo demo = new Demo();
        demo.d;  // ❌ d has private access in Demo
    }
}

编译器从符号表中查到 d 的 access_flags 是 private，而 Other 类不是 Demo 类，因此拒绝编译。

方法重载解析（Overload Resolution）

编译时多态就发生在这个阶段。当你调用一个重载方法时，编译器根据参数的静态类型来决定调用哪一个：

void print(Object obj)  { System.out.println("Object"); }
void print(String str)  { System.out.println("String"); }

print("hello");  // 编译器选择 print(String)——因为 "hello" 的类型是 String

重载解析的算法相当复杂（涉及自动装箱、可变参数、泛型推断等），但核心原则是：选择最具体的匹配。

第四阶段：注解处理

如果代码中使用了注解（如 @Override、@Getter），编译器会在这个阶段执行注册的注解处理器（Annotation Processor）。

@Override 就是一个典型的编译期注解：

class Dog extends Animal {
    @Override
    void speak() { ... }  // 编译器检查 Animal 中是否有同签名方法
}

注解处理器可以：

检查代码是否符合约定（如 @Override 检查方法签名）
生成新的 Java 源文件（如 Lombok 的 @Getter 自动生成 getter 方法）
生成新的资源文件

如果注解处理器生成了新的源文件，编译器会进入新一轮的编译（从词法分析开始），直到没有新文件产生为止。

第五阶段：脱糖（Desugaring）

Java 的很多语法特性都是"语法糖"——让代码更易读写，但不改变底层能力。编译器在这个阶段把语法糖"脱"掉，转换为等价的基础结构：

语法糖	脱糖后
泛型 `List<String>`	类型擦除为 `List`，插入强制转型
自动装箱 `Integer n = 42`	`Integer n = Integer.valueOf(42)`
自动拆箱 `int x = integerObj`	`int x = integerObj.intValue()`
增强 for-each	转为 Iterator 循环或数组下标循环
try-with-resources	转为 try-finally + close()
String 拼接 `"a" + "b"`	`new StringBuilder().append("a").append("b").toString()`
Lambda 表达式	生成 `invokedynamic` + 私有静态方法

以泛型擦除为例：

// 源码
List<String> list = new ArrayList<>();
String s = list.get(0);

// 脱糖后（编译器实际生成的等价代码）
List list = new ArrayList();
String s = (String) list.get(0);  // 编译器插入了强制转型

这就解释了为什么泛型信息在运行时"消失"了——它在编译阶段就被擦除了，只留下了原始类型和必要的强制转型。

第六阶段：字节码生成（Code Generation）

最后一步，编译器将处理后的 AST 转换为 JVM 字节码，写入 .class 文件。要理解编译的最终产物，我们需要搞清楚：一个 .class 文件到底长什么样？里面装了什么？

整体比喻：.class 文件就是一份"员工档案"

在深入每个字段之前，先建立一个整体直觉。可以把一个 .class 文件想象成一个类交给 JVM 的**"入职档案"**：

┌──────────────────────────────────────────────────┐
│  .class 文件 = 一份"员工档案"                        │
│                                                      │
│  📌 封面印章（魔数）     → 证明是正规档案，不是伪造的     │
│  📅 适用制度版本（版本号） → JVM 的哪个版本能读懂这份档案  │
│  📒 通讯录（常量池）      → 所有名字、地址的集中登记簿     │
│  🏷️ 权限牌（access_flags）→ public？final？abstract？  │
│  👤 个人信息（this/super） → 我是谁，我爸是谁            │
│  📜 资格证书（interfaces） → 我实现了哪些接口             │
│  💼 财产清单（字段表）     → 我有哪些属性（字段）          │
│  📋 工作手册（方法表）     → 我能做哪些事（方法+字节码）   │
│  📎 附件（属性表）         → 源文件名、调试信息等补充材料   │
└──────────────────────────────────────────────────┘

现在我们逐个字段"翻开"这份档案。

ClassFile 结构定义

ClassFile {
    u4             magic;                // 📌 封面印章
    u2             minor_version;        // 📅 次版本号
    u2             major_version;        // 📅 主版本号
    u2             constant_pool_count;  // 📒 通讯录有多少条
    cp_info        constant_pool[];      // 📒 通讯录内容
    u2             access_flags;         // 🏷️ 权限牌
    u2             this_class;           // 👤 我是谁（指向常量池）
    u2             super_class;          // 👤 我爸是谁（指向常量池）
    u2             interfaces_count;     // 📜 资格证数量
    u2             interfaces[];         // 📜 资格证列表
    u2             fields_count;         // 💼 财产数量
    field_info     fields[];             // 💼 财产清单
    u2             methods_count;        // 📋 技能数量
    method_info    methods[];            // 📋 工作手册
    u2             attributes_count;     // 📎 附件数量
    attribute_info attributes[];         // 📎 附件
}

其中 u1、u2、u4 分别表示 1 字节、2 字节、4 字节的无符号整数。.class 文件就是这些字段按顺序紧密排列的二进制字节流，中间没有任何分隔符——JVM 读取时靠字段长度和 count 值来确定边界。

📌 magic（魔数）—— 封面印章

字节偏移: 0-3
固定值: 0xCA 0xFE 0xBA 0xBE

每个 .class 文件的头 4 个字节永远是 0xCAFEBABE（"咖啡宝贝"）。这就像档案封面上的公章——JVM 拿到一个文件，先看前 4 个字节，如果不是 CAFEBABE，直接拒绝加载（抛出 ClassFormatError）。

很多文件格式都有类似的魔数：PNG 图片以 89 50 4E 47 开头，PDF 以 25 50 44 46（%PDF）开头。魔数的作用是快速识别文件类型，比看文件扩展名更可靠。

📅 minor_version + major_version（版本号）—— 适用的制度版本

字节偏移: 4-5（次版本号），6-7（主版本号）

版本号决定了这份档案是按哪个制度版本编写的——也就是需要什么版本的 JVM 才能读懂它。

主版本号	对应 JDK 版本	新增的语言特性
52	Java 8	Lambda、default 方法
55	Java 11	Nestmates、var
61	Java 17	sealed class、模式匹配
65	Java 21	虚拟线程、Record 模式

如果一份档案的版本号是 61（Java 17 编译的），但你拿给一个只认识版本 52（Java 8）的 JVM 去读，JVM 会说："这份档案用的制度太新了，我看不懂"——抛出 UnsupportedClassVersionError。

📒 constant_pool（常量池）—— 通讯录

字节偏移: 8-9（count），之后紧跟常量池条目

常量池是整个 .class 文件的**"通讯录"，也是最大、最复杂**的部分（通常占整个文件的 60% 以上）。

为什么需要通讯录？ 想象一下，一个方法体里写了 System.out.println("hello")。这条语句涉及三个"名字"：类名 java/lang/System、字段名 out、方法名 println，还有字符串 "hello"。如果每次出现这些名字都直接写完整内容，字节码会变得很大，而且充满重复。

常量池的策略是集中登记、编号引用：

常量池（通讯录）:
  #1  = Utf8      "java/lang/System"      ← 存一次完整的名字
  #2  = Class     #1                       ← "类 System" 引用 #1
  #3  = Utf8      "out"
  #4  = Utf8      "Ljava/io/PrintStream;"
  #5  = NameAndType  #3:#4                 ← "字段 out，类型 PrintStream"
  #6  = Fieldref     #2.#5                 ← "System 类的 out 字段"
  #7  = Utf8      "hello"
  #8  = String    #7                       ← 字符串常量 "hello"
  ...

字节码中使用时，只写编号：
  getstatic #6       // 等价于 System.out
  ldc       #8       // 等价于 "hello"
  invokevirtual #9   // 等价于 PrintStream.println(String)

可以看到，常量之间是层层引用的：Fieldref 引用 Class 和 NameAndType，Class 又引用 Utf8。最底层的 Utf8 才存储真正的字符串内容。这种多级引用设计实现了最大程度的去重。

常量池的主要条目类型：

类型	作用	比喻
`Utf8`	存储原始字符串（类名、方法名等）	通讯录里的"原始姓名"
`Class`	引用一个 Utf8 条目组成类的全限定名	"张三住在 xx 路"（人+地址的组合）
`NameAndType`	组合一个名字和类型描述符	"技能名 + 技能说明"
`Fieldref`	类 + NameAndType = 完整的字段引用	"张三的身高"（人+属性）
`Methodref`	类 + NameAndType = 完整的方法引用	"张三的跑步技能"（人+技能）
`String`	引用一个 Utf8 作为字符串常量	源代码中的 `"hello"`
`Integer`/`Long`/`Float`/`Double`	直接存储数值常量	源代码中的 `42`、`3.14`

一个重要细节：constant_pool_count 的值比实际条目数大 1，因为常量池索引从 1 开始（0 号位保留表示"不引用任何常量"）。如果 count = 15，那实际有 14 个常量条目（#1 ~ #14）。

🏷️ access_flags（访问标志）—— 权限牌

2 字节的位掩码

这个字段描述的是类本身的修饰符，用位掩码组合表示：

标志	值	含义
`ACC_PUBLIC`	`0x0001`	`public` 类
`ACC_FINAL`	`0x0010`	`final` 类（不可继承）
`ACC_SUPER`	`0x0020`	使用 `invokespecial` 的新语义（JDK 1.2+，几乎所有类都有）
`ACC_INTERFACE`	`0x0200`	接口
`ACC_ABSTRACT`	`0x0400`	抽象类
`ACC_SYNTHETIC`	`0x1000`	编译器生成的类
`ACC_ENUM`	`0x4000`	枚举类

例如一个 public class Hello 的 access_flags = 0x0021（ACC_PUBLIC | ACC_SUPER）。一个 public abstract interface Runnable 的 access_flags = 0x0601（ACC_PUBLIC | ACC_INTERFACE | ACC_ABSTRACT）。

这些标志和前面「访问修饰符的实现原理」那篇文章中讲的 ACC_PUBLIC / ACC_PRIVATE 是同一套机制——只不过那里讲的是字段和方法的 flags，这里讲的是类级别的 flags。

👤 this_class + super_class（当前类与父类）—— 我是谁，我爸是谁

各 2 字节，值是常量池的索引号

这两个字段不直接存储类名，而是存一个常量池索引，指向一个 CONSTANT_Class 条目。

this_class = #8      →  常量池 #8 = Class #10  →  #10 = Utf8 "Hello"
super_class = #2     →  常量池 #2 = Class #4   →  #4  = Utf8 "java/lang/Object"

如果一个类没有显式 extends，super_class 指向 java/lang/Object。只有 Object 类本身的 super_class 是 0（表示没有父类）。

📜 interfaces（接口列表）—— 资格证书

interfaces_count: 2 字节（接口数量）
interfaces[]:    每个元素 2 字节（常量池索引，指向 CONSTANT_Class）

如果类声明了 implements Runnable, Serializable，那 interfaces_count = 2，interfaces[] 里有两个指向常量池的索引。

💼 fields（字段表）—— 财产清单

每个字段用一个 field_info 结构描述：

field_info {
    u2  access_flags;      // 这个字段的修饰符（private/static/final 等）
    u2  name_index;        // 字段名，指向常量池的 Utf8 条目（如 "name"）
    u2  descriptor_index;  // 类型描述符，指向常量池的 Utf8 条目（如 "Ljava/lang/String;"）
    u2  attributes_count;  // 附加属性数
    attribute_info attributes[];
}

注意 name_index 和 descriptor_index 不是直接存字符串，而是存常量池的编号——再一次体现了"通讯录引用"的设计。

类型描述符是 JVM 自己的一套紧凑编码，把 Java 的类型名缩短为尽可能少的字符：

Java 类型	描述符	记忆技巧
`byte`	`B`	Byte
`char`	`C`	Char
`double`	`D`	Double
`float`	`F`	Float
`int`	`I`	Int
`long`	`J`	跳过了 K，用 J（因为 L 被引用类型占了）
`short`	`S`	Short
`boolean`	`Z`	booleaZ（因为 B 被 byte 占了）
`void`	`V`	Void
`String`	`Ljava/lang/String;`	L + 全限定名 + ;
`int[]`	`[I`	[ + 元素描述符
`String[][]`	`[[Ljava/lang/String;`	几维就几个 [

方法的描述符把参数和返回值组合在一起，格式是 (参数描述符)返回值描述符：

Java 方法签名	方法描述符	解读
`void main(String[] args)`	`([Ljava/lang/String;)V`	参数：String 数组；返回：void
`int add(int a, int b)`	`(II)I`	参数：两个 int；返回：int
`String toString()`	`()Ljava/lang/String;`	参数：无；返回：String

📋 methods（方法表）—— 工作手册

方法表的外层结构与字段表类似：

method_info {
    u2  access_flags;      // 方法修饰符
    u2  name_index;        // 方法名（如 "greet"，构造器叫 "<init>"）
    u2  descriptor_index;  // 方法描述符（如 "(Ljava/lang/String;)V"）
    u2  attributes_count;
    attribute_info attributes[];  // 最重要的属性是 Code
}

方法的灵魂在 Code 属性里——它存储了这个方法的实际执行指令。如果说 method_info 是工作手册的封面（方法名、参数、权限），那 Code 属性就是手册的正文（具体步骤）。

Code_attribute {
    u2  max_stack;       // 操作数栈的最大深度
    u2  max_locals;      // 局部变量表的槽位数
    u4  code_length;     // 字节码指令的总字节数
    u1  code[];          // ← 字节码指令序列（核心中的核心！）
    u2  exception_table_length;
    exception_info exception_table[];  // 异常处理表（try-catch）
    u2  attributes_count;
    attribute_info attributes[];       // LineNumberTable 等
}

逐个字段解释：

max_stack（操作数栈最大深度）：JVM 执行字节码时使用栈式计算——不像 CPU 有寄存器，JVM 把中间值都放在一个"栈"上。max_stack 告诉 JVM "这个方法最多需要多深的栈"，好提前分配空间。

比如计算 a + b：

  iload_1      // 把 a 压入栈      栈：[a]
  iload_2      // 把 b 压入栈      栈：[a, b]
  iadd         // 弹出两个，相加   栈：[a+b]
  istore_3     // 弹出，存到变量 c  栈：[]

这个过程中栈最深到了 2 层 → max_stack = 2

max_locals（局部变量表大小）：局部变量表是用来存储方法参数和局部变量的数组。索引 0 永远是 this（非静态方法），后面依次是方法参数，再后面是方法体中声明的局部变量。

public void test(int x, String s) {
    double d = 3.14;
}

局部变量表：
  slot 0: this          ← 自动占用
  slot 1: x (int)       ← 参数 1
  slot 2: s (String)    ← 参数 2
  slot 3-4: d (double)  ← 局部变量（double 占两个 slot）

max_locals = 5

code[]（字节码指令数组）：这是整个 .class 文件的最核心部分。它是一个字节数组，JVM 从头开始逐字节读取和执行。每条指令由 1 个字节的操作码（opcode）和 0~N 个字节的操作数组成。

code[] = [2A, B7, 00, 01, 2A, 2B, B5, 00, 07, B1]

拆解：
  2A       → aload_0            把 this 压栈
  B7 00 01 → invokespecial #1   调用 Object.<init>()，#1 是常量池索引
  2A       → aload_0            把 this 压栈
  2B       → aload_1            把参数 1 压栈
  B5 00 07 → putfield #7        this.name = 参数1，#7 是常量池中的字段引用
  B1       → return             返回

可以看到，操作码像 2A、B7 这些是固定的编码（JVM 规范定义了 200 多个操作码），操作数是跟在后面的字节。B7 00 01 的意思是"操作码 B7（invokespecial），操作数 0001（常量池第 1 项）"。

exception_table（异常处理表）：try-catch 不是靠特殊的字节码指令实现的，而是靠这张表。它告诉 JVM："如果在第 X 到第 Y 行字节码之间发生了 Z 异常，就跳转到第 W 行处理。"

exception_table:
  from=0, to=4, target=7, type=IOException
  // 如果字节码偏移 0~4 之间抛出 IOException，跳到偏移 7 继续执行

📎 attributes（属性表）—— 附件

属性表是一种灵活的扩展机制——类、字段、方法、Code 都可以携带属性。JVM 不认识的属性会被直接忽略，所以新版本 JDK 可以添加新属性而不破坏旧版本的兼容性。

常见属性及其作用：

属性名	附加在	作用	日常影响
`Code`	方法	存储字节码指令	没有它方法就无法执行
`LineNumberTable`	Code	字节码偏移 → 源码行号的映射	异常堆栈中显示"at Hello.java:5"
`LocalVariableTable`	Code	局部变量的名字和作用域	调试时 IDE 能显示变量名
`SourceFile`	类	源文件名	异常堆栈中显示"at Hello.java"
`ConstantValue`	字段	`static final` 编译期常量的值	`static final int X = 42` 会直接内联
`Exceptions`	方法	`throws` 声明的受检异常列表	编译器检查是否处理了受检异常
`InnerClasses`	类	内部类与外部类的关系	反射能找到内部类
`BootstrapMethods`	类	`invokedynamic` 的引导方法表	Lambda、字符串拼接的底层机制
`NestHost`/`NestMembers`	类	JDK 11+ 嵌套类访问控制	内部类访问外部类 private 成员

全景总结：一个 .class 文件的完整"剖面图"

一个 .class 文件的字节流（从头到尾）：

CA FE BA BE       ← 📌 魔数：证明是合法的 class 文件
00 00 00 3D       ← 📅 版本：次版本 0，主版本 61（Java 17）
00 0F             ← 📒 常量池条目数：15（实际 14 个，#1~#14）
[...常量池...]     ← 📒 14 个常量条目（Utf8、Class、Methodref 等）
00 21             ← 🏷️ access_flags：ACC_PUBLIC | ACC_SUPER
00 08             ← 👤 this_class：#8（常量池中的 "Hello"）
00 02             ← 👤 super_class：#2（常量池中的 "Object"）
00 00             ← 📜 interfaces_count：0（没有实现接口）
00 01             ← 💼 fields_count：1
[...1个字段...]    ← 💼 private String name 的 field_info
00 02             ← 📋 methods_count：2
[...2个方法...]    ← 📋 构造器和 greet() 的 method_info + Code
00 01             ← 📎 attributes_count：1
[...SourceFile...] ← 📎 SourceFile = "Hello.java"

实际验证：用 javap 查看真实 .class 文件

用一个简单的类来验证上面所有内容：

public class Hello {
    private String name;

    public Hello(String name) {
        this.name = name;
    }

    public String greet() {
        return "Hello, " + name;
    }
}

执行 javap -v Hello.class（精简后的输出）：

// ─── 📌📅 魔数 + 版本 ───
Classfile Hello.class
  Compiled from "Hello.java"
  minor version: 0
  major version: 61                              // Java 17

// ─── 🏷️👤 access_flags + this/super ───
public class Hello                               // ACC_PUBLIC
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER

// ─── 📒 常量池 ───
Constant pool:
   #1 = Methodref    #2.#3       // Object.<init>:()V
   #2 = Class        #4          // java/lang/Object
   #3 = NameAndType  #5:#6       // <init>:()V
   #4 = Utf8         java/lang/Object
   #5 = Utf8         <init>               // 构造器的固定名字
   #6 = Utf8         ()V                  // 方法描述符：无参，返回 void
   #7 = Fieldref     #8.#9       // Hello.name:Ljava/lang/String;
   #8 = Class        #10         // Hello
   #9 = NameAndType  #11:#12     // name:Ljava/lang/String;
  #10 = Utf8         Hello
  #11 = Utf8         name
  #12 = Utf8         Ljava/lang/String;   // String 的类型描述符
  ...

// ─── 💼 字段表 ───
{
  private java.lang.String name;
    descriptor: Ljava/lang/String;            // 类型描述符
    flags: (0x0002) ACC_PRIVATE               // 访问标志

// ─── 📋 方法表：构造器 ───
  public Hello(java.lang.String);
    descriptor: (Ljava/lang/String;)V         // 参数 String，返回 void
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2          // 栈深 2，局部变量 2 个
         0: aload_0                           // 把 this 压栈
         1: invokespecial #1                  // 调用 Object.<init>()
         4: aload_0                           // 把 this 压栈
         5: aload_1                           // 把参数 name 压栈
         6: putfield      #7                  // this.name = name
         9: return
      LineNumberTable:
        line 4: 0                             // 字节码偏移 0 → 源码第 4 行
        line 5: 4                             // 字节码偏移 4 → 源码第 5 行

// ─── 📋 方法表：greet() ───
  public java.lang.String greet();
    descriptor: ()Ljava/lang/String;
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: getfield      #7                  // 读取 this.name
         4: invokedynamic #13, 0              // 字符串拼接
         9: areturn                            // 返回 String
}

// ─── 📎 属性表 ───
SourceFile: "Hello.java"

对照这份 javap 输出，你能看到我们讲过的每一个部分：常量池里的引用链（#7→#8+#9→#11+#12），字段的 access_flags 和描述符，方法的 Code 属性中的操作数栈操作，以及 LineNumberTable 如何把字节码偏移映射回源码行号。

为什么编译器能发现错误？

回到最初的问题：我们写了不符合规范的代码，编译器为什么能识别出来？

答案就在编译过程的每个阶段——每个阶段都有自己的"检查职责"：

错误类型	发现阶段	示例
非法字符	词法分析	`int # = 1;`
未闭合的字符串	词法分析	`"hello`
缺少分号	语法分析	`int x = 1`
括号不匹配	语法分析	`if (x > 0 {`
变量未声明	语义分析（符号解析）	`System.out.println(y);`
类型不兼容	语义分析（类型检查）	`int x = "hello";`
访问权限违规	语义分析（访问控制）	`obj.privateField`
方法不存在	语义分析（符号解析）	`obj.nonExist()`
@Override 无效	注解处理	签名不匹配的 @Override

比喻：编译器就像一个严格的编辑审稿流程。词法分析是校对员，检查有没有错别字（非法字符）；语法分析是语法编辑，检查句子结构是否通顺（语法正确）；语义分析是主编，检查文章逻辑是否自洽（类型安全、变量存在、权限合法）。只有通过了所有编辑的审核，文章（字节码）才能出版（生成 .class 文件）。

IDE 是怎么做到"实时报红"的？

现代 IDE（如 IntelliJ IDEA、VS Code）能在你打字的同时就标出错误，这不是因为它在后台不断编译你的代码，而是因为 IDE 内部运行了一个增量编译器：

IDE 维护着整个项目的符号表和AST
当你修改一个文件时，IDE 只重新解析修改的部分（增量更新 AST）
对修改的部分重新进行语义分析（类型检查、符号解析等）
将检测到的错误实时显示为红色波浪线

这就是为什么 IDE 的错误提示比 javac 更快——它不需要从头编译整个文件，只需要增量更新受影响的部分。

编译时多态 vs 运行时多态：完整对比

维度	编译时多态（重载）	运行时多态（重写）
机制	方法签名唯一确定	虚方法表动态查找
依据	参数的静态类型	对象的实际类型
字节码	方法引用已确定	`invokevirtual` 延迟解析
确定时机	编译时	运行时
性能	无额外开销	vtable 索引查找（O(1)）
典型场景	`println(int)` vs `println(String)`	`animal.speak()` → Dog or Cat

一道经典架构问题

class Parent {
    void show(Parent p) { System.out.println("Parent-Parent"); }
    void show(Child c)  { System.out.println("Parent-Child"); }
}

class Child extends Parent {
    @Override
    void show(Parent p) { System.out.println("Child-Parent"); }
    void show(Child c)  { System.out.println("Child-Child"); }
}

Parent p = new Child();
p.show(new Child());  // 输出什么？

分步分析

第一步：编译时——重载解析（选方法签名）

编译器只看 p 的静态类型 Parent，在 Parent 类中找到两个候选方法：

show(Parent p) — 参数类型 Parent
show(Child c) — 参数类型 Child

实际参数 new Child() 的静态类型是 Child。Child 既可以匹配 Parent（因为 Child 是 Parent 的子类），也可以匹配 Child（精确匹配）。根据重载解析的"最具体匹配"原则，编译器选择 → show(Child)。

编译后的字节码：

invokevirtual Parent.show(Child)   // 方法签名已确定为 show(Child)

第二步：运行时——vtable 分派（选方法实现）

p 的实际类型是 Child。JVM 在 Child 的 vtable 中查找 show(Child) 的条目。

关键问题：Child.show(Child c) 是不是对 Parent.show(Child c) 的重写？

是的。 判断方法重写只看两个条件：

方法名相同 — 都是 show ✅
参数列表相同 — 都是 (Child c) ✅

@Override 注解不是重写的必要条件——它只是一个编译器辅助检查工具。不写 @Override，重写照样生效；写了 @Override 但签名不匹配，编译器反而会报错。

所以 Child 的 vtable 是这样的：

Child 的 vtable:
┌──────────────┬─────────────────────────────────┐
│  show(Parent) │ → Child.show(Parent)            │ ← @Override 重写了
│  show(Child)  │ → Child.show(Child)             │ ← 也重写了（签名相同）
└──────────────┴─────────────────────────────────┘

JVM 通过 vtable 索引找到 show(Child) → Child.show(Child) → 执行。

输出：Child-Child

变种题：真正"不构成重写"的场景

如果把 Child 的 show 方法参数类型改一下，情况就不同了：

class Parent {
    void show(Parent p) { System.out.println("Parent-Parent"); }
}

class Child extends Parent {
    // 注意：参数类型是 Child，不是 Parent
    // 这不是重写，而是重载！
    void show(Child c) { System.out.println("Child-Child"); }
}

Parent p = new Child();
p.show(new Child());  // 输出什么？

分析：

编译时：p 的静态类型是 Parent，编译器在 Parent 中只找到一个方法 show(Parent)。虽然 Child 类中有 show(Child)，但编译器不看 Child 的方法（因为 p 的静态类型是 Parent）→ 选择 show(Parent)
运行时：查找 show(Parent) 在 Child 的 vtable 中的条目。Child 没有重写 show(Parent)（它定义的是 show(Child)，参数类型不同，不构成重写）→ 仍然调用 Parent.show(Parent)

输出：Parent-Parent

这个变种题才是重载和重写不构成覆盖的经典场景：Child.show(Child) 和 Parent.show(Parent) 参数类型不同，它们是重载关系，不是重写关系。

为什么和经典题结果不同？ 初读这道变种题，很容易联想到经典题的结果 Child-Child，从而以为这里也应该输出 Child-Child。混淆的根源在于两题的 Parent 类结构不同：

经典题变种题

Parent 有哪些方法 show(Parent) 和 show(Child) 两个只有 show(Parent) 一个

编译时选哪个签名两个候选中选最具体的 show(Child) 只有一个候选，只能选 show(Parent)

Child 是否重写了被选中的签名重写了 show(Child) → vtable 指向 Child 实现未重写 show(Parent) → vtable 继承 Parent 实现

最终输出 Child-Child Parent-Parent

变种题的陷阱正在第一步：编译器只看 p 的静态类型 Parent，根本"看不见" Child.show(Child) 这个方法。既然字节码里写的是 invokevirtual Parent.show(Parent)，运行时 vtable 自然也只找 show(Parent) 的条目——此时 Child 没有重写它，调用回退到 Parent 的实现，输出 Parent-Parent。

	经典题	变种题
`Parent` 有哪些方法	`show(Parent)` 和 `show(Child)` 两个	只有 `show(Parent)` 一个
编译时选哪个签名	两个候选中选最具体的 `show(Child)`	只有一个候选，只能选 `show(Parent)`
`Child` 是否重写了被选中的签名	重写了 `show(Child)` → vtable 指向 Child 实现	未重写 `show(Parent)` → vtable 继承 Parent 实现
最终输出	`Child-Child`	`Parent-Parent`

核心要点

判断是否构成重写，只看方法签名（方法名 + 参数列表），不看 @Override 注解、不看返回值类型（协变返回除外）。编译器用静态类型做重载解析选签名，JVM 用实际类型做 vtable 查找选实现——两步缺一不可。

总结

                编译阶段                           运行阶段
                  │                                  │
    ┌─────────────┴──────────────┐      ┌───────────┴───────────┐
    │                            │      │                       │
词法分析 → 语法分析 → 语义分析      invokevirtual 执行时
    │         │         │              │
 非法字符  语法错误  类型检查         对象实际类型
 未闭合串  缺分号   符号解析          → vtable 索引查找
                    访问控制          → 调用正确的方法实现
                    重载解析
                      │
              （编译时多态在此确定）    （运行时多态在此确定）

编译时多态（重载）：编译器根据参数的静态类型选择方法签名
运行时多态（重写）：JVM 根据对象的实际类型在 vtable 中查找方法实现
编译器发现错误：六个编译阶段层层过滤，从字符到语法到语义全方位检查
vtable 是多态的核心数据结构，用数组索引实现 O(1) 的方法查找

多态的实现原理与编译过程

hard多态编译原理字节码JVMinvokevirtualvtable最近更新

多态的两种形态

在深入底层之前，先明确"多态"在 Java 中的两种表现形式。

编译时多态：方法重载（Overloading）

同一个类中方法名相同，但参数列表不同：

public class Calculator {
    int add(int a, int b) { return a + b; }
    double add(double a, double b) { return a + b; }
    int add(int a, int b, int c) { return a + b + c; }
}

Calculator calc = new Calculator();
calc.add(1, 2);       // 调用 add(int, int)
calc.add(1.0, 2.0);   // 调用 add(double, double)

运行时多态：方法重写（Overriding）

子类重写父类的方法，通过父类引用调用时，实际执行子类的实现：

Animal animal = new Dog();  // 编译时类型是 Animal，运行时类型是 Dog
animal.speak();             // 运行时才能确定调用 Dog.speak()

JVM 在运行时才能根据对象的实际类型决定调用哪个方法，所以叫"运行时多态"（也叫动态分派）。这是多态的核心，也是本文的重点。

比喻：编译时多态就像你去餐厅点菜——菜单（方法名）一样，但你点"小份可乐"还是"大份可乐"，点单时（编译时）就确定了。运行时多态就像快递配送——你下单时写的地址是"张三家"（父类引用），但快递员到了才发现张三搬到了新地址（实际类型），需要送到新地址去。

运行时多态的底层机制

字节码层面：五种 invoke 指令

Java 编译器会根据方法调用的类型，生成不同的字节码指令：

指令	用途	分派方式	示例
`invokestatic`	静态方法	静态（编译时确定）	`Math.max(1, 2)`
`invokespecial`	构造器、private 方法、super 调用	静态（编译时确定）	`super.toString()`
`invokevirtual`	实例方法（类的方法）	动态（运行时确定）	`animal.speak()`
`invokeinterface`	接口方法	动态（运行时确定）	`list.add(x)`
`invokedynamic`	Lambda、方法引用等	动态（引导方法决定）	`() -> {}`

多态的关键在于 invokevirtual 和 invokeinterface——它们在运行时根据对象的实际类型来决定调用哪个方法实现。

让我们看一个具体例子：

Animal animal = new Dog();
animal.speak();

编译后的字节码：

new           #2    // class Dog
dup
invokespecial #3    // Dog.<init>()          ← 调用构造器，编译时确定
astore_1
aload_1
invokevirtual #4   // Animal.speak()        ← 注意：字节码里写的是 Animal

JVM 层面：虚方法表（VTable）

JVM 如何在运行时快速找到正确的方法实现？答案是虚方法表（Virtual Method Table，简称 vtable）。

vtable 的结构

当 JVM 加载一个类时，会为这个类创建一个虚方法表。vtable 本质上是一个数组，每个元素是一个指向方法实际代码的指针：

Object 的 vtable:
┌───────────┬──────────────────────┐
│  索引 0   │ → Object.toString()  │
│  索引 1   │ → Object.hashCode()  │
│  索引 2   │ → Object.equals()    │
│  索引 3   │ → Object.finalize()  │
│   ...     │ → ...                │
└───────────┴──────────────────────┘

Animal 的 vtable:
┌───────────┬──────────────────────┐
│  索引 0   │ → Object.toString()  │  ← 继承自 Object
│  索引 1   │ → Object.hashCode()  │  ← 继承自 Object
│  索引 2   │ → Object.equals()    │  ← 继承自 Object
│  索引 3   │ → Object.finalize()  │  ← 继承自 Object
│  索引 4   │ → Animal.speak()     │  ← 新增方法
│  索引 5   │ → Animal.eat()       │  ← 新增方法
└───────────┴──────────────────────┘

Dog 的 vtable:
┌───────────┬──────────────────────┐
│  索引 0   │ → Dog.toString()     │  ← 重写了 Object 的方法
│  索引 1   │ → Object.hashCode()  │  ← 继承
│  索引 2   │ → Object.equals()    │  ← 继承
│  索引 3   │ → Object.finalize()  │  ← 继承
│  索引 4   │ → Dog.speak()        │  ← 重写了 Animal 的方法
│  索引 5   │ → Animal.eat()       │  ← 继承
│  索引 6   │ → Dog.fetch()        │  ← 新增方法
└───────────┴──────────────────────┘

vtable 的关键规则

子类的 vtable 包含父类的所有方法，方法在表中的索引位置与父类保持一致
如果子类重写了某个方法，对应索引位置的指针就指向子类的新实现
如果子类没有重写，该指针仍然指向父类的实现
子类新增的方法追加在 vtable 的末尾

动态分派的执行过程

当 JVM 遇到 invokevirtual Animal.speak() 时，执行以下步骤：

1. 从操作数栈弹出对象引用（objectref）
2. 找到 objectref 指向的实际对象（这里是 Dog 实例）
3. 通过对象头中的类型指针，找到 Dog 的 Class 对象
4. 在 Dog 的 vtable 中查找 speak() 的索引（索引 4）
5. 通过索引 4 找到 → Dog.speak() 的方法指针
6. 执行 Dog.speak() 的代码

因为 vtable 用的是数组索引，所以方法查找的时间复杂度是 O(1)——这就是为什么 Java 的方法调用性能很高。

invokeinterface 与 itable

接口方法的分派与类方法有本质区别。要理解这个区别，首先要想清楚一个问题：为什么接口方法不能直接用 vtable？

为什么接口不能复用 vtable 的固定索引

但接口不同。一个类可以实现多个接口，不同的类实现接口的顺序也不同：

class Dog implements Runnable, Comparable<Dog> { ... }
class Cat implements Comparable<Cat>, Serializable { ... }

比喻：vtable 就像一栋大楼的固定楼层分配——3 楼永远是财务部，5 楼永远是技术部。这在只有一栋总部大楼（单继承）时没问题。但接口就像"合作协议"——不同公司（类）可以签不同的合作协议（实现不同接口），你不能假设每家公司都把合作部门放在同一楼层。

所以 JVM 需要一种额外的数据结构来处理接口方法的分派——这就是 itable（Interface Method Table）。

itable 的数据结构

JVM 为每个实现了接口的类维护一个 itable。它是一个两级结构——乍看之下像二维数组，但实际上不是。

准确地说，itable 的内存布局是这样的：

第一级是一个一维数组，每个元素是一个二元组 (接口的Class指针, 方法表的偏移量/指针)
第二级是多个独立的方法指针数组，每个数组对应一个接口，存储该接口中每个方法的实现指针

内存中的真实布局（连续的一块内存）：
┌──────────────────────────────────────────────┐
│ 接口条目 0: (Runnable指针,  偏移量 → ────┐)    │  ← 第一级
│ 接口条目 1: (Comparable指针, 偏移量 → ──┐│)    │     （数组）
├──────────────────────────────────────────│┼───┤
│ Runnable 方法表:  run() → Dog.run()  ←──┘│    │  ← 第二级
│ Comparable 方法表: compareTo() → ...  ←───┘    │    （方法表）
└──────────────────────────────────────────────┘

下面用更直观的逻辑视角来展示这个结构：

Dog 的 itable:

第一级：接口偏移量表（找到接口对应的方法表）
┌─────────────────┬───────────────────┐
│  接口引用         │  方法表偏移量       │
├─────────────────┼───────────────────┤
│  Runnable       │  → offset 0       │
│  Comparable     │  → offset 1       │
└─────────────────┴───────────────────┘

第二级：每个接口的方法表（存储具体的方法指针）
┌─────────────────────────────────────┐
│  offset 0 (Runnable 的方法表)        │
│  ┌─────────┬───────────────────┐    │
│  │  run()  │ → Dog.run()       │    │
│  └─────────┴───────────────────┘    │
├─────────────────────────────────────┤
│  offset 1 (Comparable 的方法表)      │
│  ┌──────────────┬──────────────┐    │
│  │  compareTo() │ → Dog.compareTo() │
│  └──────────────┴──────────────┘    │
└─────────────────────────────────────┘

对比一下 Cat 的 itable，结构不同但原理一样：

Cat 的 itable:

第一级：
┌─────────────────┬───────────────────┐
│  Comparable     │  → offset 0       │  ← 注意：顺序与 Dog 不同
│  Serializable   │  → offset 1       │
└─────────────────┴───────────────────┘

第二级：
offset 0 → compareTo() → Cat.compareTo()
offset 1 → (Serializable 没有需要分派的方法)

invokeinterface 的完整查找过程

当 JVM 遇到 invokeinterface Comparable.compareTo() 时，执行以下步骤：

1. 从操作数栈弹出对象引用（objectref）

2. 通过对象头的类型指针，找到对象的实际类（假设是 Dog）

3. 找到 Dog 的 itable

4. 在 itable 的第一级表中，线性搜索目标接口（Comparable）
   ┌─────────────┐
   │  Runnable   │ ← 不是，跳过
   │  Comparable │ ← 找到！偏移量 = 1
   └─────────────┘

5. 用偏移量 1 跳到第二级的 Comparable 方法表

6. 在方法表中找到 compareTo() 的指针 → Dog.compareTo()

7. 执行 Dog.compareTo()

注意第 4 步：线性搜索。这是 invokeinterface 比 invokevirtual 慢的根源——vtable 直接用索引（O(1)），而 itable 需要先遍历接口列表找到目标接口。

invokevirtual vs invokeinterface：性能对比

维度	`invokevirtual`（vtable）	`invokeinterface`（itable）
查找方式	固定索引，直接跳到第 N 项	先线性搜索接口，再找方法
时间复杂度	O(1)	O(K)，K = 实现的接口数
索引稳定性	方法在所有子类中索引相同	接口在不同类中偏移量不同
适用场景	类的实例方法	接口的方法

不过在实际运行中，这个性能差距几乎可以忽略，原因是 JVM 做了大量优化。

JVM 的优化：内联缓存（Inline Cache）

HotSpot JVM 不会每次都傻傻地遍历 itable。它使用一种叫内联缓存（Inline Cache，简称 IC）的技术来加速重复调用：

单态内联缓存（Monomorphic IC）：如果某个调用点（call site）在运行过程中始终调用同一个类的方法，JVM 会缓存这个结果：

// 假设这行代码在循环中执行了 10000 次
animal.speak();

前几次：走完整的 vtable/itable 查找
JVM 发现：每次 animal 都是 Dog → 缓存 (Dog → Dog.speak())
之后的调用：检查类型是不是 Dog？
  是 → 直接调用 Dog.speak()，跳过表查找
  否 → 退化为完整查找（变成多态IC）

多态内联缓存（Polymorphic IC）：如果调用点遇到了少量不同类型（通常 2-4 种），JVM 会缓存所有见过的类型：

缓存：Dog → Dog.speak()
      Cat → Cat.speak()

调用时：检查类型
  是 Dog？→ Dog.speak()
  是 Cat？→ Cat.speak()
  都不是？→ 完整查找

超多态（Megamorphic）：如果调用点遇到的类型太多（超过阈值），JVM 放弃缓存，退化为每次都走完整的 vtable/itable 查找。

哪些方法不走 vtable？

不是所有方法都需要动态分派：

方法类型	调用指令	能否被重写	是否在 vtable 中
`static` 方法	`invokestatic`	❌	❌
`private` 方法	`invokespecial`	❌	❌
`final` 方法	`invokevirtual`	❌	✅（但不会被覆盖）
构造器	`invokespecial`	❌	❌
普通实例方法	`invokevirtual`	✅	✅

Java 编译过程全解析

编译的整体流程

Java 源码 (.java)
      │
      ▼
┌─────────────┐
│ 1. 词法分析   │ ── 把字符流变成 Token 流
│   (Lexing)    │    识别关键字、标识符、运算符
└──────┬──────┘
      │ Token 流
      ▼
┌─────────────┐
│ 2. 语法分析   │ ── 把 Token 流变成 AST（抽象语法树）
│   (Parsing)   │    检查语法结构是否合法
└──────┬──────┘
      │ AST
      ▼
┌─────────────┐
│ 3. 语义分析   │ ── 给 AST 附加类型信息
│  (Analysis)   │    类型检查、访问控制检查、泛型擦除
└──────┬──────┘
      │ 带属性的 AST
      ▼
┌──────────────┐
│ 4. 注解处理    │ ── 执行注解处理器
│  (Annotation)  │    可能生成新的源文件（回到第 1 步）
└──────┬───────┘
      │
      ▼
┌──────────────┐
│ 5. 脱糖       │ ── 将语法糖转为基础结构
│  (Desugar)    │    泛型擦除、自动装箱、for-each 展开
└──────┬──────┘
      │
      ▼
┌──────────────┐
│ 6. 字节码生成  │ ── 将 AST 转为字节码指令
│  (Generate)   │    生成 .class 文件
└──────────────┘

第一阶段：词法分析（Lexical Analysis）

词法分析器也叫"扫描器"（Scanner），它把源代码的字符流转换为Token 流。

比喻：这就像阅读一本书——你先把连续的字母组合成"单词"，然后才能理解句子的意思。词法分析就是"识别单词"的过程。

// 源代码
public class Hello {
    int x = 42;
}

词法分析后变成一个 Token 序列：

[PUBLIC] [CLASS] [IDENTIFIER:"Hello"] [LBRACE]
[INT] [IDENTIFIER:"x"] [ASSIGN] [INTEGER_LITERAL:42] [SEMICOLON]
[RBRACE]

每个 Token 包含两个信息：类型（关键字、标识符、运算符、字面量等）和值。

词法分析阶段能发现的错误：

非法字符（如在标识符中使用 #）
未闭合的字符串字面量
非法的数字字面量（如 0x 后面没有跟十六进制数字）

第二阶段：语法分析（Syntax Analysis / Parsing）

语法分析器（Parser）将 Token 流组织成抽象语法树（Abstract Syntax Tree，简称 AST）——一种树形数据结构，忠实地反映了代码的层次结构。

ClassDecl: "Hello"
├── Modifiers: [public]
└── Members:
    └── VarDecl: "x"
        ├── Type: int
        └── Init: Literal(42)

语法分析阶段能发现的错误就是我们常见的语法错误：

缺少分号
括号不匹配
非法的语句结构（比如 if 后面没有条件表达式）

public class Hello {
    int x = ;  // ❌ 语法错误：表达式缺失
}

编译器在 Token 流 [ASSIGN] [SEMICOLON] 中发现，= 号后面应该跟一个表达式，但直接遇到了分号——这不符合 Java 的语法规则，于是报告语法错误。

第三阶段：语义分析（Semantic Analysis）

符号解析（Symbol Resolution）

int x = 10;
System.out.println(y);  // ❌ 语义错误：y 未声明

编译器在符号表中找不到 y 的声明，报错 cannot find symbol。

类型检查（Type Checking）

Java 是静态类型语言——每个变量都有确定的类型，类型的一致性在编译时就要验证：

String s = "hello";
int n = s;       // ❌ 类型不兼容：String 不能赋给 int
int m = s + 1;   // ❌ 不能把 String 和 int 相加得到 int

类型检查还包括：

方法调用时参数类型是否匹配
返回值类型是否与方法声明一致
类型转换是否合法（向下转型需要显式 cast）

访问控制检查

这就是我们在上一篇「访问修饰符的实现原理」中讲到的编译期检查：

class Other {
    void test() {
        Demo demo = new Demo();
        demo.d;  // ❌ d has private access in Demo
    }
}

编译器从符号表中查到 d 的 access_flags 是 private，而 Other 类不是 Demo 类，因此拒绝编译。

方法重载解析（Overload Resolution）

编译时多态就发生在这个阶段。当你调用一个重载方法时，编译器根据参数的静态类型来决定调用哪一个：

void print(Object obj)  { System.out.println("Object"); }
void print(String str)  { System.out.println("String"); }

print("hello");  // 编译器选择 print(String)——因为 "hello" 的类型是 String

重载解析的算法相当复杂（涉及自动装箱、可变参数、泛型推断等），但核心原则是：选择最具体的匹配。

第四阶段：注解处理

如果代码中使用了注解（如 @Override、@Getter），编译器会在这个阶段执行注册的注解处理器（Annotation Processor）。

@Override 就是一个典型的编译期注解：

class Dog extends Animal {
    @Override
    void speak() { ... }  // 编译器检查 Animal 中是否有同签名方法
}

注解处理器可以：

检查代码是否符合约定（如 @Override 检查方法签名）
生成新的 Java 源文件（如 Lombok 的 @Getter 自动生成 getter 方法）
生成新的资源文件

如果注解处理器生成了新的源文件，编译器会进入新一轮的编译（从词法分析开始），直到没有新文件产生为止。

第五阶段：脱糖（Desugaring）

Java 的很多语法特性都是"语法糖"——让代码更易读写，但不改变底层能力。编译器在这个阶段把语法糖"脱"掉，转换为等价的基础结构：

语法糖	脱糖后
泛型 `List<String>`	类型擦除为 `List`，插入强制转型
自动装箱 `Integer n = 42`	`Integer n = Integer.valueOf(42)`
自动拆箱 `int x = integerObj`	`int x = integerObj.intValue()`
增强 for-each	转为 Iterator 循环或数组下标循环
try-with-resources	转为 try-finally + close()
String 拼接 `"a" + "b"`	`new StringBuilder().append("a").append("b").toString()`
Lambda 表达式	生成 `invokedynamic` + 私有静态方法

以泛型擦除为例：

// 源码
List<String> list = new ArrayList<>();
String s = list.get(0);

// 脱糖后（编译器实际生成的等价代码）
List list = new ArrayList();
String s = (String) list.get(0);  // 编译器插入了强制转型

这就解释了为什么泛型信息在运行时"消失"了——它在编译阶段就被擦除了，只留下了原始类型和必要的强制转型。

第六阶段：字节码生成（Code Generation）

整体比喻：.class 文件就是一份"员工档案"

在深入每个字段之前，先建立一个整体直觉。可以把一个 .class 文件想象成一个类交给 JVM 的**"入职档案"**：

┌──────────────────────────────────────────────────┐
│  .class 文件 = 一份"员工档案"                        │
│                                                      │
│  📌 封面印章（魔数）     → 证明是正规档案，不是伪造的     │
│  📅 适用制度版本（版本号） → JVM 的哪个版本能读懂这份档案  │
│  📒 通讯录（常量池）      → 所有名字、地址的集中登记簿     │
│  🏷️ 权限牌（access_flags）→ public？final？abstract？  │
│  👤 个人信息（this/super） → 我是谁，我爸是谁            │
│  📜 资格证书（interfaces） → 我实现了哪些接口             │
│  💼 财产清单（字段表）     → 我有哪些属性（字段）          │
│  📋 工作手册（方法表）     → 我能做哪些事（方法+字节码）   │
│  📎 附件（属性表）         → 源文件名、调试信息等补充材料   │
└──────────────────────────────────────────────────┘

现在我们逐个字段"翻开"这份档案。

ClassFile 结构定义

ClassFile {
    u4             magic;                // 📌 封面印章
    u2             minor_version;        // 📅 次版本号
    u2             major_version;        // 📅 主版本号
    u2             constant_pool_count;  // 📒 通讯录有多少条
    cp_info        constant_pool[];      // 📒 通讯录内容
    u2             access_flags;         // 🏷️ 权限牌
    u2             this_class;           // 👤 我是谁（指向常量池）
    u2             super_class;          // 👤 我爸是谁（指向常量池）
    u2             interfaces_count;     // 📜 资格证数量
    u2             interfaces[];         // 📜 资格证列表
    u2             fields_count;         // 💼 财产数量
    field_info     fields[];             // 💼 财产清单
    u2             methods_count;        // 📋 技能数量
    method_info    methods[];            // 📋 工作手册
    u2             attributes_count;     // 📎 附件数量
    attribute_info attributes[];         // 📎 附件
}

📌 magic（魔数）—— 封面印章

字节偏移: 0-3
固定值: 0xCA 0xFE 0xBA 0xBE

📅 minor_version + major_version（版本号）—— 适用的制度版本

字节偏移: 4-5（次版本号），6-7（主版本号）

版本号决定了这份档案是按哪个制度版本编写的——也就是需要什么版本的 JVM 才能读懂它。

主版本号	对应 JDK 版本	新增的语言特性
52	Java 8	Lambda、default 方法
55	Java 11	Nestmates、var
61	Java 17	sealed class、模式匹配
65	Java 21	虚拟线程、Record 模式

📒 constant_pool（常量池）—— 通讯录

字节偏移: 8-9（count），之后紧跟常量池条目

常量池是整个 .class 文件的**"通讯录"，也是最大、最复杂**的部分（通常占整个文件的 60% 以上）。

常量池的策略是集中登记、编号引用：

常量池（通讯录）:
  #1  = Utf8      "java/lang/System"      ← 存一次完整的名字
  #2  = Class     #1                       ← "类 System" 引用 #1
  #3  = Utf8      "out"
  #4  = Utf8      "Ljava/io/PrintStream;"
  #5  = NameAndType  #3:#4                 ← "字段 out，类型 PrintStream"
  #6  = Fieldref     #2.#5                 ← "System 类的 out 字段"
  #7  = Utf8      "hello"
  #8  = String    #7                       ← 字符串常量 "hello"
  ...

字节码中使用时，只写编号：
  getstatic #6       // 等价于 System.out
  ldc       #8       // 等价于 "hello"
  invokevirtual #9   // 等价于 PrintStream.println(String)

常量池的主要条目类型：

类型	作用	比喻
`Utf8`	存储原始字符串（类名、方法名等）	通讯录里的"原始姓名"
`Class`	引用一个 Utf8 条目组成类的全限定名	"张三住在 xx 路"（人+地址的组合）
`NameAndType`	组合一个名字和类型描述符	"技能名 + 技能说明"
`Fieldref`	类 + NameAndType = 完整的字段引用	"张三的身高"（人+属性）
`Methodref`	类 + NameAndType = 完整的方法引用	"张三的跑步技能"（人+技能）
`String`	引用一个 Utf8 作为字符串常量	源代码中的 `"hello"`
`Integer`/`Long`/`Float`/`Double`	直接存储数值常量	源代码中的 `42`、`3.14`

🏷️ access_flags（访问标志）—— 权限牌

2 字节的位掩码

这个字段描述的是类本身的修饰符，用位掩码组合表示：

标志	值	含义
`ACC_PUBLIC`	`0x0001`	`public` 类
`ACC_FINAL`	`0x0010`	`final` 类（不可继承）
`ACC_SUPER`	`0x0020`	使用 `invokespecial` 的新语义（JDK 1.2+，几乎所有类都有）
`ACC_INTERFACE`	`0x0200`	接口
`ACC_ABSTRACT`	`0x0400`	抽象类
`ACC_SYNTHETIC`	`0x1000`	编译器生成的类
`ACC_ENUM`	`0x4000`	枚举类

👤 this_class + super_class（当前类与父类）—— 我是谁，我爸是谁

各 2 字节，值是常量池的索引号

这两个字段不直接存储类名，而是存一个常量池索引，指向一个 CONSTANT_Class 条目。

this_class = #8      →  常量池 #8 = Class #10  →  #10 = Utf8 "Hello"
super_class = #2     →  常量池 #2 = Class #4   →  #4  = Utf8 "java/lang/Object"

如果一个类没有显式 extends，super_class 指向 java/lang/Object。只有 Object 类本身的 super_class 是 0（表示没有父类）。

📜 interfaces（接口列表）—— 资格证书

interfaces_count: 2 字节（接口数量）
interfaces[]:    每个元素 2 字节（常量池索引，指向 CONSTANT_Class）

如果类声明了 implements Runnable, Serializable，那 interfaces_count = 2，interfaces[] 里有两个指向常量池的索引。

💼 fields（字段表）—— 财产清单

每个字段用一个 field_info 结构描述：

field_info {
    u2  access_flags;      // 这个字段的修饰符（private/static/final 等）
    u2  name_index;        // 字段名，指向常量池的 Utf8 条目（如 "name"）
    u2  descriptor_index;  // 类型描述符，指向常量池的 Utf8 条目（如 "Ljava/lang/String;"）
    u2  attributes_count;  // 附加属性数
    attribute_info attributes[];
}

注意 name_index 和 descriptor_index 不是直接存字符串，而是存常量池的编号——再一次体现了"通讯录引用"的设计。

类型描述符是 JVM 自己的一套紧凑编码，把 Java 的类型名缩短为尽可能少的字符：

Java 类型	描述符	记忆技巧
`byte`	`B`	Byte
`char`	`C`	Char
`double`	`D`	Double
`float`	`F`	Float
`int`	`I`	Int
`long`	`J`	跳过了 K，用 J（因为 L 被引用类型占了）
`short`	`S`	Short
`boolean`	`Z`	booleaZ（因为 B 被 byte 占了）
`void`	`V`	Void
`String`	`Ljava/lang/String;`	L + 全限定名 + ;
`int[]`	`[I`	[ + 元素描述符
`String[][]`	`[[Ljava/lang/String;`	几维就几个 [

方法的描述符把参数和返回值组合在一起，格式是 (参数描述符)返回值描述符：

Java 方法签名	方法描述符	解读
`void main(String[] args)`	`([Ljava/lang/String;)V`	参数：String 数组；返回：void
`int add(int a, int b)`	`(II)I`	参数：两个 int；返回：int
`String toString()`	`()Ljava/lang/String;`	参数：无；返回：String

📋 methods（方法表）—— 工作手册

方法表的外层结构与字段表类似：

method_info {
    u2  access_flags;      // 方法修饰符
    u2  name_index;        // 方法名（如 "greet"，构造器叫 "<init>"）
    u2  descriptor_index;  // 方法描述符（如 "(Ljava/lang/String;)V"）
    u2  attributes_count;
    attribute_info attributes[];  // 最重要的属性是 Code
}

Code_attribute {
    u2  max_stack;       // 操作数栈的最大深度
    u2  max_locals;      // 局部变量表的槽位数
    u4  code_length;     // 字节码指令的总字节数
    u1  code[];          // ← 字节码指令序列（核心中的核心！）
    u2  exception_table_length;
    exception_info exception_table[];  // 异常处理表（try-catch）
    u2  attributes_count;
    attribute_info attributes[];       // LineNumberTable 等
}

逐个字段解释：

比如计算 a + b：

  iload_1      // 把 a 压入栈      栈：[a]
  iload_2      // 把 b 压入栈      栈：[a, b]
  iadd         // 弹出两个，相加   栈：[a+b]
  istore_3     // 弹出，存到变量 c  栈：[]

这个过程中栈最深到了 2 层 → max_stack = 2

public void test(int x, String s) {
    double d = 3.14;
}

局部变量表：
  slot 0: this          ← 自动占用
  slot 1: x (int)       ← 参数 1
  slot 2: s (String)    ← 参数 2
  slot 3-4: d (double)  ← 局部变量（double 占两个 slot）

max_locals = 5

code[] = [2A, B7, 00, 01, 2A, 2B, B5, 00, 07, B1]

拆解：
  2A       → aload_0            把 this 压栈
  B7 00 01 → invokespecial #1   调用 Object.<init>()，#1 是常量池索引
  2A       → aload_0            把 this 压栈
  2B       → aload_1            把参数 1 压栈
  B5 00 07 → putfield #7        this.name = 参数1，#7 是常量池中的字段引用
  B1       → return             返回

exception_table:
  from=0, to=4, target=7, type=IOException
  // 如果字节码偏移 0~4 之间抛出 IOException，跳到偏移 7 继续执行

📎 attributes（属性表）—— 附件

常见属性及其作用：

属性名	附加在	作用	日常影响
`Code`	方法	存储字节码指令	没有它方法就无法执行
`LineNumberTable`	Code	字节码偏移 → 源码行号的映射	异常堆栈中显示"at Hello.java:5"
`LocalVariableTable`	Code	局部变量的名字和作用域	调试时 IDE 能显示变量名
`SourceFile`	类	源文件名	异常堆栈中显示"at Hello.java"
`ConstantValue`	字段	`static final` 编译期常量的值	`static final int X = 42` 会直接内联
`Exceptions`	方法	`throws` 声明的受检异常列表	编译器检查是否处理了受检异常
`InnerClasses`	类	内部类与外部类的关系	反射能找到内部类
`BootstrapMethods`	类	`invokedynamic` 的引导方法表	Lambda、字符串拼接的底层机制
`NestHost`/`NestMembers`	类	JDK 11+ 嵌套类访问控制	内部类访问外部类 private 成员

全景总结：一个 .class 文件的完整"剖面图"

一个 .class 文件的字节流（从头到尾）：

CA FE BA BE       ← 📌 魔数：证明是合法的 class 文件
00 00 00 3D       ← 📅 版本：次版本 0，主版本 61（Java 17）
00 0F             ← 📒 常量池条目数：15（实际 14 个，#1~#14）
[...常量池...]     ← 📒 14 个常量条目（Utf8、Class、Methodref 等）
00 21             ← 🏷️ access_flags：ACC_PUBLIC | ACC_SUPER
00 08             ← 👤 this_class：#8（常量池中的 "Hello"）
00 02             ← 👤 super_class：#2（常量池中的 "Object"）
00 00             ← 📜 interfaces_count：0（没有实现接口）
00 01             ← 💼 fields_count：1
[...1个字段...]    ← 💼 private String name 的 field_info
00 02             ← 📋 methods_count：2
[...2个方法...]    ← 📋 构造器和 greet() 的 method_info + Code
00 01             ← 📎 attributes_count：1
[...SourceFile...] ← 📎 SourceFile = "Hello.java"

实际验证：用 javap 查看真实 .class 文件

用一个简单的类来验证上面所有内容：

public class Hello {
    private String name;

    public Hello(String name) {
        this.name = name;
    }

    public String greet() {
        return "Hello, " + name;
    }
}

执行 javap -v Hello.class（精简后的输出）：

// ─── 📌📅 魔数 + 版本 ───
Classfile Hello.class
  Compiled from "Hello.java"
  minor version: 0
  major version: 61                              // Java 17

// ─── 🏷️👤 access_flags + this/super ───
public class Hello                               // ACC_PUBLIC
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER

// ─── 📒 常量池 ───
Constant pool:
   #1 = Methodref    #2.#3       // Object.<init>:()V
   #2 = Class        #4          // java/lang/Object
   #3 = NameAndType  #5:#6       // <init>:()V
   #4 = Utf8         java/lang/Object
   #5 = Utf8         <init>               // 构造器的固定名字
   #6 = Utf8         ()V                  // 方法描述符：无参，返回 void
   #7 = Fieldref     #8.#9       // Hello.name:Ljava/lang/String;
   #8 = Class        #10         // Hello
   #9 = NameAndType  #11:#12     // name:Ljava/lang/String;
  #10 = Utf8         Hello
  #11 = Utf8         name
  #12 = Utf8         Ljava/lang/String;   // String 的类型描述符
  ...

// ─── 💼 字段表 ───
{
  private java.lang.String name;
    descriptor: Ljava/lang/String;            // 类型描述符
    flags: (0x0002) ACC_PRIVATE               // 访问标志

// ─── 📋 方法表：构造器 ───
  public Hello(java.lang.String);
    descriptor: (Ljava/lang/String;)V         // 参数 String，返回 void
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2          // 栈深 2，局部变量 2 个
         0: aload_0                           // 把 this 压栈
         1: invokespecial #1                  // 调用 Object.<init>()
         4: aload_0                           // 把 this 压栈
         5: aload_1                           // 把参数 name 压栈
         6: putfield      #7                  // this.name = name
         9: return
      LineNumberTable:
        line 4: 0                             // 字节码偏移 0 → 源码第 4 行
        line 5: 4                             // 字节码偏移 4 → 源码第 5 行

// ─── 📋 方法表：greet() ───
  public java.lang.String greet();
    descriptor: ()Ljava/lang/String;
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: getfield      #7                  // 读取 this.name
         4: invokedynamic #13, 0              // 字符串拼接
         9: areturn                            // 返回 String
}

// ─── 📎 属性表 ───
SourceFile: "Hello.java"

为什么编译器能发现错误？

回到最初的问题：我们写了不符合规范的代码，编译器为什么能识别出来？

答案就在编译过程的每个阶段——每个阶段都有自己的"检查职责"：

错误类型	发现阶段	示例
非法字符	词法分析	`int # = 1;`
未闭合的字符串	词法分析	`"hello`
缺少分号	语法分析	`int x = 1`
括号不匹配	语法分析	`if (x > 0 {`
变量未声明	语义分析（符号解析）	`System.out.println(y);`
类型不兼容	语义分析（类型检查）	`int x = "hello";`
访问权限违规	语义分析（访问控制）	`obj.privateField`
方法不存在	语义分析（符号解析）	`obj.nonExist()`
@Override 无效	注解处理	签名不匹配的 @Override

比喻：编译器就像一个严格的编辑审稿流程。词法分析是校对员，检查有没有错别字（非法字符）；语法分析是语法编辑，检查句子结构是否通顺（语法正确）；语义分析是主编，检查文章逻辑是否自洽（类型安全、变量存在、权限合法）。只有通过了所有编辑的审核，文章（字节码）才能出版（生成 .class 文件）。

IDE 是怎么做到"实时报红"的？

现代 IDE（如 IntelliJ IDEA、VS Code）能在你打字的同时就标出错误，这不是因为它在后台不断编译你的代码，而是因为 IDE 内部运行了一个增量编译器：

IDE 维护着整个项目的符号表和AST
当你修改一个文件时，IDE 只重新解析修改的部分（增量更新 AST）
对修改的部分重新进行语义分析（类型检查、符号解析等）
将检测到的错误实时显示为红色波浪线

这就是为什么 IDE 的错误提示比 javac 更快——它不需要从头编译整个文件，只需要增量更新受影响的部分。

编译时多态 vs 运行时多态：完整对比

维度	编译时多态（重载）	运行时多态（重写）
机制	方法签名唯一确定	虚方法表动态查找
依据	参数的静态类型	对象的实际类型
字节码	方法引用已确定	`invokevirtual` 延迟解析
确定时机	编译时	运行时
性能	无额外开销	vtable 索引查找（O(1)）
典型场景	`println(int)` vs `println(String)`	`animal.speak()` → Dog or Cat

一道经典架构问题

class Parent {
    void show(Parent p) { System.out.println("Parent-Parent"); }
    void show(Child c)  { System.out.println("Parent-Child"); }
}

class Child extends Parent {
    @Override
    void show(Parent p) { System.out.println("Child-Parent"); }
    void show(Child c)  { System.out.println("Child-Child"); }
}

Parent p = new Child();
p.show(new Child());  // 输出什么？

分步分析

第一步：编译时——重载解析（选方法签名）

编译器只看 p 的静态类型 Parent，在 Parent 类中找到两个候选方法：

show(Parent p) — 参数类型 Parent
show(Child c) — 参数类型 Child

编译后的字节码：

invokevirtual Parent.show(Child)   // 方法签名已确定为 show(Child)

第二步：运行时——vtable 分派（选方法实现）

p 的实际类型是 Child。JVM 在 Child 的 vtable 中查找 show(Child) 的条目。

关键问题：Child.show(Child c) 是不是对 Parent.show(Child c) 的重写？

是的。 判断方法重写只看两个条件：

方法名相同 — 都是 show ✅
参数列表相同 — 都是 (Child c) ✅

所以 Child 的 vtable 是这样的：

Child 的 vtable:
┌──────────────┬─────────────────────────────────┐
│  show(Parent) │ → Child.show(Parent)            │ ← @Override 重写了
│  show(Child)  │ → Child.show(Child)             │ ← 也重写了（签名相同）
└──────────────┴─────────────────────────────────┘

JVM 通过 vtable 索引找到 show(Child) → Child.show(Child) → 执行。

输出：Child-Child

变种题：真正"不构成重写"的场景

如果把 Child 的 show 方法参数类型改一下，情况就不同了：

class Parent {
    void show(Parent p) { System.out.println("Parent-Parent"); }
}

class Child extends Parent {
    // 注意：参数类型是 Child，不是 Parent
    // 这不是重写，而是重载！
    void show(Child c) { System.out.println("Child-Child"); }
}

Parent p = new Child();
p.show(new Child());  // 输出什么？

分析：

编译时：p 的静态类型是 Parent，编译器在 Parent 中只找到一个方法 show(Parent)。虽然 Child 类中有 show(Child)，但编译器不看 Child 的方法（因为 p 的静态类型是 Parent）→ 选择 show(Parent)
运行时：查找 show(Parent) 在 Child 的 vtable 中的条目。Child 没有重写 show(Parent)（它定义的是 show(Child)，参数类型不同，不构成重写）→ 仍然调用 Parent.show(Parent)

输出：Parent-Parent

这个变种题才是重载和重写不构成覆盖的经典场景：Child.show(Child) 和 Parent.show(Parent) 参数类型不同，它们是重载关系，不是重写关系。

为什么和经典题结果不同？ 初读这道变种题，很容易联想到经典题的结果 Child-Child，从而以为这里也应该输出 Child-Child。混淆的根源在于两题的 Parent 类结构不同：

经典题变种题

Parent 有哪些方法 show(Parent) 和 show(Child) 两个只有 show(Parent) 一个

编译时选哪个签名两个候选中选最具体的 show(Child) 只有一个候选，只能选 show(Parent)

Child 是否重写了被选中的签名重写了 show(Child) → vtable 指向 Child 实现未重写 show(Parent) → vtable 继承 Parent 实现

最终输出 Child-Child Parent-Parent

变种题的陷阱正在第一步：编译器只看 p 的静态类型 Parent，根本"看不见" Child.show(Child) 这个方法。既然字节码里写的是 invokevirtual Parent.show(Parent)，运行时 vtable 自然也只找 show(Parent) 的条目——此时 Child 没有重写它，调用回退到 Parent 的实现，输出 Parent-Parent。

	经典题	变种题
`Parent` 有哪些方法	`show(Parent)` 和 `show(Child)` 两个	只有 `show(Parent)` 一个
编译时选哪个签名	两个候选中选最具体的 `show(Child)`	只有一个候选，只能选 `show(Parent)`
`Child` 是否重写了被选中的签名	重写了 `show(Child)` → vtable 指向 Child 实现	未重写 `show(Parent)` → vtable 继承 Parent 实现
最终输出	`Child-Child`	`Parent-Parent`

核心要点

判断是否构成重写，只看方法签名（方法名 + 参数列表），不看 @Override 注解、不看返回值类型（协变返回除外）。编译器用静态类型做重载解析选签名，JVM 用实际类型做 vtable 查找选实现——两步缺一不可。

总结

                编译阶段                           运行阶段
                  │                                  │
    ┌─────────────┴──────────────┐      ┌───────────┴───────────┐
    │                            │      │                       │
词法分析 → 语法分析 → 语义分析      invokevirtual 执行时
    │         │         │              │
 非法字符  语法错误  类型检查         对象实际类型
 未闭合串  缺分号   符号解析          → vtable 索引查找
                    访问控制          → 调用正确的方法实现
                    重载解析
                      │
              （编译时多态在此确定）    （运行时多态在此确定）

编译时多态（重载）：编译器根据参数的静态类型选择方法签名
运行时多态（重写）：JVM 根据对象的实际类型在 vtable 中查找方法实现
编译器发现错误：六个编译阶段层层过滤，从字符到语法到语义全方位检查
vtable 是多态的核心数据结构，用数组索引实现 O(1) 的方法查找