元数据验证管“结构对不对”，检查类继承关系、访问修饰符等静态语义合法性；字节码验证管“运行稳不稳”，分析方法指令流确保栈操作、类型转换等运行时安全。
元数据验证是 Java 类加载过程第二阶段（验证阶段）的关键环节，它在类文件被加载进方法区后、准备使用前，严格检查其结构是否符合 JVM 规范。其中对类继承体系与不合规重载的拦截，不是“运行时逻辑判断”，而是基于字节码层面的静态结构校验——一旦发现违反规范，直接抛出 VerifyError（或其子类如 IncompatibleClassChangeError），类加载中止，根本不会进入初始化或执行阶段。
类继承体系的元数据验证要点
这一部分主要校验 class 文件中 super_class、interfaces[]、access_flags 等字段是否语义合法，且与已加载类型一致：
- 父类不能是 final 类：若当前类声明
extends java.lang.String，而String的 access_flag 含ACC_FINAL，验证失败 - 父类不能是接口：若
super_class指向一个 interface 的常量池索引（tag=7），而非 class（tag=7 是 class，tag=8 才是 interface），则拒绝加载 - 不允许循环继承：A extends B，B extends C，C extends A —— JVM 在解析符号引用时会检测到递归依赖，提前报错
- java.lang.Object 必须是所有类的最终祖先（除它自身外）：若某个类的继承链中跳过 Object 或指向非法类型，验证失败
不合规重载的元数据验证拦截机制
注意：这里“重载”（overload）本身合法，JVM 允许多个同名不同签名的方法共存；真正被拦截的是**违反继承约束的重写（override）伪装成重载**，或**签名冲突导致虚方法表无法构建**的情况：
- 子类中声明的方法若与父类/接口中某方法同名但 descriptor 不兼容（例如返回类型协变不成立、参数类型无法赋值），且又未正确标记为 override，则可能在校验阶段因“方法签名不匹配”被拒
- 当一个类同时实现两个接口，而这两个接口定义了相同简单名称+相同 descriptor 的 default 方法，且该类未提供具体实现——JVM 在验证阶段就发现“无法确定默认分派目标”，抛
IncompatibleClassChangeError - static 方法在子类中“重写”父类同名 static 方法（即隐藏），若 descriptor 不一致（如父类是
static void m()，子类写成static int m()），验证阶段会因方法描述符与符号引用不匹配而失败 - private 方法不可被重写，但若子类定义了同名同签名的 private 方法，属于合法重载；然而若子类试图用
invokespecial调用父类 private 方法，却因常量池中类符号指向错误（比如指向子类自身而非父类），也会在校验时暴露
如何观察这类验证失败
典型现象是类首次主动使用（如 new、static 字段访问、反射等）时抛出异常，且堆栈中无用户代码帧，常见错误类型：
-
java.lang.VerifyError: Bad type on operand stack：多因字节码生成工具（如 ASM、Javassist）改写不当，破坏了 stack map frames -
java.lang.IncompatibleClassChangeError: Expected non-static field ...：字段访问指令与实际字段修饰符不符（如把 static 字段当实例字段用） -
java.lang.NoSuchMethodError或NoSuchFieldError通常发生在链接后期（解析阶段），但若因元数据验证失败导致类未成功加载，后续尝试加载同一类会直接失败，表现类似
调试建议：启用 -XX:+ShowClassLoading -verbose:class 查看类加载顺序；配合 jclasslib 或 javap -v 检查目标类的 Constant pool、Access flags 和 Signature 属性；对于动态生成类，务必确保生成器遵守 JVMS §4.9 的验证规则。
