java虚方法表（vtable）在类加载的“准备”和“解析”阶段静态构建，大小固定、结构稳定，存于metaspace随class对象常驻，仅当类卸载时释放；它不动态扩容，所有同类型对象共享同一张表，子类通过覆盖槽位或追加新方法扩展表长，而非运行时 realloc。
虚方法表根本不会动态扩容
vtable 是按类中**可重写方法的声明顺序**一次性分配的连续数组，槽位数量在类字节码解析完成时即确定：
- 父类所有非 static / non-final / non-private 实例方法，按源码顺序填入初始槽位
- 子类重写父类方法 → 覆盖对应槽位地址（不新增槽位）
- 子类新增虚方法 → 追加到表尾（扩展表长仅发生在子类首次加载时，不是“运行中扩容”）
- 同一类的所有对象共享同一张 vtable，不存在 per-object 表或 runtime realloc
类卸载极难触发，vtable 不会“消亡”
vtable 存在于类的元数据区（Metaspace），生命周期与 Class 对象绑定。而 Class 对象只有在满足以下全部条件时才可能被卸载：
- 该类所有实例都已不可达（GC 可回收）
- 加载该类的 ClassLoader 实例本身已不可达
- 该类没有被任何其他类（包括反射、JNI、JVM 内部引用）主动引用
在主流应用服务器（如 Tomcat、Spring Boot）中，系统类和业务类几乎从不卸载；即使使用自定义 ClassLoader 做热替换，也需手动触发并确保无残留引用，vtable 才随 Class 元数据一并释放。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
真正可追踪的运行时行为：虚方法调用的实际分派路径
虽然 vtable 本身静态不变，但你可以通过工具观察 JVM 如何利用它完成动态分派：
- javap -v：查看类的 methods 区域和 constant pool，确认哪些方法被标记为 invokevirtual 指令目标，这是 vtable 构建的输入依据
-
JVM 参数 + PrintAssembly：启动时添加
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=print,*ClassName.methodName，观察热点方法编译后汇编中的间接跳转，例如call qword ptr [rax+0x10]—— 这里的rax+0x10就是查 vtable 某个固定偏移 - JITWatch 或 hsdis 日志：分析 C2 编译器是否对某次 invokevirtual 做了去虚拟化（devirtualization），比如发现调用目标恒为某子类，则直接内联，绕过 vtable 查找
-
JFR（Java Flight Recorder）事件：启用
JVMClassLoading和MethodCompilation事件，可捕获类加载时刻（vtable 创建）和方法首次编译时刻（vtable 首次被实际使用）
接口方法走的是 itable，不是 vtable
如果你观察到“多态行为变化”却找不到 vtable 线索，很可能涉及接口：
- 实现多个接口的类，会额外生成 interface method table（itable）
- itable 结构更复杂（含接口→方法槽映射），且支持多继承语义
- 调用接口方法用
invokeinterface指令，JVM 查 itable 而非 vtable - 可通过
javap -v查看Interfaces:和InterfaceMethodTable:区域确认
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
