关于java:探究-Java-应用的启动速度优化

简介： Java 的执行效率十分高，约为最快的C语言的一半。这在支流的编程语言中，仅次于C、Rust 和 C++。但在高性能的背地，Java 的启动性能差也令人印象粗浅，大家印象中的 Java 轻便迟缓的印象也大多来源于此。高性能和快启动速度仿佛有一些相悖，本文将和大家一起探索两者是否能够兼得。

作者 | 梁希
起源 | 阿里技术公众号

一高性能和快启动速度，是否鱼和熊掌兼得？

Java 作为一门面向对象编程语言，在性能方面的卓越体现自成一家。

《Energy Efficiency across Programming Languages，How Does Energy, Time, and Memory Relate?》这份报告调研了各大编程语言的执行效率，尽管场景的丰盛水平无限，然而也可能让咱们见微知著。

从表中，咱们能够看到，Java 的执行效率十分高，约为最快的C语言的一半。这在支流的编程语言中，仅次于C、Rust 和 C++。

Java 的优异性能得益于 Hotspot 中十分优良的 JIT 编译器。Java 的 Server Compiler(C2) 编译器是 Cliff Click 博士的作品，应用了 Sea-of-Nodes 模型。而这项技术，也通过工夫证实了它代表了业界的最先进程度：

驰名的V8（JavaScript引擎）的 TurboFan 编译器应用了雷同的设计，只是用更加古代的形式去实现；
Hotspot 应用 Graal JVMCI 做 JIT 时，性能根本与 C2 持平；
Azul 的商业化产品将 Hotspot 中的 C2 compiler 替换成 LLVM，峰值性能和 C2 也是持平。

在高性能的背地，Java 的启动性能差也令人印象粗浅，大家印象中的 Java 轻便迟缓的印象也大多来源于此。高性能和快启动速度仿佛有一些相悖，本文将和大家一起探索两者是否能够兼得。

二 Java 启动慢的根因

1 框架简单

JakartaEE 是 Oracle 将 J2EE 捐献给 Eclipse 基金会后的新名字。Java 在1999年推出时便公布了 J2EE 标准，EJB(Java Enterprise Beans) 定义了企业级开发所须要的平安、IoC、AOP、事务、并发等能力。设计极度简单，最根本的利用都须要大量的配置文件，应用十分不便。

随着互联网的衰亡，EJB 逐步被更加轻量和收费的 Spring 框架取代，Spring 成了 Java 企业开发的事实标准。Spring 尽管定位更加轻量，然而骨子里仍然很大水平地受 JakartaEE 的影响，比方晚期版本大量 xml 配置的应用、大量 JakartaEE 相干的注解(比方JSR 330依赖注入)，以及标准(如JSR 340 Servlet API)的应用。

但 Spring 仍是一个企业级的框架，咱们看几个 Spring 框架的设计哲学：

在每一层都提供选项，Spring 能够让你尽可能的推延抉择。
适应不同的视角，Spring 具备灵活性，它不会强制为你决定该怎么抉择。它以不同的视角反对宽泛的利用需要。
放弃弱小的向后兼容性。

在这种设计哲学的影响下，必然存在大量的可配置和初始化逻辑，以及简单的设计模式来撑持这种灵活性。咱们通过一个试验来看：

咱们跑一个spring-boot-web的helloword，通过-verbose:class能够看到依赖的class文件：

$ java -verbose:class -jar myapp-1.0-SNAPSHOT.jar | grep spring | head -n 5[Loaded org.springframework.boot.loader.Launcher from file:/Users/yulei/tmp/myapp-1.0-SNAPSHOT.jar][Loaded org.springframework.boot.loader.ExecutableArchiveLauncher from file:/Users/yulei/tmp/myapp-1.0-SNAPSHOT.jar][Loaded org.springframework.boot.loader.JarLauncher from file:/Users/yulei/tmp/myapp-1.0-SNAPSHOT.jar][Loaded org.springframework.boot.loader.archive.Archive from file:/Users/yulei/tmp/myapp-1.0-SNAPSHOT.jar][Loaded org.springframework.boot.loader.LaunchedURLClassLoader from file:/Users/yulei/tmp/myapp-1.0-SNAPSHOT.jar]$ java -verbose:class -jar myapp-1.0-SNAPSHOT.jar | egrep '^\[Loaded' > classes$ wc classes    7404   29638 1175552 classes

