jvm通过vtable在运行时动态分派虚方法调用：每个类的vtable按声明顺序存储可重写实例方法的入口地址，invokevirtual指令根据对象实际类型查vtable索引跳转；final、static、private方法不入vtable，直接静态绑定。
Java方法调用怎么找到具体实现的
Java里不是所有方法调用都直接跳转到目标字节码——尤其是重写后的方法。JVM靠每个类的vtable（虚拟方法表）在运行时决定调用哪个版本。它本质是一张函数指针数组，按声明顺序存放该类所有可被重写的实例方法（即非private、非static、非final的public/protected方法），每个槽位指向当前类对该方法的实际实现。
比如Animal有makeSound()，子类Dog重写了它，那么Dog的vtable里这个位置就存Dog.makeSound的入口地址，而不是父类的。
-
vtable在类加载的“准备”和“解析”阶段生成，不是每次调用才查 - 只有虚方法（virtual method）才进
vtable；static、private、final方法走静态绑定，压根不进表 - 接口方法不进类的
vtable，而是走另一套itable机制（别混淆）
为什么加了final就不再走vtable查找
加final不是“禁止重写”那么简单，它是向JVM发出明确信号：这个方法的实现确定不变。JVM于是跳过vtable间接寻址，直接内联或生成硬编码跳转——省掉一次内存读取+指针解引用，对高频调用有实际收益。
反例：StringBuilder.append(char)是final，所以append('a')几乎等价于直接跳转；而如果它没被标记final，哪怕当前类型是StringBuilder，JVM仍得查它的vtable确认有没有被子类覆盖（尽管实际上没有子类）。
立即学习“Java免费学习笔记（深入）”；
- 不是所有
final方法都会被内联，但一定不进vtable - 子类继承
final方法时，该方法不会出现在子类vtable中——连占位都不给 - 注意：
private方法也不进vtable，但原因不同——它连继承都没有，根本不存在“重写”语义
从字节码看invokevirtual怎么触发vtable查找
invokevirtual指令本身不带目标地址，只携带符号引用（如"Animal.makeSound:()V"）。真正执行时，JVM根据栈顶对象的实际类型（而非变量声明类型），取出其类元数据里的vtable，再按方法在类声明中的索引定位槽位，最后跳转到槽位存的地址。
这意味着：即使你写Animal a = new Dog(); a.makeSound();，字节码仍是invokevirtual Animal.makeSound，但运行时查的是Dog的vtable。
- 如果符号引用的方法在当前类
vtable中未定义（比如调用的是父类新增方法，而子类还没重新编译），会抛NoSuchMethodError - 字段访问（
getfield）永远不查vtable——字段不支持多态，只看声明类型 - Android Dalvik/ART早期用类似机制，但ART 7.0+引入去虚拟化（devirtualization）优化，部分
invokevirtual会被AOT编译器直接替换成invokestatic
vtable大小和内存开销容易被忽略
每个类的vtable大小 ≈ 该类所有可重写方法数 × 指针宽度（通常8字节）。表面看不大，但叠加泛型擦除、大量小工具类、以及Spring等框架动态生成的代理类（如CGLIB子类），vtable总内存可能悄然上涨——尤其在容器环境内存敏感场景。
更隐蔽的是：只要一个类存在子类，它的vtable就不能被完全优化掉；哪怕子类只重写一个方法，父类vtable仍需保留全部槽位（空槽填父类实现地址）。
- 用
jhsdb jmap --heap看不出vtable内存，它属于元空间（Metaspace）里的类结构体，需结合jhsdb clhsdb或JFR事件分析 - 频繁反射调用
Method.invoke()不会走vtable，但会触发JVM内部的method resolution缓存，和vtable无关 - 如果你在写高性能基础库，避免无意义的继承链——每层都增加
vtable冗余和查找深度
