Java方法重写触发动态绑定需满足：非private/static/final的实例方法，且子类有签名一致的重写方法，JVM运行时通过vtable查表调用。
Java 方法重写怎么触发动态绑定
动态绑定不是靠关键字或配置开关决定的，而是由 JVM 在运行时根据实际对象类型自动选择方法版本。只要满足「非 private / static / final 修饰的实例方法」+「子类中存在签名一致的重写方法」，调用时就会走虚方法表（vtable）查表跳转。
常见错误现象：NullPointerException 后才发现调用的是父类方法——其实是因为子类对象没真正创建（比如构造器里提前调用 this.method()，此时子类字段还没初始化，但方法已可被重写）；或者误把 static 方法当成可重写，结果编译期就绑定了父类版本。
- 必须是实例方法：
private、static、final方法不进虚方法表，编译期静态绑定 - 重写要求严格签名一致：返回类型需协变（子类可更具体），但参数类型、数量、顺序必须完全相同
- 构造器中调用可重写方法很危险：子类字段为
null或默认值，但子类重写的方法已被执行
虚方法表（vtable）在什么时机生成
vtable 是类加载阶段由 JVM 自动生成的结构，每个类（包括接口，对应 itable）有一张表，存的是该类所有可被动态调用的实例方法的入口地址。它不随对象实例变化，而是类级别共享的元数据。
使用场景：JIT 编译时可能做去虚拟化（devirtualization），比如发现某个 invokevirtual 指令始终只指向一个实现，就直接内联；但前提是逃逸分析确认对象不会被多态使用。所以 vtable 不是“一定慢”，只是保留了多态可能性。
立即学习“Java免费学习笔记（深入）”；
- vtable 在类加载的
linking阶段完成，不是 new 对象时才建 - 子类 vtable 会复制父类条目，再用自身实现覆盖同名方法项（若重写了）
- 接口方法不进类 vtable，走 itable；多个接口同名方法冲突时，由实现类显式选择
invokevirtual 指令如何查 vtable
字节码里的 invokevirtual 是动态绑定的执行指令。它不关心声明类型，而是拿到操作数栈顶对象的实际 class，再索引其 vtable 中对应方法槽位。槽位编号由方法在类定义中的声明顺序决定，与继承链无关。
容易踩的坑：用反射或 MethodHandle 调用时，默认仍是 invokevirtual 行为；但若显式调用 Method.invoke(obj, ...)，性能开销主要在参数封装和安全检查，而非 vtable 查找本身。
- 查表过程是 O(1)：JVM 已预计算好方法在 vtable 中的偏移量
- 如果对象是 null，会在查表前抛
NullPointerException，不是查表失败 - 泛型擦除不影响 vtable：
List<String>.get(int)和List<Integer>.get(int)共享同一个 vtable 条目
为什么 @Override 注解不能保证动态绑定生效
@Override 只是编译器校验工具，它不参与运行时行为。即使加了这个注解，只要方法被 static 或 private 修饰，或者签名有细微差异（比如参数是 int vs Integer），JVM 就不会把它当重写，也不会放进 vtable。
典型错误：把父类方法改成 protected，子类用 public 重写——这合法，能动态绑定；但若父类是 public，子类误写成 protected，编译器会报错，根本过不了编译。
-
@Override不影响字节码，也不改变方法访问性或静态性 - IDE 自动重写常漏掉异常声明：父类方法抛
IOException，子类重写没声明，编译失败 - Lambda 表达式里写的函数式接口实现，走的是
invokedynamic，跟 vtable 无关
