java方法表（vtable）是jvm内部自动构建的优化结构，用于加速 invokevirtual 的动态绑定；它按签名预排槽位，子类覆盖复用父类索引，不暴露给开发者，final方法和接口方法分别由内联和itable处理。
Java方法表（vtable）不是开发者能直接操作的结构
Java里没有显式的 vtable 概念，它属于JVM内部实现细节，不同厂商（HotSpot、OpenJ9）实现方式也不同。你写 obj.method() 时触发的动态绑定，背后确实依赖类似虚函数表的机制，但这个表由JVM在类加载阶段自动生成并维护，不暴露给Java代码。
常见误解是以为能像C++那样手动查表或干预分派逻辑——不能。所有多态行为都通过字节码指令 invokevirtual 驱动，JVM负责运行时查表、缓存、优化（比如内联缓存、去虚拟化）。
为什么 invokevirtual 查的是方法表而不是类定义本身
因为类继承关系可能很深，每次调用都从父类链逐级搜索效率太低。JVM在类加载时就为每个类构建一张方法表，把当前类及所有可访问的非私有实例方法按签名排序填入，子类覆盖父类方法时，直接在相同槽位（slot）写入自己的实现地址。
这样 invokevirtual 只需根据对象实际类型拿到它的类元数据，再按方法符号引用计算出槽位索引，一次查表就能定位目标方法——快且稳定。
立即学习“Java免费学习笔记（深入）”；
- 同一方法在不同子类的vtable中占据相同索引位置，这是动态绑定正确的前提
- 如果子类新增方法，会追加到表尾；若覆盖父类方法，则复用父类对应槽位
-
final方法不会进入vtable（JVM改用invokestatic或直接内联） - 接口方法走的是另一套机制（itable），和vtable分开管理
容易被忽略的性能影响点：vtable大小与类继承深度
vtable本身内存开销不大，但间接影响明显。继承链越深、重写方法越多，JVM初始化类时构建vtable越耗时；更关键的是，它会影响JIT编译器的优化判断。
例如：一个被频繁调用的 invokevirtual，如果JVM发现该调用点实际只命中1个具体类型（单态），就可能去虚拟化，直接硬编码跳转；但如果继承树太宽（如几十个子类都重写了同一个方法），JIT可能放弃优化，退回到查表逻辑。
- 过度抽象（比如为“可打印”建
Printable接口，又让50个类实现）会增加itable压力，而非vtable - 使用
sealed类限制子类数量，有助于JVM做更激进的去虚拟化 - 避免在热点路径上对高度多态的对象反复调用同一方法，考虑用策略模式+枚举分发替代深层继承
调试时看不到vtable，但能观察它的效果
你可以用 javap -v 看字节码里的 invokevirtual 指令和符号引用，也能用JVM参数 -XX:+PrintAssembly（需hsdis）看JIT后是否已去虚拟化。但vtable本身不出现在任何Java或标准工具输出里。
真正容易踩的坑，是误以为“重写了方法就一定走子类逻辑”，而忽略了静态分派规则：
- 重载（overload）是编译期决定的，跟vtable无关，看的是变量声明类型
- 重写（override）才走vtable，看的是对象实际类型
- 字段访问不经过vtable——永远按声明类型取值，不存在多态
- 构造器里调用被重写的方法，此时子类字段可能还未初始化，但vtable已就绪，会调到子类方法，造成空指针或默认值问题
这些都不是vtable设计的问题，而是它严格遵循JVM规范的结果。理解它存在，是为了不试图绕过它，也不指望控制它。
