字节码校验器在类加载的链接阶段中的验证子阶段工作，即classloader调用defineclass()后、resolveclass()前触发；它静态扫描字节码，确保类型匹配、栈平衡与控制流可达，失败抛出verifyerror。
字节码校验器在类加载的哪个阶段工作
它不是独立运行的工具，而是 ClassLoader 在 defineClass() 后、resolveClass() 前触发的一道强制检查。JVM 不会跳过它——哪怕你用自定义类加载器，只要走标准流程，verify() 就会自动执行。
常见错误现象：java.lang.VerifyError 通常出现在类第一次被主动使用（比如调用静态方法、实例化）时，而不是 Class.forName() 那一刻。这是因为校验是“懒触发”的，但一旦失败，堆栈里会明确标出 VerifyError 和出问题的字节码偏移量。
- 如果你用 ASM 或 Javassist 动态生成类，没做栈映射表（StackMapTable）更新，大概率在这里翻车
- Java 7+ 默认启用更严格的校验（
-XX:+UseSplitVerifier已废弃），旧版生成的 class 文件在新版 JVM 上可能直接拒载 - 校验不检查业务逻辑安全（比如是否删库），只管“结构上能不能不崩溃”：类型匹配、操作数栈平衡、控制流是否可达
校验器实际检查哪些字节码规则
它不跑代码，只静态扫描指令流，核心目标是防止 JVM 运行时状态错乱。重点盯三类问题：
-
aload_0后跟invokevirtual，但栈顶不是对象引用？→ 拒绝 - 方法返回
int却在末尾写areturn？→ 拒绝 - 跳转指令（如
goto）指向非法偏移，或跳进某个指令中间？→ 拒绝
性能影响很小：校验发生在类首次解析，且只做一次。但如果你频繁 defineClass() 大量动态类（比如某些 RPC 框架），校验开销会叠加。可临时关掉（-Xverify:none），但仅限可信环境——关了等于把门锁焊死再拆掉钥匙孔。
立即学习“Java免费学习笔记（深入）”；
为什么有些非法 class 文件能绕过校验
校验器有两套模式：对 bootstrap classloader 加载的类（如 java.lang.*）用“苛刻模式”，对应用类用“宽松模式”。后者允许部分不严谨但实际不会出错的字节码（比如未初始化就读取局部变量），前提是不破坏类型安全。
容易踩的坑：
- 用
javac -target 8编译，却在 Java 17 JVM 上运行——校验器版本升级后可能拒绝旧规范的 class 文件 - 混淆工具（如 ProGuard）若没配好
-adaptclassstrings，可能改坏常量池引用，导致VerifyError: Expecting a stackmap frame - 反射调用
Unsafe.defineAnonymousClass()可跳过校验，但这不是正经路子，JDK 16+ 已标记为 deprecated
如何调试 VerifyError 的具体原因
光看错误信息不够，得看到底哪条指令坏了。用 javap -v 是最快路径：
javap -v MyClass.class | grep -A 20 "public static void main"
重点关注输出里的 StackMapTable 属性和每条指令的栈帧变化。如果报 Expecting a stackmap frame at branch target，说明跳转目标处缺少栈映射；如果是 Illegal type at constant pool index，就得查常量池索引是否越界或类型错位。
真正麻烦的是：校验器不告诉你“你少写了一条 iconst_0”，只说“栈不平衡”。所以动态生成字节码时，别靠手算栈高，老实用 ASM 的 COMPUTE_FRAMES 模式让框架自动补全。
复杂点在于，校验逻辑随 JDK 版本演进过多次，Java 6 的“旧校验器”和 Java 9 的“新校验器”对同一段字节码可能给出不同结论。别假设“以前能跑现在就一定行”。
