JVM 類別載入器在載入 .class 時會執行嚴格的字節碼驗證，確保類型安全、存取控制、呼叫慣例正確。正常 Java 編譯器輸出的字節碼必通過驗證，但若手工構造或修改字節碼 (如 AOP 框架、動態代理、混淆器、編譯器 Bug)，可能產生非法字節碼導致 VerifyError。本文使用 ObjectWeb ASM 直接生成違反「局部變數表類型一致性」規則的字節碼，演示驗證器如何攔截錯誤。
CAFEBABE、版本號、常量池結構。checkcast, instanceof)Java 原始碼無法表達此邏輯 (編譯器阻擋)，但字節碼層面可構造：
import org.objectweb.asm.*;
import java.io.FileOutputStream;
public class GenBadBytecode implements Opcodes {
public static void main(String[] args) throws Exception {
ClassWriter cw = new ClassWriter(0);
cw.visit(V1_5, ACC_PUBLIC, "BadVerify", null, "java/lang/Object", null);
MethodVisitor mv = cw.visitMethod(ACC_PUBLIC | ACC_STATIC, "foo", "()V", null, null);
mv.visitCode();
// 1. 推入 float 常量 0.0
mv.visitInsn(FCONST_0); // Stack: [float]
// 2. 存入局部變數槽 0 (類型為 float)
mv.visitVarInsn(FSTORE, 0); // Locals[0] = float
// 3. 以 int 類型從槽 0 讀取 (類型衝突！)
mv.visitVarInsn(ILOAD, 0); // Stack: [int] <-- 驗證器在此檢測到類型不匹配
// 4. 再以 int 存回槽 0
mv.visitVarInsn(ISTORE, 0);
mv.visitInsn(RETURN);
mv.visitMaxs(1, 1); // max stack=1, max locals=1
mv.visitEnd();
cw.visitEnd();
byte[] bytes = cw.toByteArray();
new FileOutputStream("BadVerify.class").write(bytes);
System.out.println("Generated BadVerify.class");
}
}
public class BadVerify {
public static void foo();
Code:
0: fconst_0
1: fstore_0
2: iload_0
3: istore_0
4: return
}
$ java BadVerify
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: (class: BadVerify, method: foo signature: ()V) Register 0 contains wrong type
Could not find the main class: BadVerify. Program will exit.
關鍵訊息：Register 0 contains wrong type — 驗證器發現局部變數槽 0 先被標記為 float (fstore_0)，後又被當作 int 讀取 (iload_0)，類型狀態機衝突，拒絕載入類別。
// Java 編譯器直接報錯
void foo() {
float f = 0f;
int i = f; // 編譯錯誤: incompatible types: possible lossy conversion from float to int
// 甚至無法寫出 "同一變數先 float 後 int" 的語法
}
Java 語言層面的靜態類型系統保證了局部變數類型單一性，編譯器將其編譯為字節碼時，自動分配槽位並生成匹配的 store/load 指令對。驗證器是第二道防線，防禦繞過編譯器的惡意/錯誤字節碼。
| 場景 | 典型原因 | 排查手段 |
|---|---|---|
| 動態代理 (CGLIB/ByteBuddy) | 生成子類別時方法簽名不匹配、泛型擦除導致橋接方法衝突 | -XX:+TraceClassLoading、javap -v 對比生成類別 |
| AOP 織入 (AspectJ/Spring AOP) | Advice 修改局部變數表結構、棧幀不平衡 | 輸出織入後 .class 用 asmifier 分析 |
| 混淆器 | 重命名導致簽名不一致、刪除被反射使用的方法 | 保留規則 -keep、逐步啟用混淆選項定位 |
| 熱部署/類別重載 | 新版本類別與舊版本不兼容 (欄位/方法刪除、簽名變更) | 嚴格遵循熱插拔約定、使用 JRebel 等成熟方案 |
| 手工修改 .class | 十六進制編輯器修改常量池、指令 | 極不推薦，改用 ASM 程式化修改 |
ClassWriter(ClassWriter.COMPUTE_FRAMES | ClassWriter.COMPUTE_MAXS)：自動計算棧幀與最大棧/局部變數，減少手工 visitMaxs 錯誤。visitVarInsn (load/store) 的型別前綴 (I/L/F/D/A) 必須與該槽位當前類型一致。CheckClassAdapter.verify(new ClassReader(bytes)) 在測試階段攔截錯誤。ClassLoader 載入並反射調用，CI 流程自動化。JVM 字節碼驗證器是 Java 安全模型的基石，透過類型狀態機追蹤操作數棧與局部變數表，確保字節碼執行不會破壞記憶體安全。ASM 等字節碼操作庫賦予開發者「繞過編譯器」的能力，但也要求開發者自負驗證器責任。理解驗證規則、善用 CheckClassAdapter、編寫載入測試，是開發高質量字節碼操作工具 (編譯器、混淆器、AOP 框架、動態代理) 的必修課。
