invokevirtual 指令实现方法覆盖，其通过运行时查虚方法表（vtable）动态分派，字节码中仅含声明类型符号引用，不绑定具体实现类。
方法覆盖在字节码里靠 invokevirtual 指令触发，不是靠指令本身“知道”覆盖关系
Java 编译器不会为子类覆盖的方法生成特殊指令；invokevirtual 是唯一用于调用实例方法的字节码（除私有/构造/静态外），它把「具体调哪个实现」完全推迟到运行时。JVM 在执行时查虚方法表（vtable），根据对象实际类型找对应方法入口——这才是覆盖生效的本质。
常见错误现象：javap -c 看到父类引用调子类方法，字节码里却只有 invokevirtual SomeClass.someMethod，误以为“编译期就绑定了子类”。其实这里写的只是符号引用，解析发生在类加载阶段，而真正分派在运行时。
- 编译期只校验该方法是否在声明类型中可访问、签名是否匹配，不检查实际实现类
-
invokevirtual的操作数是常量池索引，指向一个Methodref，它记录的是“声明类型 + 方法名 + 描述符”，不是运行时类型 - 如果目标方法被标记为
final或是private，编译器会直接换成invokespecial，那就彻底失去动态分派能力
为什么 invokevirtual 不直接写子类方法名
因为 Java 支持多态变量：同一个 invokevirtual 指令，在不同执行路径下可能调用不同子类的实现。比如 List list = Math.random() > 0.5 ? new ArrayList() : new LinkedList(); list.add("x");，字节码里只会有一条 invokevirtual java/util/List.add，但 JVM 必须在每次执行时判断 list 实际是什么类型。
这带来两个关键影响：
立即学习“Java免费学习笔记（深入）”；
- 性能上：现代 JVM 通过内联缓存（IC）和类型推测优化
invokevirtual分派，但如果类型太发散（如上百个实现类），仍可能退化为查表，拖慢热点路径 - 兼容性上：只要子类方法签名不变，哪怕新增几十个子类，原有字节码无需重编译也能正常运行——这是多态可扩展性的底层保障
- 反编译工具（如 JD-GUI）显示“调用了子类方法”，其实是根据运行时行为反推的，原始字节码里根本没出现子类名
invokevirtual 解析失败的典型场景
解析发生在类加载的「解析阶段」，不是运行时。一旦失败，抛 IncompatibleClassChangeError 或其子类（如 NoSuchMethodError），且只在首次执行该指令时触发。
- 父类方法被删了，但子类还试图覆盖它：编译能过（子类编译时父类存在），运行时报
java.lang.NoSuchMethodError: Parent.method() - 父类方法从
public改成protected：子类覆盖方法变成非法，解析时抛IllegalAccessError - 子类重写了方法但改了返回类型（协变返回除外）：编译报错，根本进不了字节码；但如果用字节码编辑器硬塞进去，解析阶段会拒绝加载
- 模块系统限制：如果子类在模块 A，父类在模块 B 且未导出包，
invokevirtual解析会因封装失败而抛NoSuchMethodError
怎么验证某个调用确实是 invokevirtual 分派
别信 IDE 提示或反编译结果，直接看字节码最可靠。用 javap -v 查指令和常量池即可确认。
示例：对 obj.toString()，输出中会出现：
10: invokevirtual #4 // Method java/lang/Object.toString:()Ljava/lang/String;
注意 #4 是常量池索引，后面跟着的 Method java/lang/Object.toString 表明符号引用写的是 Object 类型，哪怕 obj 是 String 实例。
- 如果看到
invokespecial，说明是构造器、私有方法或super.xxx()显式调用，不是覆盖分派 - 如果看到
invokestatic或invokeinterface，那跟覆盖无关：invokeinterface虽也动态分派，但走的是接口方法表（itable），逻辑独立 - 想看 vtable 内容？JVM 不暴露这个结构。可用
-XX:+PrintVtables（仅 HotSpot debug 版）观察，但生产环境不可用
invokevirtual 这一条指令和它背后一整套运行时机制。很多人卡在“为什么断点进了子类方法，字节码却写着父类名”，问题不在代码，而在没意识到：字节码从不撒谎，它只写契约，不写实现。 
