Java编译器源码解析：手写javac的完整流程与避坑指南

简介Java编译器实现相关的学习资料包面向正在学习编译原理或希望动手编写简易IDE的Java开发者。资源聚焦Java源代码到JVM字节码的完整编译流程覆盖词法分析、语法分析、语义分析、中间代码生成、代码优化与目标代码生成等关键阶段并结合javac与ECJ等实例说明编译器的典型结构。压缩包内共2个文件包含一个Java源文件和一个Markdown文档整体仅2KB。JavaIDE.java提供了集成开发环境的基础框架适合作为自定义编译器和IDE项目的参考实现readme.md则用于说明项目背景、使用方式与常见问题帮助读者快速上手。当前已有58人学习下载。通过阅读源码与文档可以理解Java程序从文本到字节码的转换原理掌握错误检测与语法树构建的基本思路对后续学习JVM机制或自行实现小型语言编译器具有实用价值。1. 把 Java 编译器拆开看这份源码实现不是黑匣子很多做 Java 三年五年的同学对javac的认知还停留在「写完.java双击编译就出.class」的层面直到面试被问「Java 编译器有几种、JVM 编译器跟你本地javac有什么区别」才意识到自己把编译器和运行时混为一谈。这份「Java 编译器的实现」资源拆的是一个简化版javac的完整源码包从词法分析到字节码生成核心流程全部能跑通本地一个Main.java就能把喂进去的源码变成.class文件。适合两类人一是准备面 Java 后端、想在 JVM 类加载和字节码层面说出细节的求职者二是刚接触编译原理、不想啃龙书但想看真实代码的入门者。这份资源解决的不是「怎么用 javac」而是「javac 大致是怎么被写出来的」。2. 编译器主流程与核心数据结构词法、语法、语义三段式怎么落地2.1 词法分析器从源码字符流到 Token 流编译器第一步不是「读懂代码」而是「切分代码」。词法分析器做的事情很机械读字符、拼 Token、跳过空白和注释。很多初学的朋友以为这一步简单实际踩坑点都在细节上——关键字和标识符的区分、数字字面量溢出、字符串里转义字符的处理。这份资源里的Lexer类采用了最典型的逐字符扫描方案核心代码长这样public class Lexer { private final String source; private int pos 0; private int line 1; private static final SetString KEYWORDS Set.of( int, boolean, if, else, while, return, void, class ); public Token nextToken() { skipWhitespaceAndComments(); if (pos source.length()) { return new Token(TokenType.EOF, , line); } char c source.charAt(pos); if (Character.isDigit(c)) { return readNumber(); } if (Character.isLetter(c) || c _) { return readIdentifierOrKeyword(); } if (c ) { return readStringLiteral(); } pos; return new Token(TokenType.forChar(c), String.valueOf(c), line); } }这段逻辑的关键在readIdentifierOrKeyword()先按「字母或下划线开头、后续字母数字下划线」的规则读出一个完整词再去KEYWORDS集合里查是不是保留字是保留字就返回关键字 Token否则返回标识符 Token。顺序不能反反了就会出现「关键字被当成普通变量名」的乌龙。TokenType.forChar(c)处理的是运算符和分隔符比如、-、(、)它内部维护了一个字符到 Token 类型的映射表。参数上需要注意两点。第一line变量要在每次换行时自增否则后面语法报错时定位不到行号排查起来相当痛苦。第二readNumber()里要处理溢出常见做法是读的过程中用long累加超出int范围直接抛编译错误而不是等数值进常量池之后才发现类型装不下。2.2 语法分析器递归下降与 AST 节点设计Token 流只是一维的序列语法分析要把它还原成树形结构。这份资源用的是递归下降法没引入 CUP、ANTLR 之类的生成器好处是代码完全可控坏处是每个产生式都得手写。以表达式解析为例典型的优先级处理方式是「层层嵌套」// 优先级从低到高加法 乘法 一元 原子 public Expr parseExpression() { Expr expr parseAdditive(); return expr; } private Expr parseAdditive() { Expr left parseMultiplicative(); while (match(TokenType.PLUS) || match(TokenType.MINUS)) { Token op previousToken(); Expr right parseMultiplicative(); left new BinaryExpr(op, left, right); } return left; } private Expr parseMultiplicative() { Expr left parseUnary(); while (match(TokenType.STAR) || match(TokenType.SLASH)) { Token op previousToken(); Expr right parseUnary(); left new BinaryExpr(op, left, right); } return left; }这代码体现了一个核心设计parseAdditive()调parseMultiplicative()parseMultiplicative()再调parseUnary()每一层只处理自己那一级优先级看到运算符就继续循环。BinaryExpr节点保存运算符 Token 而不是直接保存PLUS枚举是为了后续语义分析阶段拿得到源码位置报错信息能精确到行列。AST 节点在这份资源里是「字段基本公开、不搞 getter/setter」的风格为的是写出expr.left、expr.right这种直接访问代码量小读起来也直白。新手做自己的编译器时我建议也保持这个风格AST 本身就是内部数据结构封装反而碍事。2.3 语义分析符号表与类型检查的先后顺序词法和语法过了代码还只是「长得像程序」。语义分析要回答的问题这个变量声明了吗这个类型对不对方法参数个数匹配吗这份资源里的SymbolTable用了经典的作用域链结构——当前作用域里查不到就往上一层找。public class SymbolTable { private final SymbolTable parent; private final MapString, Symbol symbols new HashMap(); public Symbol lookup(String name) { SymbolTable scope this; while (scope ! null) { Symbol sym scope.symbols.get(name); if (sym ! null) { return sym; } scope scope.parent; } return null; } public void define(String name, Type type) { if (symbols.containsKey(name)) { throw new CompileError(duplicate definition: name); } symbols.put(name, new Symbol(name, type)); } }类型检查的顺序是有讲究的先检查声明语句——变量重复定义、类型不存在这些问题要第一个暴露再检查赋值兼容性——比如把boolean赋给int变量在这份资源里直接报错最后检查表达式类型——if (a b)里a b必须是boolean。顺序乱了会出现连锁误报一个变量名打错产生一串令人困惑的错误信息实际根源就一行。我拆这份源码时的感受是语义分析是最适合照着练的部分它不涉及复杂的算法但极其考验数据结构的组织能力。符号表一旦设计成链表式作用域后面做方法重载、泛型如果扩展的话都能挂在新一层作用域上扩展路径是清晰的。3. 字节码生成与编译器参数从 AST 到 class 文件的关键一跳3.1 CodeGen 访问器AST 节点怎么映射成 JVM 指令语义分析通过之后AST 必须翻译成 JVM 字节码。这一步是这份资源里最「高级」的部分也是面试里真正能拉开差距的考点。做法是对每种 AST 节点写一个生成方法深度优先遍历把节点映射成指令序列。public class CodeGen implements ExprVisitorInteger { private final ByteArrayOutputStream code new ByteArrayOutputStream(); private final ConstantPool cp new ConstantPool(); Override public Integer visitBinary(BinaryExpr expr) { expr.left.accept(this); expr.right.accept(this); switch (expr.op.getType()) { case PLUS: emit(Opcode.IADD); break; case MINUS: emit(Opcode.ISUB); break; case STAR: emit(Opcode.IMUL); break; case SLASH: emit(Opcode.IDIV); break; default: throw new CompileError(unsupported operator: expr.op); } return null; } }映射逻辑的核心是a b先从局部变量表读aILOAD指令读b又是一个ILOAD然后执行IADD。操作数栈先进后出所以左操作数先入栈、右操作数后入栈最后指令消费两个数吐出一个结果。这里最容易写错的就是顺序如果你先访问右子树再访问左子树加法结果就反了程序运行时报错还特别隐蔽——不是「编译失败」而是「结果算错」。code输出流是逐步 build 的二进制指令最终要配合ConstantPool常量池才能形成完整 class 文件。常量池是这个阶段最常见的翻车点字符串常量、类名引用、字段描述符、方法签名都要在这里登记并拿到一个索引号索引从 1 开始计数0 号位保留。这份代码里很多索引错位问题根源都是忘了 0 号保留位。3.2 javac 的真实编译参数-source、-target 与 -proc 的边界拆这份资源不光看它内部实现还得对照真实javac的参数来理解设计取舍。以下是平常用得最多的几个编译参数配合这份源码里的对应设计看收获会大很多。参数作用对应源码中的控制点-source 8指定源码语言版本控制语法特性开关词法/语法分析中按版本决定是否启用 lambda 等新语法-target 8指定生成 class 文件的版本影响major_version字段字节码生成器写ClassFile头时写死的版本号-g生成调试信息LocalVariableTable、LineNumberTableCodeGen中是否额外写入调试属性表-proc:only只运行注解处理器不执行编译资源中的简化编译器未实现但设计上应在语义分析前后插入-d dir指定输出目录决定 class 文件的落盘位置简单做法是直接用Files.write()写死路径我自己写编译器的时候-source和-target分开设计是必须的。举个例子-source 8 -target 11是合法的它表示「用 Java 8 允许的语法写源码但生成的字节码版本是 Java 11」。这份资源里没有完整的版本分派逻辑只写死了生成 class 版本为 52.0Java 8但你看它的代码结构版本号无非是ClassFile里两个字段想扩展成可配置并不难。3.3 常量池结构索引怎么填才不会错位写 class 文件时常量池是最容易出玄学问题的地方。这份资源里ConstantPool的实现接近于教科书一个ListCpInfoadd()返回索引位置所有引用都按这个索引回填。public class ConstantPool { private final ListCpInfo entries new ArrayList(); // 注意常量池索引从 1 开始0 是保留位 public ConstantPool() { entries.add(null); // 占位符让 index 0 不可用 } public int addUtf8(String value) { entries.add(new Utf8Info(value)); return entries.size() - 1; } public int addClassRef(String className) { int nameIndex addUtf8(className.replace(., /)); entries.add(new ClassInfo(nameIndex)); return entries.size() - 1; } public int addMethodRef(String className, String name, String descriptor) { int classIndex addClassRef(className); int nameAndTypeIndex addNameAndType(name, descriptor); entries.add(new MethodrefInfo(classIndex, nameAndTypeIndex)); return entries.size() - 1; } }常量的引用关系是链式的Methodref指向Class和NameAndTypeNameAndType又指向两个Utf8。如果addClassRef每次调用都新增Utf8而不先查表复用class 文件会迅速膨胀如果entries.add(null)这个占位忘了写后面所有索引都偏移一位JVM 加载时直接抛ClassFormatError。对照真实javac的行为它有个Symbol去重表同一个类名只产生一个ClassInfo。这份资源在常量池瘦身这一点上写得不细算是可以扩展的切入点。我一般建议如果拿这份资源去做课程设计第一个改进方向就是常量池去重——代码改动量不大但对 class 文件体积的影响一眼可见写报告时也很有说服力。4. 避坑编译器实现里高频翻车的四个注意事项4.1 深嵌套表达式把栈打爆现象编译一个1 2 3 ... 1000的表达式时直接抛出StackOverflowError不是编译报错而是编译器自己崩了。原因递归下降解析器对左结合运算符用的是循环while循环继续读下一个但遇到右结合或者括号嵌套极深的表达式时parseUnary()里的括号处理会递归调用parseExpression()每层括号一次递归1000 层括号就是 1000 层 Java 方法栈。解决在parseUnary()的括号分支加一个深度计数超过 500 就直接抛CompileError(nesting too deep)。更好的做法是把极端深的表达式用循环加显式栈来解析但做课程设计的话阈值限制足够用。这个坑如果不处理用户手滑生成一个深括号表达式你的编译器就成了一个拒绝服务的工具。4.2 中文注释和字符串乱码现象源码文件里有中文注释时编译能过但反编译后注释位置出现乱码字符串里直接写中文生成的 class 文件里变成了问号。原因读取源码文件时用了平台默认字符集Windows 简体中文环境下通常是 GBK而源码文件是 UTF-8 编码。词法分析器读进来就已经是乱码流后面再怎么处理都救不回。解决读文件的地方强制指定 UTF-8Files.readString(Path.of(inputFile), StandardCharsets.UTF_8);对应的String.getBytes()写 class 文件时也要指定StandardCharsets.UTF_8。我拆这份资源时发现它内部Utf8Info写数据用的就是getBytes()无参版本这就是个隐患——在自己电脑上跑没问题换成中文 Windows 就翻车。记住一句话源码读写和编译产物写出的字符集必须全部写死绝对不能依赖环境。4.3 方法重载解析选错目标现象定义了两个重载方法foo(int x)和foo(long x)调用foo(5)时编译器选择了foo(long)运行结果和直觉不符。原因方法重载解析按 JVM 规范有三个阶段第一阶段不拆包装、不允许变参只在「严格匹配」里找找不到才进入第二阶段允许自动拆装箱仍找不到最后才允许变参。这份资源只实现了「宽化转换」int可以宽化成long就直接匹配没有分阶段处理导致整数字面量直接匹配到了long版本。解决在语义分析阶段的方法查找逻辑里拆两个循环先做完全按参数类型的精确匹配精确匹配没有结果再去做允许宽化转换的匹配。两阶段中间绝不能合并。4.4 class 文件版本号写错导致高版本 JDK 拒收现象本地 JDK 8 编译产物正常拿到 JDK 17 环境一运行报UnsupportedClassVersionError提示版本号过低或过高。原因ClassFile 结构里major_version字段和 JDK 版本是一一对应的52 对应 Java 861 对应 Java 17。这份资源把版本号写死成了 52.0如果用户拿它跑在高版本 JVM 上反而被拒绝——虽然实际上 Java 8 的 class 在 Java 17 上默认能跑但如果你把版本号写成了 55Java 11却想跑在 Java 8 上就会报错。解决把版本号设计成可配置项从命令行参数读取。不配置的情况下默认输出 52.0。注意major_version是u2无符号 16 位写文件时用writeShort()不要用writeInt()否则把整个字段布局撑坏了问题更隐蔽。5. 用 javap 反汇编验证编译产物每改一处代码都值得跑一遍编译器写完了怎么知道生成的.class对不对靠跑程序只能看到结果看不到结构。这时候javap是最好用的验证工具——它就是 JDK 自带的 class 文件反汇编器不需要额外装任何依赖。先用最简单的方式验证整体结构# 编译自己实现的编译器然后让它去编译一个测试文件 java -cp ./classes Main Test.java -d ./out # 反汇编生成的 class 文件-c 展示字节码-p 展示私有成员 javap -c -p ./out/Test.class-c是看方法体字节码-p是连私有方法也一起展现。如果你写的测试类里有一个add(int, int)方法这时应该看到iload_1、iload_2、iadd、ireturn这样的指令序列——它们和你 CodeGen 里visitBinary生成的指令完全对应。再往上一步用-vverbose看完整的 class 文件结构javap -v ./out/Test.class这一段输出包含四块最值得检查的信息第一是major version确认版本号和预期一致第二是Constant pool列表核对每个常量的索引编号和类型第三是LocalVariableTable如果你的实现支持-g参数这里应该能看到变量名和起始 PC第四是LineNumberTable检查源码行号和字节码偏移量是否对应。我自己拆这份资源时已经形成了习惯每在CodeGen里加一种新的节点类型支持固定跑三个步骤——先用测试用例编译再跑javap -v看常量池索引最后用java实际执行一次确认结果。前两步能抓住绝大多数结构性错误第三步兜底验证语义。尤其是常量池索引偏移这类问题javap 会直接在输出里报Bad constant pool index定位速度比自己猜快得多。血泪经验是加字段解析支持的那次我改完语法分析、语义分析、CodeGen 三处代码后直接跑测试程序结果正常就没管了。后来换了个测试类同一个字段名在不同类重复出现才暴露出常量池没做按名去重class 文件里塞了十几份冗余的 Utf8 条目。从那以后我每次改完编译器都会对同一个测试源码强制走一遍javap -v对比前后差异不在这一步省时间。这份资源整体结构清晰按上面流程走一遍半天就能摸清编译器的主干路径希望帮到你。本文还有配套的精品资源点击获取