Class 文件与字节码全解析：从 javac 编译流程到 JVM 加载机制

先别急着敲命令。我见过太多人用了一年多 Java，javac 和 java 倒是敲得飞起，可你要问他 .class 文件里到底存了什么，为什么同一份代码换个 JDK 版本就报 UnsupportedClassVersionError，他多半只能挠头。这一章咱们就把 OpenJDK 里“从源码到字节码”这条管线整个撸一遍，重点盯着 Class 文件的结构和 javac 的编译流程。看完你会明白，字节码不是玄学，它只是一份格式极其严格的二进制契约，而 javac 就是那个把人类能读懂的 Java 源码翻译成这份契约的翻译官。

这篇内容适合三类人：刚学完 Java 语法、想知道 .class 里面到底是什么的新人；被 NoClassDefFoundError、UnsupportedClassVersionError 折磨过、想彻底搞懂根因的开发者；以及准备接触 JVM 调优、字节码插桩、Arthas 这类工具，需要先建立底层认知的进阶选手。

1. 为什么必须先把“Class 文件”和“字节码”分开理解

很多人把“Class 文件”和“字节码”当成一回事，真追起来其实差着层面。Class 文件是字节码的容器，字节码是 Class 文件里 Code 属性中存的那一串指令。这就好比 PDF 文件里存的是文字内容，PDF 是壳，文字才是核。搞混这两层，后面看 javap -verbose 输出时会晕。

1.1 “一次编译，到处运行”这句话骗了你好多年

Java 号称“一次编译，到处运行”，但这句话成立的前提是每个平台上都装了一个对应的 JVM。javac 编译出来的 .class 不是给 CPU 直接跑的机器码，而是给 JVM 这个“虚拟机 CPU”跑的指令集。同一个 Class 文件，Windows 上的 JVM 能读，Linux 上的 JVM 也能读，macOS 上还能读，前提是版本兼容。

这就产生了一个特别容易踩的坑：Class 文件里写着编译时用的 JDK 主版本号，JVM 加载时先看这个号，比自己的版本高就直接拒绝。JDK 8 对应的主版本号是 52，JDK 11 是 55，JDK 17 是 61。你用 JDK 17 编译出来的 Class，扔到只装了 JDK 8 的环境里，跑起来就是 UnsupportedClassVersionError，报错信息会写得明明白白。

注意：高版本 JDK 编译出的 Class 文件不代表只能在将来版本的 JVM 上跑，而是不能在比自己版本低的 JVM 上跑。 这两句话区别很大，前者说的是兼容方向，后者说的是版本门槛。

1.2 字节码和机器码的差距，恰恰是 Java 的护城河

字节码的每一个指令都有固定含义，但它不绑定任何具体 CPU 架构。iadd 就是“把操作数栈顶两个 int 相加”，不管底下是 x86 还是 ARM，JVM 都得把这个语义翻译成本地指令。真正干这活的叫解释器和 JIT 编译器（Just-In-Time Compiler）——解释器一条条读字节码执行，JIT 则把热点代码编译成当前平台的机器码缓存起来。

所以你在 .java 里写死的 a + b，经历了两层翻译：javac 把它编成字节码 iadd，JVM 再把它变成 CPU 认识的原生加法指令。理解这条链路，后面看常量池、看 Code 属性、看操作数栈的时候，就不会觉得那些数字是乱码了。

2. javac 前端编译管线：源码从字符流变成二进制的五步流程

javac 不是一口气把 .java 变成 .class 的。它的编译过程分成五个阶段，每个阶段处理的对象都不一样。我在 OpenJDK 源码的 com.sun.tools.javac 包里追过这条链路，主流程在 JavaCompiler 类里，核心步骤清清楚楚。

2.1 第一阶段：词法分析，把字符流切成 Token 流

源码对编译器来说就是一段字符串。词法分析器（JavacParser 配合 Scanner）负责把这串字符切成一个个有意义的“单词”，这些单词叫 Token。Token 的种类包括：关键字（public、class、if）、标识符（变量名、类名）、字面量（数字、字符串）、运算符（+、=）、分隔符（{、}、;）。

