https://www.zhihu.com/question/274042223

Java自上世纪诞生以来，凭借其跨平台运行的能力，再加上庞大的生态圈，在众多语言中脱颖而出，且稳居第一座椅。

可惜，Docker 横空出世了。

加上 K8s 的完美配合，更快速的启动时间、持续支付和部署、更高效的利用系统资源 已经是许多工程师的追求了。

再加上 “云原生” 、serverless 的出现，Java 相对于 Go、 Node.js 这种语言来说，实在是太 “臃肿”了。

虽然说 SprinBoot 也算是给 Java 挣足了面子，进一步奠定了统治定位，快速启动、脚手架一键配置，快速部署，但仍然不足够。

如果你用过 go、nodejs，再对比 Java ，你就会发现 Java 的性能是较差的，且 冷启动开销较大 。在 Serverless 场景下，难以竞争。

虽然 JVM 也不断的优化，比如引入了：

• Java 引入了实时编译技术（JIT，Just In time）、AOT (Ahead-Of-Time - 预先编译)
• C1（Client Complier）、C2（Server Complier） 模式
• 热点探测技术

JIT 带来了非常显著的性能优势的同时，也存在一些问题：

1. 启动更慢，一次性全部编译耗时将会导致JAVA程序启动时间大幅度延长

2. 消耗内存，编译后的机器码需要占用大量内存

总结就是，虽然性能提升了，但是编译、启动 还是很耗时，占用的资源也相对较多。

那怎么办，GraalVM 来替代。

与传统 Java 运行模型相比，GraalVM 的静态编译运行模型有两大特点：

一是静态编译后的可执行程序已经是本地程序，而且自包含了轻量级运行时支持，因此不再额外需要 Java 虚拟机。没有了 JVM，自然也就消除了图 1 中的响应时间无穷大阶段，使得应用程序达到即起即用的状态。另外，因为 JVM 的运行也需要消耗一部分内存，去掉 JVM 后应用程序的内存占用也大幅降低。

二是静态编译后的程序也经过了众多的编译优化，运行时不再需要经过解释执行和 JIT 编译，既避免了解释执行的低效，也避免了 JIT 编译的 CPU 开销，还解决了传统 Java 执行模型中无法充分预热，始终存在解释执行的问题，因此可以保证应用程序始终以稳定的性能执行，不会出现性能波动。

这两个基本特点解决了 Java 程序冷启动问题—JVM 初始化的开销和从解释执行到 JIT 编译执行的开销，因此静态编译后的 Java 程序可以获得极速启动的效果。