Java编译流程全解析：从代码到运行

本文深入剖析了Java从源码到运行的完整生命周期，系统揭示javac编译器远不止“翻译”代码：它严格执行词法、语法、语义分析、注解处理（内置注解如@Override在语义阶段校验，Lombok等则在注解处理阶段动态改写AST）、字节码生成五步前端流程；厘清了-classpath与--module-path的本质分工与常见陷阱，指出模块化下类路径与模块路径互不可见的硬边界；还原了ClassLoader双亲委派的真实加载时机——按需触发而非目录顺序；并一针见血地解释了“编译通过却运行报IllegalAccessError”等经典疑难问题的根源——模块约束仅在运行链接期强制生效，而javac对此静默无视。无论你是被“cannot find symbol”困扰的初学者，还是在混合模块与类路径中踩坑的资深开发者，这篇文章都直击痛点，提供可立即落地的诊断思路与解决方案。

javac 命令到底做了什么

javac 不是简单地把 .java 文件“翻译”成 .class 文件，它执行的是一个完整的前端编译流程：词法分析 → 语法分析 → 语义分析 → 注解处理 → 字节码生成。其中，@Override、@Deprecated 等内置注解会在语义分析阶段被检查；而自定义注解处理器（如 Lombok 的 @Data）则在注解处理阶段介入，可能动态修改 AST 或生成新类。

常见错误现象：javac 报错 “cannot find symbol”，往往不是缺 jar 包，而是当前编译路径未包含依赖的 .class 或源码（比如没加 -cp 或 -sourcepath）；若报 “class file has wrong version”，说明 JDK 版本不匹配（如用 JDK 17 编译但目标运行在 JDK 8 上）。

• 使用 -source 和 -target（旧版）或 --release（推荐）控制源码语法兼容性和字节码版本，例如 javac --release 8 Hello.java 可确保生成 JDK 8 兼容的 class 文件
• 多个源文件编译时，javac 默认只编译显式列出的文件，不会自动递归查找依赖的 .java —— 除非用 -sourcepath 指明源码根目录
• -Xlint:all 能暴露潜在问题（如未使用的变量、裸类型），但默认关闭；生产环境建议启用

类路径（-cp / -classpath）和模块路径（--module-path）怎么配才不乱

Java 9+ 引入模块系统后，-cp 和 --module-path 各司其职：-cp 用于传统类路径下的非模块化 JAR 或 class 目录；--module-path 用于定位模块化 JAR（含 META-INF/MANIFEST.MF 中的 Automatic-Module-Name 或真正 module-info.class）。

容易踩的坑：java -cp lib/a.jar:lib/b.jar MyApp 中，如果 b.jar 是模块化 JAR 且声明了 requires a，但 a.jar 在 -cp 下而非 --module-path，JVM 会报 Module b not found —— 因为模块路径上的模块无法“看到”类路径上的类（反之亦然，除非用 --add-modules 显式打开）。

• 混合使用时，优先把所有 JAR 放到 --module-path，再用 --add-modules ALL-SYSTEM 或 --add-modules java.xml 按需引入系统模块
• 用 java --list-modules 查看当前模块图，确认目标模块是否已解析
• IDE（如 IntelliJ）默认用模块路径管理依赖，但 Maven 构建时 maven-compiler-plugin 仍默认走类路径，需显式配置 true

运行时 ClassLoader 加载 class 文件的真实顺序

JVM 启动后，并不立即加载所有 .class 文件。类加载分三个阶段：加载（Loading）、链接（Linking）、初始化（Initialization），而“加载”本身又由 ClassLoader 按双亲委派模型触发 —— 并非按文件目录顺序，而是按首次主动使用（如 new 实例、调用静态方法、访问静态字段）时的引用链触发。

典型误解：把 MyApp.class 和它依赖的 Utils.class 放同一目录，就认为 JVM 会“一起加载”。实际是 MyApp.main() 执行中首次碰到 Utils.doWork() 时，才委托 AppClassLoader 去加载 Utils.class；若此时 Utils.class 损坏或权限不足，抛出 NoClassDefFoundError（注意不是 ClassNotFoundException，后者发生在 Class.forName() 显式加载失败时）。

• ClassLoader.getSystemClassLoader() 返回的是应用类加载器，它只负责 -cp 下的路径，不负责 --module-path —— 后者由 ModuleLayer 管理
• 自定义 ClassLoader 若重写 loadClass() 但未调用 super.loadClass()，会破坏双亲委派，导致 java.lang.String 等核心类无法加载
• 用 java -verbose:class MyApp 可实时观察每个类何时被哪个 ClassLoader 加载

为什么 javac 编译通过，java 却报 IllegalAccessError

这通常发生在模块边界被绕过时。例如：模块 A 导出 com.a.publicpkg，但内部类 com.a.internal.Helper 被 B 模块通过反射获取并调用其 public 方法 —— javac 编译期只检查语法和可见性声明，不校验模块约束；而 JVM 运行时在链接阶段发现该类未被导出，直接拒绝访问，抛出 IllegalAccessError（不是 IllegalAccessException，后者是反射调用时的检查异常）。

另一个常见场景：使用 sun.misc.Unsafe 或 jdk.internal.ref.Cleaner 等内部 API。JDK 9+ 默认禁止访问，即使加了 --add-opens，若未同时加 --add-exports，编译期无感知，运行时报错。

• 修复方式：对模块间访问，用 requires transitive 或 exports ... to 显式授权；对内部 API，用 --add-exports jdk.unsupported/sun.misc=ALL-UNNAMED
• javac -Xdiags:verbose 不会提示模块问题，必须靠 jdeps --module-path 分析依赖图，或用 jlink 构建最小运行镜像时暴露缺失模块
• Gradle 用户要注意：compileJava 任务默认不启用模块检查，需手动加 options.compilerArgs = ['--module-path', ...]

今天关于《Java编译流程全解析：从代码到运行》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！