比如下面这行代码：

会被切成长这样六个 Token：

这一步看着简单，但细节不少：数字 42 是 int 还是 long？字符串里的转义字符怎么处理？// 和 /* */ 注释怎么跳过？这些全是词法分析器的工作。它输出的 Token 流，是下一步语法分析的输入。

2.2 第二阶段：语法分析，Token 流变成抽象语法树

语法分析器拿到 Token 流之后，按照 Java 语言的语法规则（上下文无关文法），把它们组装成一棵抽象语法树，简称 AST。AST 的每个节点代表一个语法结构，比如类声明节点、方法声明节点、表达式节点、语句节点。

举个直观的例子，if (x > 0) { y = 1; } 这棵语法树的形状大致是这样：

树建好之后，语法分析阶段基本就结束了。这一步能抓出绝大多数“写错语法”的问题，比如少个括号、多个分号。你在命令行看到的那种 error: ';' expected，就是这里报出来的。

2.3 第三阶段：语义分析与符号标注，让树变得“有意义”

AST 建好了，但编译器还不知道 x 是什么类型、y 有没有定义、a + b 里的 + 是数字加法还是字符串拼接。这一步有两个重要角色：

• 符号表（Symbol Table）：记录类、方法、字段的声明信息。javac 会把遇到的每个类、每个方法都注册进去，这样后面代码里引用 Foo.bar() 时，能快速找到对应的声明。
• 类型检查（Type Checking）：确认 String s = 123; 这种代码报错，确认 int x = "abc"; 类型不匹配。类型不匹配的 incompatible types 错误在这里产生。

还有一个容易忽视的小优化叫常量折叠（Constant Folding）。final int SIZE = 1024 * 4; 在生成字节码时，1024 * 4 会被直接算成 4096，不会傻傻地在运行时做一次乘法。这个细节在 javac 的 Attr 和 ConstFold 类里实现，后面用 javap 看字节码时你能直观看到效果。

2.4 第四阶段：注解处理，Lombok 的秘密就藏在这

这一步不是必须的，但它让 javac 变得可插拔。Java 提供了一套注解处理器机制（javax.annotation.processing），JDK 内置的 -processor 参数可以加载外部的注解处理器，对 AST 进行修改。

Lombok 就是干这个的。你用 @Getter 注解时，Lombok 的处理器会在 AST 里插入一个 getXxx() 方法节点，然后 javac 继续编译这棵已经被改过的树，所以生成的 .class 里真的会有 getXxx() 方法。你写的源码里看不到，但字节码里有。

实务提示：正因为注解处理器能改 AST，有些项目里 Lombok 和 MapStruct 同时用于同一个类时会出现诡异错误。原因往往是两个处理器对同一棵 AST 做了互相冲突的修改，排查方向应该先锁定是哪个处理器动了哪个节点。

2.5 第五阶段：字节码生成，AST 变成 Class 文件

最后一个阶段是代码生成，核心类是 com.sun.tools.javac.jvm.ClassWriter。它把标注完成的 AST 按照 JVM 规范里的 Class 文件格式，逐字节输出。这个格式可不是 javac 自己拍的，而是写死在 Java 虚拟机规范里的，JVM 加载 Class 文件时按同一套规范解析。

到这里，编译管线的全景图就出来了：

这套流程学着抽象，但你可以用一个命令看到中间产物：javac -XD-printflat 会输出注解处理和语法糖展开后的“扁平化” Java 源码，javac -XD-printtree 会直接打印 AST 的树形结构。我第一次看到 -XD-printtree 的树状输出时，前面那些抽象概念瞬间落地了。

3. Class 文件结构拆解：从魔数到属性表的完整旅程

Class 文件格式是一个严格排布的二进制定长/变长结构。你可以把它想象成一份填好的表单，每个字段该占几个字节、含义是什么，JVM 规范里写得一清二楚。下面用 JDK 8 编译一个最简单的类来逐段拆：

用 javac Hello.java && xxd Hello.class 看前 32 个字节，大概是这个样子：

