Java类验证阶段通过字节码校验机制在连接环节拦截非法操作，包括格式校验（魔数、版本、常量池等）、类型一致性校验（控制流模拟与类型推断）和符号引用访问控制检查，确保运行时安全，失败分别抛出ClassFormatError、VerifyError或IllegalAccessError等。
Java类验证阶段通过严格的字节码校验机制，在类加载的“连接”环节中提前拦截非法或危险操作，防止恶意代码破坏JVM运行时安全边界。它不依赖源码，而是基于字节码结构、类型约束和控制流逻辑进行静态与部分动态分析，确保类在执行前符合Java语言规范与虚拟机安全模型。
字节码格式与结构校验
这是验证的第一步，发生在类加载器将字节码读入内存后、解析前。JVM检查class文件是否符合《Java虚拟机规范》定义的二进制格式：
- 魔数（0xCAFEBABE）是否正确，版本号是否在当前JVM支持范围内
- 常量池中是否存在非法类型、损坏的UTF-8编码或循环引用
- 字段、方法、属性表的结构是否对齐，访问标志是否合理（如接口中出现static方法）
- 类继承关系是否合法（例如final类被继承、重复实现同一接口等）
这一步不涉及语义，仅做“语法级”扫描，失败直接抛出ClassFormatError。
语义与类型一致性校验
核心是确保字节码指令的操作不会破坏JVM运行时类型安全。JVM模拟执行方法的控制流，构建操作数栈与局部变量表的类型状态（即“类型推断”），逐条验证每条指令的合法性：
立即学习“Java免费学习笔记（深入）”；
- 指令参数是否指向有效的常量池索引（如getfield引用的字段是否存在且可访问）
- 方法调用目标是否匹配签名（参数数量、类型、返回值是否兼容）
- 对象创建与强制转换是否满足继承关系（避免ClassCastException在运行时才暴露）
- 局部变量与操作数栈在每个控制流分支合并点是否具有相同类型（保证类型唯一性）
该过程称为“类型检查器”（Type Checker），是验证最耗时也最关键的阶段；若发现冲突，抛出VerifyError。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
符号引用验证与访问控制检查
在解析阶段前后，JVM将常量池中的符号引用（如类名、方法名、字段名）转换为直接引用前，会验证其可访问性：
- 引用的类是否能被当前类加载器成功加载并链接
- 字段/方法是否对当前类可见（private、package-private、protected、public 的访问规则）
- 是否违反封装限制（如子类访问父类private成员、跨包访问default成员）
- 是否尝试对final字段进行非构造器内的写操作
这类检查保障了Java语言层面的封装性和模块化边界，失败时抛出IllegalAccessError或NoSuchFieldError/NoSuchMethodError。
可选：字节码验证器的定制与绕过限制
标准JVM（如HotSpot）默认启用完整验证。但某些场景下可调整：
- -Xverify:none可跳过验证（仅限信任环境，如嵌入式或AOT预编译，生产禁用）
- 自定义类加载器可通过defineClass(String, byte[], int, int, ProtectionDomain)传入安全域，影响后续访问控制判断
- Java 9+ 模块系统强化了验证粒度，模块描述符（module-info.class）本身也需通过结构与依赖合法性校验
注意：任何绕过都意味着放弃JVM核心安全契约，不应在不可信代码中使用。
基本上就这些。验证不是万能的（比如无法阻止逻辑漏洞或反射滥用），但它构成了Java沙箱的第一道坚实防线——让问题暴露在运行之前，而不是崩溃在用户现场。
