进击的 Java ，云原生时代的蜕变(5)

通常而言，HotSpot JIT 比 AOT 可以进行更加全面和深入的执行路径优化，从而有更高的运行效率。为了解决这个矛盾，OpenJ9 的 AOT SCC 只在启动阶段生效，在后续运行中会继续利用JIT进行分支预测、代码内联等深度编译优化。

HotSpot 在 Class Data Sharing (CDS) 和 AOT 方面也有了很大进展，但是 IBM J9 在这方面更加成熟。期待阿里的 Dragonwell 也提供相应的优化支持。

思考：与 C/C++，Golang, Rust 等静态编译语言不同，Java 采用 VM 方式运行，提升了应用可移植性的同时牺牲了部分性能。我们是否可以将 AOT 做到极致?完全移除字节码到本地代码的编译过程?

原生代码编译

为了将 Java 应用编译成本地可执行代码，我们首先要解决 JVM 和应用框架在运行时的动态性挑战。JVM 提供了灵活的类加载机制，Spring 的依赖注入(DI，Dependency-injection)可以实现运行时动态类加载和绑定。在 Spring 框架中，反射，Annotation 运行时处理器等技术也被广泛应用。这些动态性一方面提升了应用架构的灵活性和易用性，另一方面也降低了应用的启动速度，使得 AOT 原生编译和优化变得非常复杂。

为了解决这些挑战，社区有很多有趣的探索，Micronaut 是其中一个优秀代表。与 Spring 框架序不同，Micronaut 提供了编译时的依赖注入和AOP处理能力，并最小化反射和动态代理的使用。Micronaut 应用有着更快的启动速度和更低的内存占用。更加让我们更感兴趣的是 Micronaut 支持与 GraalVM 配合，可以将 Java 应用编译成为本地执行代码全速运行。

注：GraalVM 是 Oracle 推出的一种新型通用虚拟机，支持多种语言，可以将Java应用程序编译为本地原生应用。

下面开始我们的探险，我们利用 Mitz 提供的 Micronaut 版本 PetClinic 示例工程并做了一点点调整。(使用 Graal VM 19.2)

$ git clone https://github.com/denverdino/micronaut-petclinic 
$ cd micronaut-petclinic 

其中 Docker 镜像的内容如下：

$ cat Dockerfile 
FROM maven:3.6.1-jdk-8 as build 
COPY ./ /micronaut-petclinic/ 
WORKDIR /micronaut-petclinic 
RUN mvn package 
FROM oracle/graalvm-ce:19.2.0 as graalvm 
RUN gu install native-image 
WORKDIR /work 
COPY --from=build /micronaut-petclinic/target/micronaut-petclinic-*.jar . 
RUN native-image --no-server -cp micronaut-petclinic-*.jar 
FROM frolvlad/alpine-glibc 
EXPOSE 8080 
WORKDIR /app 
COPY --from=graalvm /work/petclinic . 
CMD ["/app/petclinic"] 

其中：

• 在 "build" 阶段，利用Maven构建 Micronaut 版本的 PetClinic 应用
• 在 "graalvm" 阶段，我们通过 native-image 将 PetClinic jar 文件转化成可执行文件
• 在最终阶段，将本地可执行文件加入一个 Alpine Linux 基础镜像

构建应用：

$ docker-compose build 

启动测试数据库：

$ docker-compose up db 

（编辑：ASP站长网）