方法表是HotSpot VM中每个类（非接口）的Klass持有的哈希表，以方法签名为键、Method指针为值，仅用于invokevirtual/invokeinterface的符号解析；不参与栈帧调用，查的是接收者实际类型的方法表，并沿继承链向上查找。
方法表在JVM里到底存什么
方法表（MethodTable）不是Java源码里的概念，而是HotSpot VM内部对类元数据的组织方式——它本质是一张以方法签名（name + descriptor）为键、指向Method*指针的哈希表，用于快速定位虚方法实现。
注意：它不参与字节码执行时的栈帧调用，只服务于invokevirtual和invokeinterface指令的符号解析阶段。真正决定“调哪个方法”的，是运行时查这张表+类型检查+继承链遍历的组合逻辑。
- 每个
Klass*（类元数据）持有一个MethodTable，但接口类没有，只有实现类有 -
MethodTable大小在类加载时固定，不可扩容；冲突过多会退化为线性查找，影响多态分派性能 - 静态方法、私有方法、构造器不进方法表，它们走的是直接调用（
invokespecial）路径
invokevirtual怎么靠方法表找对方法
invokevirtual指令执行时，JVM先从操作数栈顶拿到对象引用，再通过其Klass*找到对应的方法表，然后用当前调用点的符号引用（如"java/lang/Object.toString()Ljava/lang/String;"）查表。
关键点在于：查的是**接收者实际类型**的方法表，不是编译时类型。所以哪怕变量声明为Object o = new ArrayList()，查的仍是ArrayList的MethodTable。
- 如果表中没命中，说明该类没重写这个方法，JVM会沿
super_klass链向上查，直到java/lang/Object - 如果查到的是
abstract方法（比如接口默认方法未被覆盖），会抛AbstractMethodError - 方法表查不到+继承链走到头还没结果 →
IncompatibleClassChangeError（常见于热替换后旧方法签名残留）
为什么final方法不走方法表查找
final方法（含private、static、<init></init>）在字节码层面就绑定到具体Method*地址，编译期就能确定目标，跳过运行时方法表查找。
这不只是优化——更是语义要求：final意味着不可重写，也就不存在“多态分派”一说。JVM连方法表都懒得去翻，直接生成硬编码跳转。
-
javac对final实例方法仍生成invokevirtual指令，但JIT编译时会内联或转成invokespecial - 子类里声明同名
final方法不算重写，而是独立方法；父类final方法在子类方法表里根本不会出现 - 反射调用
final方法时，走的是统一的Reflection::invoke_method路径，绕过方法表逻辑
看方法表内容得用HSDB或jhsdb，别信jstack
jstack只显示线程栈和锁信息，完全不暴露方法表结构。jhsdb jmap --histo也只统计对象数量。真要看某个类的方法表内容，必须进HotSpot调试环境。
实操路径：启动JVM加-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（可选），用jhsdb hsdb attach后，在Klass视图里展开method_table字段，点开每个Method*看name_and_sig和access_flags。
- 方法表项顺序≠源码声明顺序，也不等于vtable索引，它是哈希散列后的布局
- 同一个方法签名在不同子类的方法表里，
Method*地址一定不同（除非是继承未重写的父类方法） - 动态代理生成的类（如
$Proxy1）方法表里只有hashCode/toString/equals和接口方法，没有InvocationHandler字段——那是实例对象的数据部分
invokevirtual都是现场查+沿继承链爬。最容易被忽略的是：方法表大小在类加载时固化，一旦填满就降级为O(n)查找——而这个“满”的阈值（默认32）没法调，只能靠减少无意义的重载或拆分大类来缓解。 