每个十六进制字节都不是乱填的，位置换一下，Class 文件就废了。

3.1 魔数、次版本号、主版本号

前 4 个字节是魔数：CA FE BA BE。这是 JVM 用来快速判断一个文件是不是 Class 文件的标识，十六进制写法是 0xCAFEBABE，这四个字节是 Java 设计者 Robert Griesemer 当年开玩笑定的——因为 Java 的 Logo 是一杯咖啡，而咖啡的英文是 Java，浓咖啡在意大利语里叫 Espresso，杯子上印着咖啡豆。魔数的存在还带来一个实际作用：文件扩展名被改成 .txt 也没关系，JVM 只认魔数。

紧接着的两个字节是次版本号，再两个字节是主版本号。0x0000 0034 表示次版本号 0、主版本号 52。52 对应的就是 JDK 8。把这个数字背下来，排查版本问题会快很多：

特别注意：JDK 8 对应的主版本号是 52，很多资料把 JDK 8 和 52 绑在一起没错，但 javac -source/-target 可以向下兼容生成低版本的 Class 文件。比如 JDK 17 的 javac 执行 javac -source 8 -target 8，生成的版本号就是 52，可以在 JDK 8 的 JVM 上跑。实际项目里我建议尽量用 -release 8 而不是 -source/-target，因为后者只限制语言特性和版本号，不会限制 API 调用，容易编出一个版本号很低但用着高版本 API 的“不伦不类” Class 文件。

3.2 常量池：Class 文件里的“符号表”

0x001d 是常量池计数器，十进制 29，表示后面有 28 个常量。注意，计数器比实际数量多 1，因为第 0 项是留给 JVM 内部用的“空引用”标记。常量池是 Class 文件里最大的一个区域，存放了类、方法、字段、字符串字面量等所有符号信息。

每个常量都有一个 tag 字节表示类型，常用的类型见下表：

为什么搞这么复杂？因为 JVM 是一门“宁可不做也不乱做”的虚拟机。它在解析一个 System.out.println 方法调用时，字节码指令指向常量池里的某个 Methodref，Methodref 又指向 Class 和 NameAndType，NameAndType 再指向两个 Utf8 串。这种多级引用的目的是让符号信息可以被多个地方复用，减少重复存储。一个方法被 10 个地方调用，常量池里只需要存一份 Methodref。

3.3 访问标志、继承关系、接口表

常量池后面是访问标志 access_flags，占用 2 个字节，用位掩码表示类的修饰符。0x0021 是 ACC_PUBLIC（0x0001）和 ACC_SUPER（0x0020）的组合。ACC_SUPER 这个标志在 JDK 8 之后其实已经没有实际作用，但规范要求必须显式置位，属于历史包袱。

接着是 this_class 和 super_class，各占 2 字节，都指向常量池中的 CONSTANT_Class 项。再往后的 interfaces_count 和 interfaces[] 记录类实现了哪些接口。这里值得注意：this_class 指向的常量是一个“类名索引”，实际类名是 java/lang/Object 这种内部形式，包名用 / 而不是 .，因为在 Class 文件层面，点号是非法字符。

3.4 字段表和方法表：描述符是理解字节码的钥匙

字段表和方法表的结构几乎一样：先是 access_flags，然后是 name_index、descriptor_index，最后是 attributes_count 和 attributes[]。

name_index 指向常量池里的字段名或方法名，descriptor_index 指向一个描述符字符串。描述符是 JVM 用来描述类型签名的一套编码规则：

