方法重写本质是jvm运行时通过invokevirtual指令查vtable实现的动态分派，源码中@override仅触发编译校验，字节码只存符号引用，执行时才根据对象实际类型定位具体方法入口。

方法重写在源码层面是语法现象，在 JVM 层面则由 invokevirtual 指令驱动，依赖运行时对象的实际类型查虚方法表（vtable）完成分派。理解它，关键不是看 Java 代码怎么写，而是看编译后字节码怎么调、JVM 运行时怎么找。

源码写法只是触发条件，不决定执行路径

Java 源码中写一个 @Override 方法，只是告诉编译器“我打算重写”，但能否真正重写、是否生效，取决于编译期校验和类加载时的验证：

• 编译器（javac）检查签名是否一致：方法名、参数类型（擦除后）、返回类型是否协变；访问修饰符不能更严格；异常声明不能新增受检异常
• 若违反规则，编译直接报错，根本不会生成 invokevirtual 调用
• 即使编译通过，类加载的验证阶段还会再校验一遍；失败则抛 VerifyError，不是运行时报 NullPointerException 或 ClassCastException

字节码里看不到“重写”，只看到 invokevirtual

无论你写了多少层继承、多少个重写版本，javac 编译后对非 private/ static/ final 的实例方法调用，统一生成 invokevirtual 指令——它不绑定具体实现，只记录符号引用（类名+方法名+描述符）：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 例如 animal.speak()，不管 animal 是 Animal 还是 Dog 实例，字节码都是 invokevirtual Animal.speak:()V
• 这个符号引用在类加载解析阶段不会被转成固定地址，留到运行时才确定
• 反编译 class 文件（如用 javap -c）能看到该指令，但看不到“它会跳去 Dog.speak”

JVM 运行时靠 vtable 定位真实方法入口

当解释器或 JIT 执行到 invokevirtual 时，按固定流程查表：

• 从操作数栈取出对象引用，拿到其实际 class 对象（比如 Dog.class）
• 查该 class 的虚方法表（vtable），每个槽位对应一个可重写方法
• 根据方法符号引用计算槽位索引（如 speak() 在 Animal vtable 中是第 5 号槽）
• Dog 类的 vtable 第 5 号槽已填入 Dog.speak 的字节码入口地址，于是跳过去执行
• 如果 Dog 没重写 speak，该槽仍指向 Animal.speak 入口——这就是“未重写时走父类”的本质

对比其他指令，更能看清 invokevirtual 的特殊性

同为调用指令，它们的绑定时机完全不同：

• invokestatic：调静态方法，编译期就解析成直接引用，类加载时就定死，无多态
• invokespecial：调构造器、private 方法或 super.xxx()，也是解析期绑定，不走 vtable
• invokeinterface：类似 invokevirtual，但查的是 itable（接口方法表），逻辑更复杂（因一个类可实现多个接口）
• 只有 invokevirtual 和 invokeinterface 支持“一个调用点、多个可能实现”，而重写正是通过 invokevirtual 实现的

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南