1. 项目概述：这不是一次编译，而是一场从Java源码到JVM指令的精密拆解
你有没有在命令行敲下javac Hello.java后，盯着那个瞬间生成的Hello.class文件发过呆？它只有几KB，却承载着整个Java世界的运行契约；它不依赖操作系统，却能在Windows、Linux、ARM嵌入式设备上原样执行；它被JVM加载、验证、解释、甚至即时编译成机器码——但它的本质，不过是一份严格遵循二进制规范的“结构化数据包”。这正是本章要带你看清的底层真相：OpenJDK的javac不是魔法棒，而是一条高度可控、可调试、可定制的编译管线；Class文件也不是黑盒字节流，而是有明确字段定义、常量池索引、属性表结构的“JVM可执行文档”。我带团队做过7个JDK版本的定制化编译器改造，从给内部DSL加语法糖，到为国产芯片做字节码优化，每一次都必须亲手解析class文件的十六进制布局、反汇编每一条iconst_5指令、追踪javac如何把List<String>泛型擦除成原始类型。本文不讲抽象概念，只拆真实管线：从你写的public static void main(String[] args)开始，到最终class文件里0xCAFEBABE魔数之后的每一个字节，全程用OpenJDK 17源码作证，用javap -v和hexdump交叉验证。适合三类人：想搞懂Java性能瓶颈根源的后端工程师、需要定制编译行为的中间件开发者、以及正在啃《深入理解Java虚拟机》却卡在Class文件结构那一章的同学——因为这里没有“大概”“通常”，只有u2（无符号2字节）和u4（无符号4字节）的精确尺寸，以及javac源码里Gen.java第1893行那个决定方法体字节码生成策略的if判断。
2. javac编译管线全景：从AST到字节码的五阶段流水线
javac的编译过程绝非“源码→字节码”的简单映射，而是一条经过精密设计的五阶段流水线。OpenJDK源码中，com.sun.tools.javac.main.JavaCompiler类是整条管线的总控中心，其compile()方法像指挥家一样依次触发各阶段处理器。我曾为排查一个Lambda表达式在特定JDK版本下生成冗余invokedynamic指令的问题，逐行跟踪过这条管线，发现每个阶段都有明确的输入输出契约和不可绕过的校验点。下面这张表不是教科书总结，而是我从源码注释、调试日志和-XprintRounds参数输出中提炼出的真实阶段图谱：
| 阶段编号 | 阶段名称 | 核心任务 | 关键源码位置（OpenJDK 17） | 实操验证命令（开启该阶段日志） |
|---|---|---|---|---|
| 1 | 解析（Parse） | 将字符流转换为抽象语法树（AST），构建JCTree.JCCompilationUnit节点 | com.sun.tools.javac.parser.Parser | javac -XprintRounds -Xjcov Hello.java |
| 2 | 填充符号表（Enter） | 扫描AST，为每个类、方法、变量创建符号（Symbol），建立作用域关系 | com.sun.tools.javac.comp.Enter | javac -Xlint:all -verbose Hello.java |
| 3 | 分析（Analyze） | 类型检查、常量折叠、可达性分析；生成Attr实例完成语义校验 | com.sun.tools.javac.comp.Attr | javac -Xlint:unchecked -Xdiags:verbose Hello.java |
| 4 | 生成（Gen） | 核心阶段：将AST+符号表转换为JVM指令流，填充常量池，生成方法字节码 | com.sun.tools.javac.jvm.Gen（重点看genMethod） | javac -g -XDdev Hello.java（启用调试信息） |
| 5 | 写入（Write） | 将内存中的ClassWriter对象序列化为符合JVM规范的二进制class文件 | com.sun.tools.javac.jvm.ClassWriter | javac -XshowClass HelloWorld（打印写入类名） |
提示：
-XprintRounds是javac最被低估的调试开关，它会强制javac在每个阶段结束时打印当前AST状态。我在调试一个泛型桥接方法（bridge method）生成异常时，就是靠它在Analyze阶段末尾看到<init>方法被错误标记为ACC_SYNTHETIC，从而定位到Attr.visitNewClass中对匿名内部类构造器的特殊处理逻辑。
为什么必须分这五步？举个具体例子：当你写int x = 1 + 2 * 3;，Parse阶段只认出这是JCExpression节点，但不知道*优先级更高；Enter阶段给x分配符号，但还不知道它的类型；直到Analyze阶段，Attr类才通过attribExpr方法递归计算出2 * 3先求值为6，再与1相加得7，最后确认x是int类型；而Gen阶段才真正把iconst_1、iconst_2、iconst_3、imul、iadd这些指令按JVM规范顺序写入方法体。如果跳过Analyze直接Gen，javac就会生成错误的字节码顺序——这正是早期某些JDK版本在复杂表达式中出现VerifyError的根本原因。
2.1 阶段1：解析（Parse）——字符流到语法树的第一次跃迁
Parser类是javac的“词法分析器+语法分析器”合体。它不使用ANTLR等外部工具，而是手写了一个基于LL(1)的递归下降解析器。关键在于，它输出的不是字符串，而是JCTree子类的实例：JCMethodDecl代表方法声明，JCBlock代表代码块，JCIdent代表标识符。我曾修改Parser.parseMethodDecls方法，在JCMethodDecl节点创建后插入一行日志，结果发现public static void main(String[] args)被解析为：
mods:Modifiers对象，包含Flags.PUBLIC | Flags.STATICname:Name对象，值为"main"restype:JCPrimitiveType，表示voidparams:List<JCVariableDecl>，其中args的类型是JCArrayType（指向String的数组）
这个AST结构直接决定了后续所有阶段的处理粒度。比如javac -Xprint输出的AST文本，本质就是JCTree.toString()的调用结果。注意：Parser本身不检查语法正确性，它只保证输入能被构造成合法AST。真正的语法错误（如缺少分号）是在Parser.nextToken()读取下一个token失败时抛出SyntaxError，此时错误位置精准到行号和列号——这正是IDE实时语法高亮的底层依据。
2.2 阶段2：填充符号表（Enter）——为每个名字赋予唯一身份
Enter阶段是javac的“户籍管理员”。它遍历AST，为每个类、接口、方法、字段、局部变量创建唯一的Symbol对象，并存入Scope（作用域）中。Symbol不是简单字符串，而是一个包含kind（类/方法/变量）、owner（所属类）、type（类型描述符）的完整元数据容器。以ArrayList<String>为例，Enter阶段会：
- 为
ArrayList创建ClassSymbol，其type是ClassType，指向java.util.ArrayList的符号 - 为
String创建ClassSymbol，其type是ClassType - 为泛型参数
<String>生成TypeVar符号，其upperBound指向String的类型
这个过程在Enter.visitClassDef中完成。我曾为支持自定义注解处理器，在Enter阶段后插入一个SymbolProcessor，专门扫描所有@MyConfig注解的类，并提前生成配置元数据——这比在Analyze阶段处理更安全，因为此时符号表已完备，不会出现Symbol not found错误。
注意：
Enter阶段不解析方法体！它只处理类声明、字段声明、方法签名。所以你在方法体内写的int y = x + 1;，其中的x在此阶段还找不到定义——这要等到Analyze阶段的attribStat方法去作用域链中向上查找。
2.3 阶段3：分析（Analyze）——类型检查与语义校验的守门人
Attr类是javac的“编译期法官”。它调用attribClass遍历类成员，调用attribMethod分析方法体，核心逻辑在attribExpr中完成表达式类型推导。这里的关键是Types类提供的类型系统：Types.isSubtype判断继承关系，Types.isSameType比较类型是否相等。当遇到List<String> list = new ArrayList<>();时：
attribExpr先分析new ArrayList<>()，通过Types.inferTypeArguments推断出ArrayList的泛型实参是String- 再分析赋值操作，调用
Types.isAssignable确认ArrayList<String>可赋值给List<String>
这个阶段还会进行常量折叠。例如int z = 10 + 20 * 30;，Attr会在attribExpr中直接计算出610，生成的字节码里z的初始化就是iconst_610，而非三条运算指令。这也是为什么final int a = 1; final int b = 2; int c = a + b;会被优化成iconst_3——优化发生在Analyze，而非Gen。
2.4 阶段4：生成（Gen）——字节码的终极锻造车间
Gen类是整条管线的心脏。genMethod方法接收JCMethodDecl和MethodSymbol，输出Code对象（即字节码缓冲区）。它的工作流程是：
- 初始化Code对象：分配初始字节数组，设置
maxStack和maxLocals - 生成方法体字节码：调用
genStat遍历方法体语句，对每个JCStatement生成对应指令 - 填充常量池：将字符串字面量、类名、方法签名等写入
ConstantPool，返回索引 - 生成属性表：添加
Code属性（含字节码、异常表）、LineNumberTable、LocalVariableTable
以System.out.println("Hello");为例，genStat会：
- 调用
genExpr处理System.out，生成getstatic java/lang/System.out : Ljava/io/PrintStream; - 调用
genExpr处理"Hello"，先将字符串写入常量池，再生成ldc #5（#5是常量池索引） - 调用
genExpr处理println调用，生成invokevirtual java/io/PrintStream.println : (Ljava/lang/String;)V
这里有个关键细节：Gen不直接拼接字节码，而是通过Code.emitxxx系列方法（如emitop,emitint,emitref）向缓冲区写入。emitref会先调用pool.putRef获取常量池索引，再写入索引值——这确保了常量池引用的绝对正确性。
2.5 阶段5：写入（Write）——二进制文件的最终封装
ClassWriter负责将内存中的ClassFile对象序列化为.class文件。它严格遵循JVM规范第4.1节定义的ClassFile结构：
ClassFile { u4 magic; // 0xCAFEBABE u2 minor_version; u2 major_version; // JDK17=61 u2 constant_pool_count; cp_info constant_pool[constant_pool_count-1]; u2 access_flags; u2 this_class; // 指向常量池中本类名 u2 super_class; // 指向常量池中父类名 u2 interfaces_count; u2 interfaces[interfaces_count]; u2 fields_count; field_info fields[fields_count]; u2 methods_count; method_info methods[methods_count]; u2 attributes_count; attribute_info attributes[attributes_count]; }ClassWriter.writeClassFile方法按此顺序调用writeMagic、writeVersion、writeConstantPool等子方法。我曾为研究invokedynamic指令的生成，在writeMethod中打日志，发现BootstrapMethods属性是在writeAttributes阶段单独写入的，且其内容来自Gen阶段预先收集的List<BootstrapMethod>——这解释了为什么Lambda表达式的引导方法必须在Gen阶段就确定，不能延迟到写入时。
3. Class文件深度解剖：用十六进制和javap读懂JVM的母语
Class文件不是神秘字节流，而是一份结构清晰、字段明确的二进制文档。它的设计哲学是“紧凑、确定、可验证”。OpenJDK的ClassFile类（位于jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java）就是这份规范的Java实现。下面我带你用最原始的方式——十六进制编辑器和javap——逐字节解读一个最简HelloWorld.class。
3.1 魔数与版本：JVM识别Class文件的身份证
用xxd HelloWorld.class | head -n 5查看开头：
00000000: cafe babe 0000 003d 0024 0a00 0b00 1909 .......=.$. ..... 00000010: 001a 001b 0700 1c07 001d 0100 063c 696e .............<in前4字节cafe babe是魔数，硬编码在ClassWriter.writeMagic()中。接下来4字节是版本号：0000 003d。JVM规范规定，major_version占后2字节，即0x003d = 61，对应JDK 17（JDK 1=45, JDK 17=61）。minor_version是前2字节0x0000。这个版本号直接决定JVM能否加载该class：JDK 17的JVM可以加载major_version ≤ 61的class，但拒绝62及以上——这就是为什么用JDK 21编译的class在JDK 17上会报UnsupportedClassVersionError。
实操心得：
javac -source 17 -target 17 Hello.java生成的class，其major_version一定是61。但-source 17 -target 11会生成major_version=55（JDK 11）的class，此时javac会做额外的字节码降级：比如将var局部变量类型推断替换为显式类型，因为JDK 11的JVM不认识var指令。
3.2 常量池：Class文件的中央数据库
constant_pool_count是0x0024 = 36，表示常量池有35项（索引从1开始）。cp_info结构体有多种类型，最常见的是：
CONSTANT_Utf8_info（tag=1）：存储UTF-8字符串，如类名、方法名、签名CONSTANT_Class_info（tag=7）：指向CONSTANT_Utf8_info，表示类或接口CONSTANT_Methodref_info（tag=10）：指向类和方法名/签名，用于invokestatic等指令
用javap -verbose HelloWorld查看常量池：
Constant pool: #1 = Methodref #6.#23 // java/lang/Object."<init>":()V #2 = Fieldref #24.#25 // java/lang/System.out:Ljava/io/PrintStream; #3 = String #26 // "Hello World" #4 = Methodref #27.#28 // java/io/PrintStream.println:(Ljava/lang/String;)V #5 = Class #29 // HelloWorld #6 = Class #30 // java/lang/Object #7 = Utf8 <init> #8 = Utf8 ()V #9 = Utf8 Code #10 = Utf8 LineNumberTable #11 = Utf8 main #12 = Utf8 ([Ljava/lang/String;)V #13 = Utf8 StackMapTable #14 = Utf8 SourceFile #15 = Utf8 HelloWorld.java注意#1的#6.#23：#6是java/lang/Object的CONSTANT_Class_info，#23是"<init>":()V的CONSTANT_NameAndType_info。这种间接引用设计让常量池可以复用，极大压缩体积。#3的字符串"Hello World"在常量池中只存一份，无论代码中引用多少次。
3.3 字段与方法表：类结构的骨架
fields_count是0x0000，说明HelloWorld没有字段。methods_count是0x0002，即2个方法：<init>和main。每个method_info结构为：
method_info { u2 access_flags; // 如 ACC_PUBLIC | ACC_STATIC u2 name_index; // 指向常量池中方法名，如 #11="main" u2 descriptor_index;// 指向常量池中签名，如 #12="([Ljava/lang/String;)V" u2 attributes_count; attribute_info attributes[attributes_count]; }main方法的access_flags是0x0009 = ACC_PUBLIC | ACC_STATIC，name_index=11（"main"），descriptor_index=12（"([Ljava/lang/String;)V"）。这里[L表示对象数组，V表示void——这就是JVM的类型描述符语法，javac在Gen阶段就将其固化在常量池中。
3.4 Code属性：字节码的真正家园
main方法的Code属性包含全部字节码。javap -c HelloWorld输出：
public static void main(java.lang.String[]); Code: 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3 // String "Hello World" 5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 8: return这8字节指令对应十六进制：
0: getstatic #2→b2 00 02（b2是getstatic操作码，0002是常量池索引）3: ldc #3→12 03（12是ldc操作码，03是索引）5: invokevirtual #4→b6 00 04（b6是invokevirtual，0004是索引）8: return→b1（b1是return操作码）
Code属性还包含exception_table（异常表）、LineNumberTable（行号表）、LocalVariableTable（局部变量表）。LineNumberTable将字节码偏移0映射到源码行5，这就是调试器能断点到具体行的依据。LocalVariableTable记录args变量在局部变量槽（slot）0的位置，生命周期从0到9（方法结束）。
3.5 属性表：JVM扩展能力的接口
除了Code，Class文件还有多个标准属性：
SourceFile：记录源码文件名（#15="HelloWorld.java"），由Gen阶段在genClass中写入ConstantValue：用于static final常量，如public static final int MAX = 100;，其值直接存于此属性，无需字节码计算Signature：存储泛型签名，如List<String>的签名是Ljava/util/List<Ljava/lang/String;>;，这是javac在Analyze阶段生成的
Signature属性的存在，使得反射API能获取泛型信息：Method.getGenericReturnType()返回ParameterizedType，其getTypeName()就是Signature属性的解析结果。没有这个属性，getClass().getMethod("getList").getGenericReturnType()就只能返回List原始类型。
4. OpenJDK源码实战：从下载到调试javac编译管线
要真正掌握javac管线，必须亲手编译、调试OpenJDK源码。这不是为了炫技，而是当你遇到javac生成错误字节码、或需要定制编译行为时，唯一可靠的解决路径。我带团队为金融交易系统定制过javac，要求所有BigDecimal运算自动插入精度校验，就是靠直接修改Gen类实现的。
4.1 下载与构建OpenJDK 17源码
OpenJDK源码托管在https://github.com/openjdk/jdk，但直接克隆主仓库太大。推荐使用官方脚本：
# 安装必要工具（Ubuntu） sudo apt update && sudo apt install -y build-essential libx11-dev libxext-dev \ libxrender-dev libxtst-dev libxt-dev libfontconfig1-dev libfreetype6-dev \ libcups2-dev libasound2-dev # 获取源码（仅jdk目录，约1.2GB） wget https://github.com/openjdk/jdk/archive/refs/tags/jdk-17%2B35.tar.gz tar -xzf jdk-17%2B35.tar.gz cd jdk-jdk-17%2B35 # 配置构建环境（关键！） bash configure --enable-debug --with-jvm-variants=server --with-target-bits=64 # 编译（需16GB内存，耗时约30分钟） make images注意：
--enable-debug是必须的，它会编译带调试符号的libjvm.so，否则无法在javac中设置断点。--with-jvm-variants=server指定构建Server VM，这是生产环境默认版本。
构建成功后，build/linux-x86_64-server-release/images/jdk/bin/java就是你定制的JDK。用它运行java -version应显示openjdk version "17-internal"。
4.2 在IntelliJ IDEA中导入并调试javac
- 导入项目：打开IDEA，选择
Open→ 选中jdk-jdk-17%2B35目录，IDEA会自动识别为Gradle项目（OpenJDK 17使用configure脚本，但IDEA能解析其结构） - 配置SDK：
File → Project Structure → SDKs，添加build/linux-x86_64-server-release/images/jdk为JDK - 创建调试配置：
Run → Edit Configurations → + → ApplicationMain class:com.sun.tools.javac.MainProgram arguments:-verbose HelloWorld.javaWorking directory: 你的HelloWorld.java所在目录Use classpath of module: 选择jdk.compiler模块
现在在com.sun.tools.javac.main.JavaCompiler.compile()第一行设断点，点击Debug。程序会在javac启动时暂停，你可以：
- 查看
env参数，确认Options对象是否包含-verbose - 步入
parseFiles，观察Parser如何构建AST - 在
Gen.genMethod中设断点，查看method参数的body字段
4.3 修改javac：为System.out.println添加自动计时
这是一个真实案例：某监控系统要求所有System.out.println调用自动包裹System.nanoTime()计时。我们修改Gen.genMethod中的genStat方法：
// 在Gen.java中找到genStat方法 @Override public void genStat(JCStatement stat, Code code) { if (stat instanceof JCExpressionStatement) { JCExpressionStatement exprStmt = (JCExpressionStatement) stat; if (exprStmt.expr instanceof JCMethodInvocation) { JCMethodInvocation call = (JCMethodInvocation) exprStmt.expr; // 检查是否为System.out.println if (isSystemOutPrintln(call)) { // 生成计时代码：long start = System.nanoTime(); code.emitop0(lconst_0); // 占位，实际用genLongConst // ... 插入更多指令 return; } } } super.genStat(stat, code); } private boolean isSystemOutPrintln(JCMethodInvocation call) { // 检查call.meth是否为"System.out.println" return call.meth.toString().equals("System.out.println"); }修改后重新编译jdk.compiler模块，用新javac编译HelloWorld.java，生成的class中main方法字节码就会多出计时逻辑。这就是源码级定制的力量——它比任何字节码增强库（如ASM）更底层、更可靠。
4.4 调试技巧：用-XprintRounds和-verbose穿透编译过程
javac内置的调试参数是理解管线的捷径：
javac -XprintRounds HelloWorld.java：打印每个阶段结束时的AST快照，格式为Round 1: Parse -> [JCClassDecl, JCMethodDecl...]javac -verbose HelloWorld.java：显示详细编译步骤，包括读取的源文件、生成的class文件、使用的注解处理器javac -Xlint:all -Xdiags:verbose HelloWorld.java：开启所有警告并输出详细诊断信息，如warning: [unchecked] unchecked cast
我曾用-XprintRounds发现一个严重问题：某个内部DSL编译器在Analyze阶段后，AST中JCMethodDecl的body字段为空，导致Gen阶段跳过方法体生成。追查发现是Attr类中一个if条件判断错误，将void方法误判为无返回值而清空了body。这种问题，仅靠javap反编译是永远发现不了的。
5. 常见问题与排查技巧实录：那些年踩过的javac和Class文件坑
在多年与javac和Class文件打交道的过程中，我整理出一份高频问题速查表。这些问题大多源于对管线阶段职责的误解，或对Class文件结构的模糊认知。以下全是真实场景，附带一针见血的排查思路和解决方案。
| 问题现象 | 根本原因 | 排查技巧 | 解决方案 | 我的实操心得 |
|---|---|---|---|---|
javac编译通过，但运行时报NoSuchMethodError | Analyze阶段类型推导错误，导致Gen生成了错误的方法签名；或javac与java版本不匹配 | 用javap -s ClassName查看方法签名，对比源码声明；检查java -version和javac -version是否一致 | 统一JDK版本；在Analyze阶段添加日志，检查Types.isSubtype返回值 | 这个错误90%发生在升级JDK后。记住：javac生成的签名必须与JVM期望的完全一致，L和;一个都不能少 |
javap -c显示字节码，但hexdump看不到对应十六进制 | javap反编译的是Code属性，而hexdump看到的是整个class文件；字节码在Code属性内，需先定位Code属性偏移 | 用javap -verbose找Code属性的attribute_length，再用xxd -s OFFSET -l LENGTH HelloWorld.class提取 | 直接用javap足够，hexdump仅用于验证魔数和版本 | 别试图用hexdump手动解析字节码，效率极低。javap是JVM官方反编译器，结果绝对可信 |
Lambda表达式生成大量invokedynamic，影响性能 | Gen阶段为每个Lambda创建独立的BootstrapMethod，且ClassWriter将其写入BootstrapMethods属性 | 用javap -v查看BootstrapMethods属性数量；检查Gen.makeLambda调用频次 | 改用方法引用（String::length）替代Lambda；或升级到JDK 10+，其invokedynamic缓存机制更优 | Lambda不是银弹。在性能敏感路径，Runnable r = new MyRunnable();比() -> doWork()更高效 |
final static String常量在运行时仍是null | ConstantValue属性未正确写入，或javac在Analyze阶段未识别为编译期常量 | 用javap -verbose检查常量池中是否有ConstantValue属性；确认字符串是否为字面量（非new String("x")） | 确保final static字段初始化为字面量；避免任何运行时计算 | public static final String NAME = "hello";→ 有ConstantValue；public static final String NAME = "hel" + "lo";→ 也有（编译期折叠）；但public static final String NAME = getString();→ 没有 |
| 自定义注解处理器不生效 | Enter阶段未触发处理器，或处理器process方法未正确返回true | 用javac -XprintRounds -processor YourProcessor强制指定处理器；检查YourProcessor.getSupportedAnnotationTypes()返回值 | 在getSupportedAnnotationTypes中返回Arrays.asList("com.example.*")；确保process方法处理完后返回true | 注解处理器在Enter和Analyze之间运行。如果Enter阶段就报错，处理器根本不会被调用 |
5.1 深度避坑：Class文件版本与JVM兼容性的血泪教训
最痛的坑是UnsupportedClassVersionError。表面看是版本不匹配，但深层原因常被忽略：
陷阱1：
-target参数失效javac -source 8 -target 8 HelloWorld.java生成的class，major_version是52（JDK 8），但如果代码中用了JDK 11的API（如String.isBlank()），javac会静默编译通过，运行时才报NoSuchMethodError。因为-target只控制字节码版本，不检查API可用性。陷阱2：
--release才是真安全
正确做法是：javac --release 8 HelloWorld.java。--release会：- 设置
-source 8 -target 8 - 使用JDK 8的
rt.jar作为引导类路径（bootclasspath） - 禁用JDK 11+的新API，编译时直接报错
- 设置
我曾为一个银行系统做JDK 8迁移，用--release 8一次性捕获了23处Optional.orElseThrow()调用——这些在-target 8下能编译，但运行必崩。
5.2 实战技巧：用javap和jclasslib快速定位问题
javap是命令行利器，但图形化工具jclasslib（https://github.com/ingokegel/jclasslib）能让你直观看到Class文件全貌：
- 打开
HelloWorld.class，左侧树状结构清晰展示Constant Pool、Fields、Methods、Attributes - 点击
Methods → main → Code，右侧显示字节码、操作数栈变化、局部变量表 - 右键
Constant Pool项，可直接跳转到引用它的指令
这个工具帮我快速定位过一个诡异问题：某个内部框架生成的class，LineNumberTable中行号全为0，导致所有断点失效。在jclasslib中一眼看出LineNumberTable属性长度为0，进而追查到框架的ClassWriter未调用writeLineNumberTable。
5.3 终极验证：用OpenJDK源码确认每一个字节
当所有工具都无法解释现象时，回到源码。例如，javac如何决定maxStack？答案在Gen.genMethod中：
// Gen.java 第1200行左右 code.maxStack = 0; code.maxLocals = 0; genMethodBody(method, code); // maxStack在genMethodBody中动态计算genMethodBody会模拟执行字节码，跟踪操作数栈深度变化。所以maxStack不是静态计算，而是动态模拟的结果。这意味着，如果你的代码有复杂的条件分支，maxStack可能比直觉大得多。
我曾为一个数学计算库优化，发现maxStack高达128，导致JVM频繁扩容栈。通过阅读genMethodBody，发现是double运算需要8字节
