java 启动器 java 将初始化 Java 虚拟机。虚拟机随即按以下顺序搜索和加载类： 自举类 - 构成 Java 平台的类，包括 rt.jar 和 i18n.jar 中的类。 扩展类 - 使用 Java 扩展机制的类。它们被捆绑为 .jar 文件，位于扩展目录中。 用户类 - 开发人员和第三方定义的类，不使用扩展机制。在命令行上使用 -classpath 选项（常用方法）或使用 CLASSPATH 环境变量可识别这些类的位置（参见设置 Windows 或 Solaris 的 Classpath）。 实际上，这三个搜索路径将被连为一个简单的类路径。这有点象以前使用的“单级”类路径，但现在的模型有一些重要差别： 偶然“隐藏”或省略自举类相对困难一些。 通常只需指定用户类的位置。系统将“自动”查找自举类和扩展类。 工具类现在位于独立的归档中 （tools.jar）。只有当它包含在用户类路径中时才可用（稍后会有解释）。 Java 启动器如何查找自举类 自举类是实现 Java 1.2 平台的类。自举类在 /jdk1.2/jre/lib 中的 rt.jar 和 i18n.jar 归档中。这些归档由存储在 sun.boot.class.path 系统属性中的自举类路径值指定。该系统属性仅供引用，不应直接修改。 需要重新定义自举类路径的可能性较小。极少数情况下需要使用另一组核心类时，非标准选项 -Xbootclasspath 答应重新定义自举类路径。 注重：实现 JDK 开发工具的类与自举类在不同归档中。工具归档为 /jdk1.2/lib/tools.jar.调用启动器时，开发工具将该归档添加到用户类路径中。然而，这个扩大的用户类路径仅用于执行工具。处理源代码的工具 javac 和 javadoc 将使用初始类路径，而不是扩大后的类路径（有关具体信息，参见下面的 Javac 和 Javadoc 如何查找类）。 Java 启动器如何查找扩展类 扩展类是扩展 Java 平台的类。扩展目录中的每个 .jar 文件即被认为是扩展，且都使用 Java 扩展框架加载。我们不提供改变扩展目录位置的选项。 Java 启动器如何查找用户类 用户类是在 Java 平台上构建的类。查找用户类时，启动器需要使用用户类路径，它是一张目录、JAR 归档和包含类文件的 Zip 归档的列表。 类文件有一个反映类全限定名的子路径名。例如，假如类 com.mypackage.MyClass 存储在 /myclasses 下，则 /myclasses 一定位于用户类路径中，且类文件的完全路径一定为 /myclasses/com/mypackage/MyClass.class.假如类存储在名为 myclasses.jar 的归档中，则 myclasses.jar 一定位于用户类路径中，且类文件一定作为 com/mypackage/MyClass.class 存储在归档中。 在Solaris 中，我们用字符串指定用户类路径，而用冒号 （：） 分隔类路径项。java 启动器将用户类路径字符串放置在 java.class.path 系统属性中。该值可能的源为： 缺省值“。”意味着用户类文件是当前目录中的所有类文件（假如是在包中，则为当前目录下的）。 CLASSPATH 环境变量的值，它覆盖缺省值。 命令行选项 -cp 或 -classpath 的值，它覆盖缺省值和 CLASSPATH 值。 -jar 选项指定的 JAR 归档，它覆盖所有其它值。假如使用该选项，则所有用户类都来自指定的归档。

Java世界里有很多AOT编译的解决方案，虽然Oracle/Sun JDK到JDK8为止都还没有提供这样的功能。

先来几个传送门：

HotSpot VM JIT的编译产出，理论上能否被复用？ - RednaxelaFX 的回答

逃逸分析为何不能在编译期进行？ - RednaxelaFX 的回答

为什么Java不能由JVM产生针对特定操作系统的机器码从而提高效率？ - RednaxelaFX 的回答

请教：对Java类库jar文件，有什么好的防止反编译办法，最好是加密/解密方案，而不是代码混淆方案。 - RednaxelaFX 的回答

如何将Java打包成exe文件在没有JRE环境的电脑上执行？ - RednaxelaFX 的回答

各个操作系统下的 JVM 是谁开发出来的？ - RednaxelaFX 的回答

ios设备如何java编译？ - RednaxelaFX 的回答

java现在能直接编译成机器码? - Java

在深入到具体实现前，要先强调一点：

AOT编译（Ahead-of-Time Compilation）不但涉及一个编译器，还要涉及配套的运行时支持系统（runtime system）。两者通常是紧密耦合的。

换

句话说，一个AOT编译器只能跟自己的runtime搭配使用，这个runtime可以是一个完整的VM（如NGen与CLR的搭配），也可以是一个比较

小的runtime（如.NET Native里的MRT（Minimal Runtime），只提供基础的GC、多线程支持等功能）。

所以不要想像说下面列举的工具能够对Java做AOT编译，然后运行时还搭配Oracle JDK / OpenJDK来使用。

来看看一些具体实现。

IBM JDK6+ - Enhance performance with class sharing

IBM JDK是主流JDK之一，并且提供了AOT编译的功能。

这个AOT编译的主要目的是提高启动速度，以及在多个进程之间共享AOT编译出来的机器码。

被AOT编译的代码在运行时还可以再次被JIT编译，这样既能提高启动速度，又不会影响最高速度（peak performance）。

这个AOT编译用的编译器就是IBM J9 VM里的JIT编译器，只是让它以AOT模式来工作。这点跟NGen有点类似（NGen也是直接用CLR里的JIT编译器来生成native image）。跟它搭配使用的runtime自然就是完整的J9 VM。

不

过跟NGen不同的是，NGen是真的在程序执行前就做了编译，而IBM

