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

58次阅读

共计 15480 个字符，预计需要花费 39 分钟才能阅读完成。

简介：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 5
MODULE 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 | head
META-INF/
META-INF/MANIFEST.MF
org/slf4j/
org/slf4j/event/EventConstants.class
org/slf4j/event/EventRecodingLogger.class
org/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.class
public 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 hessianIO
Benchmark                      Mode  Cnt       Score   Error  Units
SerializeBenchmark.hessianIO  thrpt       118194.452          ops/s

$ java -Xint -jar benchmarks.jar hessianIO
Benchmark                      Mode  Cnt     Score   Error  Units
SerializeBenchmark.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
//     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 须要通过如下步骤：

  1. 调用用户定义的 Classloader.loadClass()，拿到 class byte stream
  2. 计算 class byte stream 的 checksum，与 jsa 中的同类名构造的 checksum 比拟
  3. 如果匹配胜利则返回 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.0

foo.jar
com/foo

bar.jar
com/bar

baz.jar
com/baz

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

com/bar --> bar.jar
com/baz --> baz.jar
com/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 减速、镜像减速等技术的研发落地。

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

正文完
java
发表至： java
2021-08-13
 0
力扣(LeetCode)221
tp5实现微信app支付
Rust中文社刊2019-01发布
Stream流与Lambda表达式（二) Stream收集器 Collector接口