OpenJDK类验证分三阶段：一是文件格式验证，检查魔数、版本、常量池等二进制合规性；二是元数据与字节码验证，确保继承关系、类型安全及控制流正确；三是符号引用验证，确认类、字段、方法存在且可访问。
OpenJDK类验证阶段检查哪些内容
OpenJDK的类验证（Verification）不是可配置或可跳过的步骤，而是JVM在连接阶段自动触发的强制安全检查。它不依赖源码，只基于.class文件字节码结构和语义规则进行静态分析。验证失败会直接中断类加载，并抛出特定异常——这意味着你看到ClassFormatError、VerifyError或IncompatibleClassChangeError时，问题一定出在字节码本身，而非Java源码逻辑。
文件格式验证：魔数、版本、常量池是否合规
这是验证的第一道关卡，纯二进制层面扫描，不涉及任何Java语义。
- 魔数必须为
0xCAFEBABE，否则抛出ClassFormatError - 主次版本号需在当前JVM支持范围内（例如OpenJDK 21不接受class版本66+）
- 常量池项不能有非法UTF-8编码、损坏的符号引用索引或循环引用
- 字段/方法表结构需对齐，访问标志不能矛盾（如接口中声明
static方法）
这一层失败通常来自手动修改字节码、使用不兼容的编译器（如用JDK 22编译后在JDK 17上运行），或反编译后再编译产生的损坏class文件。
元数据与字节码验证：继承关系与类型安全能否成立
这一步开始做语义分析，也是最容易被误判为“代码写错了”的环节。
- 检查是否继承
final类、覆盖final方法、抽象类是否实现全部抽象方法 - 对每个方法执行控制流模拟，确保操作数栈不会下溢/溢出，局部变量类型始终一致
- 验证
checkcast、instanceof等指令的目标类型在继承链上合法 - 分支跳转目标必须落在有效指令边界，不能指向中间字节
常见诱因包括：ASM或Byte Buddy动态生成字节码时未正确更新StackMapTable；使用旧版javac（如JDK 7）编译但启用了Java 8+的-target参数；或混淆工具（ProGuard/R8）破坏了类型推断所需元数据。
符号引用验证：类、字段、方法是否存在且可访问
这一步发生在解析阶段前后，决定符号引用能否成功转为直接引用。
- 引用的类能否被当前类加载器加载（注意双亲委派被破坏时的
NoClassDefFoundError前置条件） - 调用的字段/方法是否满足访问控制：跨包访问
default成员、子类访问父类private字段、对final字段非构造器内赋值 - 接口方法是否被实现类正确定义（签名一致、返回类型协变合法）
这个阶段的问题往往在运行时才暴露为IllegalAccessError或IncompatibleClassChangeError，尤其多见于模块化（JPMS）环境下跨模块反射调用，或使用--add-opens不足时的私有API访问。
真正容易被忽略的是：验证全程不读取源码、不执行任何用户代码，也不受@SuppressWarnings影响；它只认字节码。所以当你遇到VerifyError，别急着改Java逻辑——先用javap -v看字节码结构，再查对应OpenJDK版本的verifier.cpp源码路径，确认是哪一类检查被触发。