class 个数达到惊人的7404个。

咱们再比照下 JavaScript 生态，应用罕用的 express 编写一个根本利用：

const express = require('express')const app = express()app.get('/', (req, res) => {  res.send('Hello World!')})    app.listen(3000, () => {    console.log(`Example app listening at http://localhost:${port}`)})

咱们借用 Node 的 debug 环境变量剖析：

NODE_DEBUG=module node app.js 2>&1  | head -n 5MODULE 18614: looking for "/Users/yulei/tmp/myapp/app.js" in ["/Users/yulei/.node_modules","/Users/yulei/.node_libraries","/usr/local/Cellar/node/14.4.0/lib/node"]MODULE 18614: load "/Users/yulei/tmp/myapp/app.js" for module "."MODULE 18614: Module._load REQUEST express parent: .MODULE 18614: looking for "express" in ["/Users/yulei/tmp/myapp/node_modules","/Users/yulei/tmp/node_modules","/Users/yulei/node_modules","/Users/node_modules","/node_modules","/Users/yulei/.node_modules","/Users/yulei/.node_libraries","/usr/local/Cellar/node/14.4.0/lib/node"]MODULE 18614: load "/Users/yulei/tmp/myapp/node_modules/express/index.js" for module "/Users/yulei/tmp/myapp/node_modules/express/index.js"$ NODE_DEBUG=module node app.js 2>&1  | grep ': load "' > js$ wc js      55     392    8192 js

这里只依赖了区区55个 js 文件。

尽管拿 spring-boot 和 express 比并不偏心。在 Java 世界也能够基于 Vert.X、Netty 等更加轻量的框架来构建利用，然而在实践中，大家简直都会不假思索地抉择 spring-boot，以便享受 Java 开源生态的便当。

2 一次编译，到处运行

Java 启动慢是因为框架简单吗？答案只能说框架简单是启动慢的起因之一。通过 GraalVM 的 Native Image 性能联合 spring-native 个性，能够将 spring-boot 利用的启动工夫缩短约十倍。

Java 的 Slogan 是 "Write once, run anywhere"(WORA)，Java 也的确通过字节码和虚拟机技术做到了这一点。

WORA 使得开发者在 MacOS 上开发调试实现的利用能够疾速部署到 Linux 服务器，跨平台性也让 Maven 核心仓库更加易于保护，促成了 Java 开源生态的凋敝。

咱们来看一下 WORA 对 Java 的影响：

Class Loading

Java 通过 class 来组织源码，class 被塞进 JAR 包以便组织成模块和散发，JAR 包实质上是一个 ZIP 文件：

$ jar tf slf4j-api-1.7.25.jar | headMETA-INF/META-INF/MANIFEST.MForg/slf4j/org/slf4j/event/EventConstants.classorg/slf4j/event/EventRecodingLogger.classorg/slf4j/event/Level.class

每个 JAR 包都是性能上比拟独立的模块，开发者就能够按需依赖特定性能的 JAR，这些 JAR 通过 class path 被JVM 所知悉，并进行加载。

依据，执行到 new 或者 invokestatic 字节码时会触发类加载。JVM 会将管制交给 Classloader ，最常见的实现 URLClassloader 会遍历 JAR 包，去寻找相应的 class 文件：

for (int i = 0; (loader = getNextLoader(cache, i)) != null; i++) {    Resource res = loader.getResource(name, check);    if (res != null) {        return res;    }}

因而查找类的开销，通常和 JAR 包个数成正比，在大型利用的场景下个数会上千，导致整体的查找耗时很高。