J9提供的AOT编译其实是在用户第一次运行程序时把特殊模式的JIT编译生成的代码缓存到磁盘上，后续执行的时候就可以直接使用该缓存里的机器码。所以

IBM把这个功能叫做“dynamic AOT”。

Excelsior JET

一个比较成熟的商业的Java AOT编译解决方案。仅支持x86上的若干操作系统。

这个AOT编译器是自己写的一个私有的编译器，其搭配使用的runtime也是私有的。它支持几种不同的编译模式，搭配使用的runtime可以完全不带解释器/JIT编译器，只带有GC、线程支持等功能，也可以带有更完整的JVM功能。

现在可能很多人都知道Android的ART，而对Java世界里的老前辈们没啥认知。其实ART的AOT编译与解释器/JIT混合的方式，跟Excelsior JET（以及下面提到的GCJ）是相当相似的。

GCJ

一个开源的Java运行时系统，支持AOT编译、解释执行与JIT编译。GCJ是GCC的一部分。在OpenJDK流行起来之前，通常各种Linux发行版带的Java实现会是GCJ。

RoboVM

一个让Java程序可以运行在iOS上的开源解决方案。

iOS不允许第三方程序做运行时代码生成（也就是不允许JIT编译），所以在iOS上运行程序要么得AOT编译，要么只能解释执行。Oracle ADF选择使用一个只能解释执行的JVM来支持Java程序，而RoboVM选择使用AOT编译。

RoboVM的AOT编译器借助了不少现成的框架来实现。其中最重要的两个是Soot与LLVM，前者解决编译器前端、后者解决编译器后端，RoboVM自己只要解决一些跟runtime搭配的地方就好了。

RoboVM配套的runtime是自己写的一个比较小的runtime。

VMKit

VMKit是一个基于许多现成的库组合起来实现的VM，主要可以用作JVM，也可配置为一个CLI。

VMKit支持AOT编译。它的JIT与AOT编译器都是基于LLVM实现的。不过实现得比较粗糙嗯。

Avian

Avian不是一个完整的JVM，只支持Java的一个比较有用的子集。很多时候也够用了。

它可以支持AOT编译。

ART (Android Runtime)

ART和Dalvik VM虽然不直接实现Java字节码，但从整个系统的角度看它们俩都是不折不扣的Java系统。

ART支持AOT编译与解释执行。Java程序的启动速度在ART上是比在Dalvik VM上快多了。

只想强调一点：ART的AOT编译并不依赖LLVM。详情请参考另外几个回答：

Android 中的 LLVM 主要做什么？ - RednaxelaFX 的回答

如何看待微软新出的LLILC，一个新的基于LLVM的CoreCLR JIT/AOT编译器？ - RednaxelaFX 的回答

Jikes RVM、Maxine VM、Joeq

这三个是元循环Java虚拟机的代表。关于元循环虚拟机（metacircular VM），请参考另一个回答：用 JavaScript 写成的 JavaScript 解释器，意义是什么？ - RednaxelaFX 的回答

它们都是用纯Java实现的Java虚拟机，而且都能独立运行，也就是说可以自举（bootstrap）。要实现bootstrap，它们就必然需要能支持AOT编译的编译器。

所以说在这类实现里，AOT编译不是为了提高启动速度，而是为了实现bootstrap的根本需求。有趣的是，它们可以（在一定范围内）支持定制boot image的内容，也就是说可以让Java应用程序与JVM一起AOT编译构成boot image。

JNode - Java New Operating System Design Effort

JNode是一个用纯Java实现的操作系统。这比上面三个元循环Java虚拟机还要更进一步，可以在裸硬件上bootstrap。自然，它也需要一个支持AOT编译的编译器，同样是出于实现的根本需求。

Oracle Labs: Substrate VM

Substrate VM是Oracle Labs的一个研究项目，跟Graal编译器与Truffle框架搭配使用。它实现了一个很小型的、可定制的runtime，可以让基于Truffle实现的编程语言可以脱离标准JVM独立运行。

这里，Substrate VM提供的是runtime的功能，真正的AOT编译器是Graal。

Oracle/Sun JDK

其

实Sun以前在JDK6时期研究过实现AOT编译，但是当时选择的实现方式比较取巧。后来发现效果并不理想，而且在有了多层编译系统（tiered

compilation system）之后这个AOT编译的原型实现在启动速度上根本没有优势，就把这个项目搁置了。具体细节抱歉我无法多说。

但是Oracle JDK在计划提供新的AOT编译支持。或许会在未来版本的Oracle JDK里出现。请拭目以待。

目前Oracle在公开场合介绍这个AOT编译器的主要资料是JVMLS 2015上的一个演讲，Java Goes AOT - JVMLS 2015 （打不开请自备工具…），有兴趣的同学可以参考下。它是一个基于Graal编译器的实现。

IKVM.NET

前面说的AOT编译解决方案都是把Java（包含Java字节码的Class文件）编译到native code。http://IKVM.NET是一种比较特殊的方案，把Java Class文件编译到.NET Assembly，然后可以用任意CLI（Common Language Infrastructure）实现上运行，例如微软的CLR和Xamarin的Mono。

借助CLR的NGen和Mono的AOT编译，http://IKVM.NET生成的.NET Assembly还可以进一步被编译为native code。这样也算间接达到了AOT编译的目的。

这不是拿来搞笑的。http://IKVM.NET的作者做过一个演示，在Windows上基于IKVM+NGen来运行Eclipse，启动速度比当时的Oracle JDK6快得多…

跟http://IKVM.NET类似的项目以前还有几个，例如Ja.NET（官网挂了，介绍可以看InfoQ的新闻稿）。但活到现在的恐怕就IKVM.NET一家了。

---