[[418030]]

一 高性能和快啟動速度，能否魚和熊掌兼得？

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 文件的分發都被自動化。客戶可以輕松享受應用加速帶來的技術紅利。