GraalVM static compilation in web container application

1.  Java Web容器应用运行回顾

在介绍静态编译在Web容器的应用之前，我们先来简单回顾一下，非静态编译或者说常规的Java Web容器的运行过程。

如上图所示，一个正常的Java应用，从编写代码、打包、运行过程，首先需要写一个.java的源文件，然后通过javac把源文件打包编译，编译成.class的字件码。运行过程就是虚拟机加载字节码做解释执行，或者在解释执行之后，对热点代码进行即时编译，这个就是Java应用的运行过程。

在这个过程里，因为有了字节码的概念，让Java Web容器或者Java应用实现写一次，让应用实现跟平台无关，这是它的设计优势。

但这个优势是否就无可挑剔能够帮助Java应用广泛应用在各种场景下了呢？答案是否定的。例如：有的时候我们会发现写一个很简单的Java程序的demo，代码可能不多，逻辑也不复杂，它的启动时间短则几秒或者十多秒，它的内存占用从几十兆到上百兆不等。但如果我们的应用想要快速扩缩容，就会对我们非常不利。

这个现象产生的原因，就如上图所示，首先会有一个虚拟机启动的过程，对应图中红色的部分。在Java程序没执行之前，会首先把虚拟机加载到内存里去。当虚拟机加载到内存里后，它就会去做类加载，就是应用程序的加载过程。就如图中浅蓝色的CL过程，它会把应用程序加载进去。之后JVM就会对程序进行解释执行了，这里要注意一下，它是解释执行不是编译，对应图中浅绿色的部分。

当解释执行产生，程序就运行起来了，就可以处理请求了。处理请求的过程中，它就会进行垃圾回收，对应图中黄色的部分。当程序逐步的运行时，一些方法和一些代码段会被反复的执行。在执行的次数很高的情况下，解释执行的性能就会变得比较差了。

这个时候在虚拟机里，会有一个叫即时编译JIT的概念，对应图中白色的部分。在我们的程序中它有一套规则，比如在一个时间内一个方法执行了500次，我们可能觉得它是个热点代码。然后我们对相关的代码通过JIT进行即时编译，对应图中绿色的部分，它是和机器强相关的编译后的汇编代码，它的执行效率是比较高的。

所以从这张图我们可以看到，一个Java应用从启动到运行到性能的峰值，中间还是会经过一个比较长的时间，包括虚拟机初始化、应用初始化、应用预热等等过程。这就是Java应用/Java Web应用启动比较耗时的原因。

另外一个问题是，为什么Java应用写一个比较简单的逻辑，最终的占用内存会比较高呢？这个的原因从图中也可以看到，程序什么都不执行，就会加载一个虚拟机，它也会有一定的内存大小。如果我们用一些工具，比如NMT工具，我们可以打印一下我们的应用，也可以看到GC本身占用的内存，它们都会有一定的内存。

另外，也和解释执行编译的过程有关。比如C/C++语言，会在执行之前做编译，编译的过程就有优化。而Java程序它是解释执行，它在解释的过程中会把我们的代码全部逐步地加载到内存中，因为它不知道哪一块代码需要，哪一块不需要，所以实际加载的代码会比实际要执行的代码要多很多。这个就是应用在运行过程中的额外的内存开销。

带你读《Apache Tomcat的云原生演进》——GraalVM static compilation in web container application（2）https://developer.aliyun.com/article/1377534