当找到 class 文件后 JVM 须要校验 class 文件的是否非法，并解析成外部可用的数据结构，在 JVM 中叫做 InstanceKlass ，听过 javap 窥视一下class文件蕴含的信息：

$ javap -p SimpleMessage.classpublic class org.apache.logging.log4j.message.SimpleMessage implements org.apache.logging.log4j.message.Message,org.apache.logging.log4j.util.StringBuilderFormattable,java.lang.CharSequence {  private static final long serialVersionUID;  private java.lang.String message;  private transient java.lang.CharSequence charSequence;  public org.apache.logging.log4j.message.SimpleMessage();  public org.apache.logging.log4j.message.SimpleMessage(java.lang.String);

这个构造蕴含接口、基类、静态数据、对象的 layout、办法字节码、常量池等等。这些数据结构都是解释器执行字节码或者JIT编译所必须的。

Class initialize

当类被加载实现后，要实现初始化能力理论创建对象或者调用静态方法。类初始化能够简略了解为动态块：

public class A {  private final static String JAVA_VERSION_STRING = System.getProperty("java.version");    private final static Set<Integer> idBlackList = new HashSet<>();    static {        idBlackList.add(10);        idBlackList.add(65538);    }}

下面的第一个动态变量 JAVA_VERSION_STRING 的初始化在编译成字节码后也会成为动态块的一部分。

类初始化有如下特点：

只执行一次；
有多线程尝试拜访类时，只有一个线程会执行类初始化，JVM 保障其余线程都会阻塞期待初始化实现。

这些特点非常适合读取配置，或者结构一些运行时所须要数据结构、缓存等等，因而很多类的初始化逻辑会写的比较复杂。

Just In Time compile

Java 类在被初始化后就能够实例对象，并调用对象上的办法了。解释执行相似一个大的 switch..case 循环，性能比拟差：

while (true) {  switch(bytocode[pc]) {        case AALOAD:            ...            break;        case ATHROW:            ...            break;    }}

咱们用 JMH 来跑一个 Hessian 序列化的 Micro Benchmark 试验：

$ java -jar benchmarks.jar hessianIOBenchmark                      Mode  Cnt       Score   Error  UnitsSerializeBenchmark.hessianIO  thrpt       118194.452          ops/s$ java -Xint -jar benchmarks.jar hessianIOBenchmark                      Mode  Cnt     Score   Error  UnitsSerializeBenchmark.hessianIO  thrpt       4535.820          ops/s

第二次运行的 -Xint 参数管制了咱们只应用解释器，这里差了26倍，这是间接机器执行的执行和解释执行的差别带来的。这个差距跟场景的关系很大，咱们通常的经验值是50倍。

咱们来进一步看下 JIT 的行为：

$ java -XX:+PrintFlagsFinal -version | grep CompileThreshold     intx Tier3CompileThreshold                     = 2000                                {product}     intx Tier4CompileThreshold                     = 15000                               {product}

这里是两项 JDK 外部的 JIT 参数的数值，咱们暂不对分层编译原理做过多介绍，能够参考Stack Overflow。Tier3 能够简略了解为(client compiler)C1，Tier4 是 C2。当一个办法解释执行2000次会进行 C1 编译，当 C1 编译后执行15000次后就会 C2 编译，真正达到文章结尾的 C 的一半性能齐全体。

在利用刚启动阶段，办法还没有齐全被JIT编译实现，因而大部分状况停留在解释执行，影响了利用启动的速度。

三如何优化 Java 利用的启动速度

后面咱们花了大量的篇幅剖析了 Java 利用启动慢的次要起因，总结下就是：

受到 JakartaEE 影响，常见框架思考复用和灵活性，设计得比较复杂；
为了跨平台性，代码是动静加载，并且动静编译的，启动阶段加载和执行耗时；

这两者综合起来造成了 Java 利用启动慢的现状。

Python 和 Javascript 都是动静解析加载模块的，CPyhton 甚至没有 JIT，实践上启动不会比 Java 快很多，然而它们并没有应用很简单的利用框架，因而整体不会感触到启动性能的问题。

尽管咱们无奈轻易去扭转用户对框架的应用习惯，然而能够在运行时层面进行加强，使启动性能尽量凑近 Native image。OpenJDK 官网社区也始终在致力解决启动性能问题，那么咱们作为一般 Java 开发者，是否能够借助OpenJDK的最新个性来帮助咱们晋升启动性能呢？

Class Loading

通过 JarIndex 解决 JAR 包遍历问题，不过该技术过于古老，很难在古代的囊括了tomcat、fatJar的我的项目里应用起来
AppCDS 能够解决 class 文件解析解决的性能问题
Class Initialize: OpenJDK9 退出了 HeapArchive，能够长久化一部分类初始化相干的 Heap 数据，不过只有寥寥数个 JDK 外部 class (比方 IntegerCache )能够被减速，没有凋谢的应用形式。
JIT预热: JEP295 实现了 AOT 编译，然而存在 bug，使用不当会引发程序正确性能问题。在性能上没有失去很好的 tuning，大部分状况下看不到成果，甚至会呈现性能回退。

面对 OpenJDK 上述个性所存在的问题，Alibaba Dragonwell 对以上各项技术进行了研发优化，并与云产品进行了整合，用户不须要投入太多精力就能够轻松地优化启动工夫。

1 AppCDS

CDS(Class Data Sharing)在Oracle JDK1.5被首次引入，在Oracle JDK8u40中引入了AppCDS，反对JDK以外的类，然而作为商业个性提供。随后Oracle将AppCDS奉献给了社区，在JDK10中CDS逐步欠缺，也反对了用户自定义类加载器(又称AppCDS v2)。

面向对象语言将对象(数据)和办法(对象上的操作)绑定到了一起，来提供更强的封装性和多态。这些个性都依赖对象头中的类型信息来实现，Java、Python语言都是如此。Java对象在内存中的layout如下：

+-------------+|  mark       |+-------------+|  Klass*     |+-------------+|  fields     ||             |+-------------+

mark 示意了对象的状态，包含是否被加锁、GC年龄等等。而Klass*指向了形容对象类型的数据结构 InstanceKlass :

//  InstanceKlass layout://    [C++ vtbl pointer           ] Klass//    [java mirror                ] Klass//    [super                      ] Klass//    [access_flags               ] Klass//    [name                       ] Klass//    [methods                    ]//    [fields                     ]...

基于这个构造，诸如 o instanceof String 这样的表达式就能够有足够的信息判断了。要留神的是InstanceKlass构造比较复杂，蕴含了类的所有办法、field等等，办法又蕴含了字节码等信息。这个数据结构是通过运行时解析class文件取得的，为了保障安全性，解析class时还须要校验字节码的合法性( 非通过 Javac 产生的办法字节码很容易引起 JVM crash)。

CDS 能够将这个解析、校验产生的数据结构存储(dump)到文件，在下一次运行时重复使用。这个dump产物叫做Shared Archive，以jsa后缀(Java shared archive)。

为了缩小 CDS 读取 jsa dump 的开销，防止将数据反序列化到InstanceKlass的开销，jsa 文件中的存储layout和InstanceKlass对象齐全一样，这样在应用 jsa 数据时，只须要将 jsa 文件映射到内存，并且让对象头中的类型指针指向这块内存地址即可，非常高效。

Object:+-------------+|  mark       |         +-------------------------++-------------+         |classes.jsa file         ||  Klass*     +--------->java_mirror|super|methods|+-------------+         |java_mirror|super|methods||  fields     |         |java_mirror|super|methods||             |         +-------------------------++-------------+

AppCDS 对 customer class loader 力不从心

jsa 中存储的InstanceKlass是对class文件解析的产物。对于 boot classloader (就是加载jre/lib/rt.jar上面的类的classloader)和 system(app) classloader (加载-classpath上面的类的 classloader )，CDS有外部机制能够跳过对 class文件的读取，仅仅通过类名在 jsa 文件中匹配对应的数据结构。

Java 还提供用户自定义类加载器(custom class loader)的机制，用户通过Override本人的 Classloader.loadClass() 办法能够高度定制化获取类的逻辑，比方从网络上获取、间接在代码中动静生成都是可行的。为了加强AppCDS的安全性，防止因为从CDS加载了类定义反而取得了非预期的类，AppCDS customer class loader须要通过如下步骤：

调用用户定义的Classloader.loadClass()，拿到class byte stream
计算class byte stream的checksum，与jsa中的同类名构造的checksum比拟
如果匹配胜利则返回jsa中的InstanceKlass，否则持续应用slow path解析class文件

咱们看到许多场景下，上述的第一步占据了类加载耗时的大头，此时 AppCDS 就显得力不从心了。举例来说：

bar.jar +- com/bar/Bar.class baz.jar +- com/baz/Baz.class foo.jar +- com/foo/Foo.class

class path 蕴含如上的三个jar包，在加载class com.foo.Foo 时，大部分Classloader实现(包含URLClassloader、tomcat、spring-boot)都抉择了最简略的策略(过早的优化是万恶之源): 依照jar包呈现在磁盘的程序一一尝试抽取 com/foo/Foo.class 这个文件。

JAR 包应用了 zip 格局作为存储，每次类加载都须要遍历classpath下的 JAR 包们，尝试从 zip 中抽取单个文件，来确保存在的类能够被找到。假如有N个 JAR 包，那么均匀一个类加载须要尝试拜访N/2个zip文件。

在咱们的一个实在场景下，N达到2000，此时 JAR 包查找开销十分大，并且远大于InstanceKlass解析的开销。面对此类场景 AppCDS 技术就力不从心了。

JAR Index

依据jar文件标准，JAR 文件是一种应用 zip封装，并应用文本在META-INF目录存储元信息的格局。该格局在设计时曾经思考了应答上述的查找场景，这项技术叫做JAR Index。

假如咱们要在上述的bar.jar、baz.jar、foo.jar中查找一个class，如果可能通过类型com.foo.Foo，立即推断出具体在哪个jar包，就能够防止上述的扫描开销了。

JarIndex-Version: 1.0foo.jarcom/foobar.jarcom/barbaz.jarcom/baz

通过 JAR Index 技术，能够生成出上述的索引文件INDEX.LIST。加载到内存后成为一个HashMap：

com/bar --> bar.jarcom/baz --> baz.jarcom/foo --> foo.jar

当咱们看到类名com.foo.Foo，能够依据包名 com.foo 从索引中得悉具体的jar包foo.jar，迅速抽取class文件。

Jar Index 技术看似解决了咱们的问题，然而这项技术非常古老，很难在古代利用中被应用起来：

jar i 依据 META-INF/MANIFEST.MF 中的 Class-Path 属性产生索引文件，古代我的项目简直不保护这个属性
只有 URLClassloader 反对JAR Index
要求带索引的jar尽量呈现在 classpath 的后面

Dragonwell 通过 agent 注入使得 INDEX.LIST 可能被正确地生成，并呈现在 classpath 的适合地位来帮忙利用晋升启动性能。

2 类提前初始化

类的 static block 中的代码执行咱们称之为类初始化，类加载实现后必须执行完初始化代码能力被应用(创立instance、调用 static 办法)。

很多类的初始化实质上只是结构一些static field：

class IntegerCache {    static final Integer cache[];    static {        Integer[] c = new Integer[size];        int j = low;        for(int k = 0; k < c.length; k++)            c[k] = new Integer(j++);        cache = c;    }}

咱们晓得 JDK 对 box type 中罕用的一段区间有缓存，防止过多的反复创立，这段数据就须要提前结构好。因为这些办法只会被执行一次，因而是以纯解释的形式执行的，如果能够长久化几个static字段的形式来防止调用类初始化器，咱们就能够拿到提前初始化好的类，缩小启动工夫。

将长久化加载到内存应用最高效的形式是内存映射：

int fd = open("archive_file", O_READ);struct person *persons = mmap(NULL, 100 * sizeof(struct person),                              PROT_READ, fd, 0);int age = persons[5].age;

C语言简直是间接面向内存来操作数据的，而Java这样的高级语言都将内存形象成了对象，有mark、Klass*等元信息，每次运行之间都存在肯定的变动，因而须要更加简单的机智来取得高效的对象长久化。

Heap Archive简介

OpenJDK9 引入了HeapArchive能力，OpenJDK12中heap archive 被正式应用。顾名思义，Heap Archive技术能够将堆上的对象长久化存储下来。

对象图被提前被构建好后放进archive，咱们将这个阶段称为dump；而应用archive里的数据称为运行时。dump和运行时通常不是一个过程，但在某些场景下也能够是同一个过程。

回顾下应用AppCDS后的内存布局，对象的Klass*指针指向了SharedArchive中的的数据。AppCDS对InstanceKlass这个元信息进行了长久化，如果想要复用长久化的对象，那么对象头的类型指针必须也要指向一块被长久化过的元信息，因而HeapArchive技术是依赖AppCDS的。

为了适应多种场景，OpenJDK的HeapArchive还提供了Open和Closed两种级别：

上图是容许的援用关系：

Closed Archive

不容许援用Open Archive 和Heap中的对象
能够援用Closed Archive外部的对象
只读，不可写

Open Archive

能够援用任何对象
可写

这样设计的起因是对于一些只读构造，放在Closed Archive 中能够做到对GC齐全无开销。

为什么只读？设想一下，如果Closed Archive中的对象A援用了heap中的对象B，那么当对象B挪动时，GC须要修改A中指向B的field，这会带来GC开销。
利用 Heap Archive 提前做类初始化

反对这种构造后，在类加载后，将static变量指向被Archive的对象，即可实现类初始化：

class Foo {  static Object data;}                 +                  |        <---------+Open Archive Object:+-------------+|  mark       |         +-------------------------++-------------+         |classes.jsa file         ||  Klass*     +--------->java_mirror|super|methods|+-------------+         |java_mirror|super|methods||  fields     |         |java_mirror|super|methods||             |         +-------------------------++-------------+

3 AOT编译

除去类的加载，办法的前几次执行因为没有被JIT编译器给编译，字节码在解释模式下执行。依据本文上半局部的剖析，解释执行速度约为JIT编译后的几十分之一，代码解释执行慢也启动慢的一大首恶。

传统的C/C++等语言都是间接编译到指标平台的native机器码。随着大家意识到Java、JS等解释器JIT语言的启动预热问题，通过AOT将字节码间接编译到native代码这种形式逐步进入公众视线。

wasm、GraalVM、OpenJDK都不同水平地反对了AOT编译，咱们次要围绕JEP295引入的jaotc工具优化启动速度。

留神这里的术语应用：

JEP295应用AOT是将class文件中的办法一一编译到native代码片段，通过Java虚拟机在加载某个类后替换办法的的入口到AOT代码。

而GraalVM的的Native Image性能是更加彻底的动态编译，通过一个用Java代码编写的小型运行时SubstrateVM，该运行时和利用代码一起被动态编译到可执行的文件(相似Go)，不再依赖JVM。该做法也是一种AOT，然而为了辨别术语，这里的AOT单指JEP295的形式。

AOT个性初体验

通过JEP295的介绍，咱们能够疾速体验AOT

jaotc 命令会调用Graal编译器对字节码进行编译，产生 libHelloWorld.so 文件。这里产生的so文件容易让人误以为会间接像JNI一样调用进编译好的库代码。然而这里并没有齐全应用ld的加载机制来运行代码，so文件更像是当做一个 native 代码的容器。hotsopt runtime 在加载 AOT so 后须要进行进一步的动静链接。在类加载后hotspot 会主动关联 AOT 代码入口，对于下次办法调用应用 AOT 版本。而 AOT 生成的代码也会被动与 hotspot 运行时交互，在aot、解释器、JIT 代码间互相跳转。

1）AOT 的一波三折

看起来JEP295曾经实现了一套齐备的AOT体系，然而为何不见这项技术被大规模应用？在 OpenJDK 的各项新个性中，AOT 算得上是命途多舛。

2）多 Classloader 问题

JDK-8206963: bug with multiple class loaders

这是在设计上没有思考到Java的多 Classloader 场景，当多个 Classloader 加载的同名类都应用了 AOT 后，他们的 static field 是共享的，而依据 Java 语言的设计，这部分数据应该是隔开的。

因为没有能够疾速修复这个问题的计划，OpenJDK 仅仅是增加了如下代码：

ClassLoaderData* cld = ik->class_loader_data();  if (!cld->is_builtin_class_loader_data()) {    log_trace(aot, class, load)("skip class  %s  for custom classloader %s (%p) tid=" INTPTR_FORMAT,                                ik->internal_name(), cld->loader_name(), cld, p2i(thread));    return false;}

对于用户自定义类加载器不容许应用 AOT。从这里曾经能够初步看出该个性在社区层面曾经逐步不足保护。

在这种状况下，尽管通过 class-path 指定的类仍然能够应用 AOT，然而咱们罕用的 spring-boot、Tomcat 等框架都须要通过 Custom Classloader 加载利用代码。能够说这一扭转切掉了 AOT 的一大块场景。

3）不足调优和保护，退回成试验个性

JDK-8227439: Turn off AOT by default

JEP 295 AOT is still experimental, and while it can be useful for startup/warmup when used with custom generated archives tailored for the application, experimental data suggests that generating shared libraries at a module level has overall negative impact to startup, dubious efficacy for warmup and severe static footprint implications.

从此关上 AOT 须要增加 experimental 参数：

java -XX:+UnlockExperimentalVMOptions -XX:AOTLibrary=...
依据 issue 的形容，这项个性编译整个模块的状况下，对启动速度和内存占用都起到了副作用。咱们剖析的起因如下：

Java 语言自身过分简单，动静类加载等运行时机制导致 AOT 代码没法运行得像预期一样快
AOT 技术作为阶段性的我的项目在进入 Java 9 之后并没有被长期保护，不足必要的调优(反观AppCDS始终在迭代优化)

4）JDK16 中被删除

JDK-8255616：Disable AOT and Graal in Oracle OpenJDK

在 OpenJDK16 公布前夕，Oracle正式决定不再保护这项技术:

We haven't seen much use of these features, and the effort required to support and enhance them is significant.

其根本原因还是这项基于不足必要的优化和保护。而对于 AOT 相干的将来的布局，只能从只言片语中揣测未来Java的AOT 有两种技术方向：

在 OpenJDK 的 C2 根底上做 AOT

在 GraalVM 的 native-image 上反对残缺的 Java 语言个性，须要 AOT 的用户逐步从 OpenJDK 过渡到native-image
上述的两个技术方向都没法在短期内看到停顿，因而 Dragonwell 的技术方向是让现有的 JEP295 更好地工作，为用户带来极致的启动性能。

5）Dragonwell 上的疾速启动

Dragonwell 的疾速启动个性攻关了 AppCDS、AOT 编译技术上的弱点，并基于 HeapArchive 机制研发了类提前初始化个性。这些个性将 JVM 可见的利用启动耗时简直全副打消。

此外，因为上述几项技术都合乎 trace-dump-replay 的应用模式，Dragonwell 将上述启动减速技术对立了流程，并且集成到了 SAE 产品中。

四 SAE x Dragonwell : Serverless with Java 启动减速最佳实际

有了好的食材，还须要相匹配的佐料，以及一位烹饪巨匠。

将 Dragonwell 的启动减速技术和和以弹性著称的 Serverless 技术相结合更井水不犯河水，同时独特落地在微服务利用的全生命周期治理中，能力施展他们缩短利用端到端启动工夫的作用，因而 Dragonwell 抉择了 SAE 来落地其启动减速技术。

SAE （Serverless 利用引擎）是首款面向 Serverless 的 PaaS 平台，他能够：

Java 软件包部署：零代码革新享受微服务能力，升高研发老本
Serverless 极致弹性：资源免运维，疾速扩容利用实例，升高运维与学习老本

1 难点剖析

通过剖析，咱们发现微服务的用户在利用启动层面面临着一些难题：

软件包大：几百 MB 甚至 GB 级别
依赖包多：上百个依赖包，几千个 Class
加载耗时：从磁盘加载依赖包，再到 Class 按需加载，最高可占启动耗时的一半

借助 Dragonwell 疾速启动能力，SAE 为 Serverless Java 利用提供了一套，让利用尽可能减速启动的最佳实际，让开发者更专一于业务开发：

Java 环境 + JAR/WAR 软件包部署：集成 Dragonwell 11 ，提供减速启动环境
JVM 快捷设置：反对一键开启疾速启动，简化操作
NAS 网盘：反对跨实例减速，在新包部署时，减速新启动实例/分批公布启动速度

2 减速成果

咱们抉择一些微服务、简单依赖的业务场景典型 Demo 或外部利用，测试启动成果，发现利用广泛能升高 5%～45% 的启动耗时。若利用启动，存在下列场景，会有显著减速成果：

类加载多（spring-petclinic 启动加载约 12000+ classes）
依赖内部数据越少

3 客户案例

阿里巴巴搜寻举荐 Serverless 平台

阿里外部的搜寻举荐 Serverless 平台通过类加载隔离机制，将多个业务的合并部署在同一个 Java 虚拟机中。调度零碎会按需地将业务代码合并部署到闲暇的容器中，让多个业务能够共享同一个资源池，大大提高部署密度和整体的 CPU 使用率。

因为要撑持大量不同的业务研发运行，平台自身须要提供足够丰盛的性能，如缓存、RPC调用。因而搜寻举荐Serverless 平台的每个 JVM 都须要拉起相似 Pandora Boot 的中间件隔离容器，这将加载大量的类，连累了平台本身的启动速度。当突增的需要进入，调度零碎须要拉起更多容器以供业务代码部署，此时容器自身的启动工夫就显得尤为重要。

基于 Dragonwell 的疾速启动技术，搜寻举荐平台在预公布环境会执行 AppCDS、Jarindex 等优化，将产生的 archive 文件打入容器镜像中，这样每一个容器在启动时都能享受减速，缩小约30%的启动耗时。

潮牌秒杀SAE极致弹性

某内部客户，借助 SAE 提供的 Jar 包部署与 Dragonwell 11，疾速迭代上线了某潮牌商场 App。

在面对大促秒杀时，借助 SAE Serverless 极致弹性，与利用指标 QPS RT 指标弹性能力，轻松面对 10 倍以上疾速扩容需要；同时一键开启 Dragonwell 加强的 AppCDS 启动减速能力，升高 Java 利用 20% 以上启动耗时，进一步减速利用启动，保障业务安稳衰弱运行。

五总结

Dragonwell 上的疾速启动技术方向上齐全基于 OpenJDK 社区的工作，对各项性能进行了粗疏的优化与 bugfix，并升高了上手的难度。这样做既保证了对规范的兼容，防止外部定制，也可能为开源社区做出奉献。

作为根底软件，Dragonwell 只能生成/应用磁盘上的 archive 文件。联合 SAE 对 Dragonwell 的无缝集成，JVM 配置、archive 文件的散发都被自动化。客户能够轻松享受利用减速带来的技术红利。

作者：

梁希，来自阿里云 Java 虚拟机团队，负责 Java Runtime 方向。主导了 Java 协程、启动优化等技术的研发和大规模落地。

代序，来自阿里云 SAE 团队，负责 Runtime 演进、弹性能力与效率方向。主导利用弹性、Java 减速、镜像减速等技术的研发落地。

原文链接
本文为阿里云原创内容，未经容许不得转载。

一 高性能和快启动速度，是否鱼和熊掌兼得？