方法描述符的格式是 (参数类型列表)返回值类型。main 方法的描述符是 ([Ljava/lang/String;)V，意思是参数是一个 String 数组，返回值是 void。第一次看这串会头皮发麻，但这是一切字节码工具的基石，看懂它，javap 的输出不再神秘。

U 形管道记忆法：方法描述符的括号，像一根 U 形管道。管道进口是参数类型，出口是返回值类型。(IJ) 就是“进来两个 int，出去一个 JVM 栈上的 long”。

3.5 属性表：真正存放“代码”的地方

方法表后面跟着属性表，属性表里各种属性用不同的结构存放额外信息，其中最核心的是 Code 属性。Code 属性就是字节码指令的最终宿主，里面包含：

• max_stack：这个方法运行时候操作数栈的最大深度
• max_locals：局部变量表需要的槽位数
• code_length 和 code[]：真正的字节码指令数组
• exception_table[]：异常处理表，对应 try-catch 的跳转逻辑
• LineNumberTable：字节码行号到 Java 源码行号的映射
• LocalVariableTable：局部变量名与槽位的映射，用于调试

还有一个容易被忽略的属性叫 Exceptions（注意名字带 s），它记录方法声明 throws 哪些受检异常。JIT 在运行时做优化时，会用到这里的异常信息。

看 Hello 类的 main 方法，Code 属性的 max_stack 是 2，max_locals 是 1。为什么是 2？因为 System.out.println 调用需要先加载 System.out（压入槽 1），再加载常量池里的字符串（压入槽 2），然后调用 println，栈深最高到 2。这个数字不是拍脑袋定的，是 javac 静态分析栈行为算出来的，JVM 加载时还要验证这个数值不能超过方法实际需要的栈深，否则直接 VerifyError。

4. 用 javap 把字节码“翻译”回人话

Class 文件的结构讲完，不能光看不练。JDK 自带的 javap 工具就是拆解 Class 文件最好的锤子。下面把 Hello.class 反汇编看核心内容。

4.1 javap 最常用的三组参数

命令行执行 javap -c Hello，输出如下：

每一行指令分成三部分：指令偏移量（如 0:）、操作码（如 getstatic）、操作数（如 #7）。#7 是常量池的第 7 项，javap 贴心地给你标出来了这一项具体是什么。getstatic 的作用是把一个静态字段的值压到操作数栈上，这里就是取出 System.out；ldc 把一个常量从常量池加载到栈；invokevirtual 调用实例方法。整个 main 方法就四句指令，一气呵成。

4.2 操作数栈模型：一个加法方法的完整执行

用一个更简单的例子看栈的变化：

javap -c 输出：

逐行拆解：

• iload_1：把局部变量表第 1 个槽位的 int（即 a）压入操作数栈
• iload_2：把局部变量表第 2 个槽位的 int（即 b）压入操作数栈
• iadd：把栈顶两个 int 弹出，相加，结果压回栈
• ireturn：把栈顶 int 返回给调用者

这里有个隐藏知识点：实例方法的局部变量表第 0 个槽位是 this！所以 int a 排在第 1 个槽位，int b 排在第 2 个。如果是静态方法，this 不存在，参数直接从第 0 个槽位开始。这个“差一位”的规律，在分析字节码时特别容易踩坑。

坑：有些反编译工具显示的局部变量槽位和源码顺序不一致，这不是工具 bug，而是 javac 对局部变量槽位做了复用。int i = 0; 和后续的 String s = ""; 生命周期不重叠，就可能共用同一个槽位。MaxLocals 不是参数个数 + 局部变量个数那么简单，而是“同时存活的变量峰值”。

4.3 源码的语法糖在字节码里长什么样

Java 的很多语法糖，最终都会被 javac 翻译成等价的字节码。javap 是抓语法糖现形的最好工具。

字符串加号拼接是典型。JDK 8 及以前，"a" + b + "c" 会被编译成 new StringBuilder() 然后连环 append。但 JDK 9 改了策略，改用 invokedynamic 加上 StringConcatFactory 引导方法。这在字节码里怎么体现？

这是 JDK 8 的样子。JDK 11 则变成了：

invokedynamic 是 JDK 7 引入、JDK 8 在 Lambda 里大放异彩的指令。它允许在运行时才决定怎么调用，极大地增加了 JVM 的动态性。理解这一点，对后来理解 LambdaMetafactory、StringConcatFactory 这些“引导方法”很有帮助。

4.4 看懂字节码学了有什么实际价值

有人觉得字节码是“底层人才要看的”，这是误区。SQL 慢了你得看执行计划，线上问题你得看堆栈，字节码就是 Java 的“执行计划”。我在排查过的一次线上问题里，一个诡异到找不到根因的 NullPointerException，最终就是用 javap 看到了一个字段在 try-with-resources 展开后的 close() 调用被内联到了异常路径里，才知道是资源关闭时序问题。

搞字节码的另一个价值是理解字节码增强工具。Arthas 的 watch、trace 本质上是动态修改目标类的字节码，插桩后重新加载；SkyWalking 这类 APM 工具的 agent 也靠 Java Instrumentation API 做字节码增强。不懂字节码，出了问题连日志都看不明白。

5. 三个“看完就上手”的实操验证手段

光纸上谈兵没意思。我每次给团队讲新同事讲这块内容，都会让他们做下面三个练习，半小时内就能建立“我能看清 Class 文件”的信心。

5.1 练习一：用 javap -verbose 通读一个极简类的完整结构

创建一个 Point.java：

javac Point.java && javap -verbose Point。

你会看到 flags: (0x0021) ACC_PUBLIC, ACC_SUPER、this_class: #7、super_class: #2、一堆常量池项。重点观察 distanceSquared 的 Code 属性里的 max_stack 是多少。这里用 iload_0 加载 this，然后 getfield 拿 x，iload_0 再取 this，再 getfield 拿 x，相乘……最终算出 max_stack 至少是 2。看完你会对“栈深度是静态计算出来的”这句话有切身体会。

5.2 练习二：编译产物到底落在了哪个目录

javac 默认把 .class 生成在和 .java 相同的目录。但实际项目里没人会这么干，通常用 -d 参数指定输出目录：

这条命令会把 Point.class 生成到 out/classes/com/example/Point.class，包名的目录结构会被自动创建。面试里经常有人答错“一个 .java 文件里有多个类时，编译后生成几个 .class”，答案是“有几个类就生成几个”。顶层 public 类的文件名必须和类名一致，但非 public 的 package-private 类、内部类、匿名类都会各生成一个 .class 文件。匿名类的名字长这样：OuterClass$1.class、OuterClass$1$2.class，数字是嵌套顺序。

5.3 练习三：JSP 编译出的 Class 到底保存在哪

这个点经常有人问：“JSP 不是直接由 JVM 执行吗？哪来的 Class 文件？”这是一个流传甚广的误区。JSP 是服务器端模板，Tomcat 第一次访问 JSP 时，会先把 JSP 翻译成一个 Java Servlet 源码文件，然后调用 javac 把它编译成 Class 文件，再装载执行。

Tomcat 的默认工作目录是 ${CATALINA_BASE}/work/Catalina/localhost/<应用名>/org/apache/jsp/。你在里面能找到类似 index_jsp.java 和 index_jsp.class 的文件。index_jsp.java 是 Tomcat 生成的 Servlet 源码，里面能看到 _jspService 方法内嵌了 HTML 输出和 Java 逻辑。所以 JSP 不是绕过编译，而是自动触发了一遍预编译。对应地，修改 JSP 后 Tomcat 检测到文件变化，会重新走一遍翻译 → 编译 → 加载流程，所以 work 目录下会产生新的 Class 文件，旧版本残留多了还会占磁盘空间。

经验：线上排查 JSP 相关问题时，第一件事就是去 work 目录下看生成的 _jsp.java 源码。改了 JSP 不生效时，经常是 work 目录里的旧 Class 没被清理干净，手动清掉 work 目录再重启，比在那儿瞎猜配置快得多。

6. 从搜索热词看初学者最常踩的三个 Class 相关坑

搜索引擎的热词总是很诚实，它们反映的就是实际开发里大家问得最多的问题。我把跟 Class 文件相关的三个高频问题整理出来，逐个说透。

6.1 javac Welcome.java 之后卡住了，或者 Could not find or load main class

新手常犯的错误是编译和执行的类名写法不一致。假设源码是：

编译执行顺序应该是：

注意 java 后面跟的是类名，不带 .class 后缀，也不带 .java 后缀。很多新手写成 java Welcome.java，到 JDK 11 以后这样跑单文件还行，但在传统编译执行模型里就是错的。Could not find or load main class 另一个高频原因是把 java 命令放在了错误的目录执行，或 CLASSPATH 配置有问题。JDK 9 之后没有自动把当前目录加入 classpath 的说法吗？不是的，默认 classpath 就是当前目录，但你如果设置了 CLASSPATH 环境变量，就会覆盖默认行为。

6.2 java Welcome a 44 里 a 和 44 是怎么进到 main 的

命令行里 java 后面的参数会以字符串数组的形式传给 main 方法：

args[0] 是 "a"，args[1] 是 "44"——注意，44 虽然看起来像数字，但它到了 main 里就是字符串 "44"。想要当成数字用，得手动转换：

Args 的分配发生在 JVM 的启动流程里，JVM 解析命令行参数的时候，把 a 和 44 放进一个 String[]，然后调用 Welcome.main 时作为参数传进去。这一步在字节码层面看，main 方法描述符 ([Ljava/lang/String;)V 的参数部分，JVM 会在调用前把数组对象压到局部变量表第 0 个槽位。权限校验、类加载完成后，这步由 JVM 内部完成，不经过 javac，属于运行时行为。

6.3 openjdk:17-jdk-slim 和容器里编译有哪些容易忽略的差异

这个热词出现在容器化和云原生环境里。openjdk:17-jdk-slim 是一个精简版 JDK 17 镜像，带 javac。但要注意：编译时用的镜像和运行时用的镜像最好分开。编译阶段需要完整的 JDK（含 javac、jar 等工具），而运行阶段只需要包含 JRE（或者 JDK 里的 java 命令）即可，镜像体积能小很多。

如果你在容器里执行 javac 遇到 Unable to locate a Java Runtime 之类的错，先检查镜像里装的是不是 JRE 而不是 JDK。slim 镜像本身没问题，它自带 javac，但如果你把 openjdk:17-jre-slim（只有 JRE）当 JDK 用，编译自然是失败的。

编译与运行的版本一致性也很重要。容器里用 JDK 17 编译，推到测试环境却是 JDK 11，Class 文件主版本号 61 直接撞上 JVM 55，报错就是 UnsupportedClassVersionError。这种情况在本地没事、上容器就崩，排查方式很简单：javap -verbose 你的类名 | grep major，或者直接用 file 你的.jar。看到 major version 61，再确认目标环境的 java -version 是 17 以上，问题就锁定了。如果要兼容低版本 JDK，就用 -release 11 这类参数重新编译，而不是靠运行时打补丁。

7. 最后说点心里话：Class 文件值得每个 Java 开发者读一遍

我最早接触 Class 文件格式是在查一个线上 VerifyError 的时候。当时某个中间件供应商给了个补丁 jar，在 JDK 8 上跑得好好的，升级到 JDK 11 就崩，报 VerifyError: Bad type on operand stack。我抓破脑袋想不通，后来用 javap -verbose 对比新旧两个 jar 里的同一个方法，发现对方打着“兼容 JDK 11”的旗号，实际在字节码里对同一个局部变量槽位塞了两个类型。JVM 的字节码验证器不买账，当场拒收。那次经历让我彻底明白，Class 文件不是一个看一眼就扔的黑盒，它是 JVM 信任你的最低底线。

如果你问我学这块最快的路径，我的答案朴素得过分：把自己写过的类都 javap 一遍，看到不懂的指令就查 JVM 规范，查完再写一个更复杂的类继续 javap。Java 的语法糖不算少，try-with-resources、增强 for 循环、Lambda、字符串拼接，它们在字节码里全都会现出原形。看多了你会发现，javac 做的事没那么玄，它不过是一个非常守规矩的翻译官，而你手里的 javap，就是查看这位翻译官工作底稿的放大镜。

坚持看完这一章，你已经在“Java 开发者”和“JVM 使用者”之间划了一道分界线。下一章可以放心去聊类加载机制了——到时候你会发现，类加载器读的正是这章拆过的 Class 文件，知识一下子就闭环了。