音乐无国界，但是音乐人有国界。
云原生亦如此。虽没有限定的编程语言，但应用所使用的编程语言已经决定了应用部署运行的行为。
Java 诞生于20年前，拥有大量优秀的企业级框架，践行 OOP 理念，更多体现的是严谨以及在长时间运行条件下的稳定性和高性能。反观如今，在要求快速迭代交付的云场景下，语言的简单性似乎成了首要的要求，而传统的 Java 语言显得有一些过于重量了。
ElasticHeap
Java 常因为耗资源而受诟病，其中最显著一点就是 Heap 对内存的占用，即便没有请求在处理也没有对象分配，进程仍然会保留完整的堆内存空间，保障 GC 进行分配内存和操作内存的快速敏捷。
AJDK ZenGC/ElasticHeap 双十一全面支持核心链路上百应用和数十万实例。
JDK12 开始支持固定时间的触发 concurrent mark 并在 remark 中收缩 Java 堆归还内存的功能，然而并未解决在 stw 中增加暂停时间的问题，因此无法在每次 young GC 时做内存归还。 ElasticHeap 在并发异步线程中完成内存处理反复 map/unmap 以及 page fault 的开销，因此任意一次 young GC 都可以敏捷的及时归还内存，或重新恢复内存使用。
ElasticHeap 阿里巴巴实战
ElasticHeap场景1：可预测的流量高峰
ElasticHeap 场景 2 ：单机运行多个 Java 实例
多个 Java 实例接受的流量任务较为随机，峰值不会重叠，在闲时可以有效降低多个实例整体的内存占用，提高部署密度。
双11验证核心交易系统使用 ElasticHeap 进行低功耗模式运行，大幅降低 WSS(Working Set Size) 规模的实例。
静态编译
很多云上的新应用不约而同地选择了 Go 语言，很大的原因是 Go 应用对运行时没有依赖，静态编译的程序启动速度快，也不需要通过 JIT 来预热。在阿里有大量 Java 代码的前提下，我们是如何为 Java 注入这方面的能力的呢？
Java 静态编译技术是一种激进的 AOT 技术，通过单独的编译阶段将 Java 程序编译为本地代码，在运行时无需传统 Java 虚拟机和运行时环境，只需操作系统类库支持即可。其工作基本原理如下图所示。静态编译技术实现了 Java 语言与原生 native 程序的“合体”，将原本的 Java 程序编译成为了一个自举的具有 Java 行为的原生 native 程序，由此兼有 Java 程序和原生 native 程序的优点。
JVM 团队与 SOFAStack 团队密切合作，在中间件应用上率先实现静态编译的落地。将一个应用的启动速度从 60 秒优化到 3.8 秒，双十一期间静态编译的应用运行稳定，没有故障， GC 停顿时间在 100 毫秒，在业务允许范围之内，内存占用和 RT 与传统 Java 应用持平。
综上所述，静态编译的应用在稳定性、资源占用、RT 响应等各方面指标与传统 Java 应用基本持平的状况下，将启动时间降低了 2000% 。
Wisp2
当你用时下最酷炫的 Vert.X 开发一个简单的 Web 服务，准备体验一下最强的性能， QA 同学拿来一台 1C 2G 的容器让你压一下，你却发现你怎么也拼不过别人 Go 应用。研究之后发现，原来协程模型在这样的少核心的情况下性能要好很多。是时代变了， Java 落伍了？
AJDK Wisp2 回答了这个问题： Java 同样可以拥有高性能的协程。今年是 Wisp2 大规模上线的第一年， Wisp2 具有如下特点:
在整个Java runtime中支持了协程调度，线程(比如 Socket.getInputStream().read() )阻塞会变成更轻量的协程切换。
完全兼容 Thread API ，在开启 Wisp2 的 JDK 中，Thread.start() 实际创建的是一个协程(轻量级线程)，可以类比 Go 只提供协程关键字 go 而没有暴露线程接口；我们同样只提供创建协程的方式，应用可以透明切换到协程。
支持 work stealing ，调度策略特别适合 web 场景，在高压力下调度开销极小。
在今年双十一， Wisp 支持了上百应用，十万级容器，其中 90% 的容器已经升级到 Wisp2 。
我们可以看到峰值附近， Wisp2 机器的 CPU 要低 7%( Wisp1 更低，Wisp2的取向是 RT ，因此 CPU 会高一些)左右，这主要是轻量级调度所节省的 sys CPU 。 0 点的 CPU 是相等的，这也说明一点： Wisp2 解决的是调度开销，当 CPU 低，调度没有压力时是看不出差距的。
从 RT 角度看， Wisp2 机器的 RT 要低 20% 左右， RT 减少明显的一个原因是这批机器的 CPU 压力很大，协程的调度优势更容易体现出来。这样的优势可以帮助系统摸高到更高的水位，整体地提高利用率而担心 RT 过高导致系统雪崩。
FDO
双十一正零点相对后面几分钟会有一个明显的 CPU 峰值，根据数据分析，主要原因是双十一零点触发了 JIT 编译。 举个例子，程序里有逻辑:
if (is1111(LocalDate.now())) {
branch1
} else {
branch2
}
假设预热时一直在走 branch2 ，那么 JIT 有理由相信后续基本也都会走 branch2 ，而不会对 branch1编译。在零点时，我们进入 branch1 ，此时就需要触发退优化重新编译方法。我们来看 AJDK 如何通过 profiling 解决这个问题。
退优化原理及其危害
JDK 运行代码的时候，采用分层编译的方式对 Java 方法进行动态编译。在最高等级(峰值性能最好)的编译中，出于性能的考虑，编译的时候会根据收集的信息做一些比较乐观的假设，一旦这些假设条件不满足了，就会出现退优化的现象。比如某个热点方法中某段代码仅会在双十一中执行，那么在预热过程中这段代码不会被编译，双十一到来时这段代码一旦被执行，就会触发整个方法的退优化。
发生退优化有两个方面的负面影响，一是需要运行的方法由高效率的编译执行变成了解释执行，运行速度降低百倍以上；二是流量高峰期退优化的方法会很快被重新编译，编译线程会消耗 CPU 。因此在双十一这种流量短时间剧增且与预热流量不太一样的场景下，退优化的危害会特别明显。
通过 FDO 减少退优化
FDO 是 feedback directed optimization 的缩写，即参考以往 JVM 运行时的编译信息，指导本次运行时进行更好的编译。具体的，我们采用了两个层面的方法来减少退优化。
将每次运行时的退优化信息记录到文件中，下次运行时读取这个文件，在决定是否做乐观假设的时候参考文件中的信息做判断，从而减少退优化的概率。
信息显示出现最多的退优化与 if-else 相关，占总数量的一半以上。我们提供了一个方法根据以往出现 if-else 退优化的信息，关闭某个路径上所有相关的乐观假设。
双十一中 FDO 的效果
FDO 今年双十一上线，目标解决两个问题：
1、双十一 0 点流量高峰和退优化/编译高峰叠加造成的 CPU 使用率脉冲过高。
2、预热效率低，压测经过前长时间预热后，增大流量时仍然伴随着大量的编译及退优化。
针对第一个问题，我们收集了双十一高峰第一分钟的退优化／C2 编译次数以及 CPU 数据。
可见开启 FDO 后高峰期 C2 编译数目减少约 45% ，退优化数目减少约 70% 。
CPU 数据上，高峰期第一分钟内开启 FDO 后 CPU 由约 67.5 降低到 63.1 ，降低约 7.0% 。
第二个目标可以通过压测第一分钟的 CPU 数据验证。
开启 FDO ，压测第一分钟 CPU 使用率由 66.19 降低到 60.33% ，降低约 10% 。
Grace
ZProfiler 一直是全集团排查 Java 应用各类问题的利器，而 Grace 作为其平台化的版本，对其实施了一系列的优化，从原来的单机版本到现在的 Master/Worker 架构，同时引入了任务排队机制，在高压力情况下对用户的任务进行排队从而解决 Worker 不堪重负的问题。在可维护性、拓展性、以及用户体验上得到了质的提升，为后续工具平台的上云、开源事项打下了夯实的基础。
目前已经集成了 Heap Dump 功能，在继承 ZProfiler 功能的基础上做了一定的优化，提升了解析引擎的版本，支持更全面的 OQL 语法等等。
JDK11
JDK8 作为一个经典版本，正被大规模使用，虽然从 JDK6 和 7 迁移上来有一定的阵痛，但是升级后普遍的反馈是：“真香”。
OpenJDK 8的下一个稳定版本是 OpenJDK 11 。JVM 团队自然会在这个方向上积极跟进，目前 AJDK11 支持了 AJDK8 的 Wisp2 、多租户特性。本次双十一的部分集群已经上线到 JDK11 ，表现稳定。
升级 JDK11 是否会和升级 JDK8 一样给我们带来同样的的惊喜呢？在 JDK11 上我们可以体验到最新的 ZGC 。
ZGC
JDK11 引入了一个重要特性： ZGC 内存垃圾回收器。这个垃圾回收器号称能够在几十 GB 至若干 TB 的堆上把暂停时间保持在 10ms 以内。许多 Java 开发者苦于过去的垃圾回收器的暂停时间带来延迟， ZGC 短暂停的特性未来无疑会成为 Java 开发者的新宠。
目前 ZGC 在 OpenJDK 中仍然处于实验特性，而且 JDK11 尚未在产业界完全普及， JDK11 只支持 Linux 上的 ZGC（ MacOS 和 Windows 的 ZGC 预计在 2020 年 3 月发布的 JDK14 版本才会支持），许多 Java 开发者仍然只能垂涎欲滴，处于观望状态。
向来敢于吃螃蟹的我们岂能望而却步？阿里 JVM 团队和数据库团队已经开始让数据库应用运行在 ZGC 上，并根据运行的效果对 ZGC 进行了相应的改进工作，包括 ZGC 的页缓存机制优化、ZGC的触发时机优化等等。
从 9 月开始，两个团队推动线上数据库应用在 ZGC 上运行，目前已经稳定运行两个月，并顺利通过双十一大考。线上反馈的效果可喜可贺：
1、 JVM 暂停时间保持在官方的 10ms 以内；
2、 ZGC 大大改善了线上运行集群的平均 RT 与毛刺指标。
小结
从上述的功能特性可以看到 AJDK 已经从一个传统的 Managed Runtime 脱胎换骨。今后 AJDK 将继续致力于提高云上的应用的开发体验，通过底层的创新为上层应用提供更多的可能。
在 Dragonwell 上使用 AJDK 功能
上述的这些经过双十一考验的功能都将随着 Dragonwell 陆续开源和交付到广大用户手中，敬请关注。
Alibaba Dragonwell 8 是一款免费的 OpenJDK 发行版。它提供长期支持，包括性能增强和安全修复。Alibaba Dragonwell 8 目前支持 X86-64/Linux 平台，在数据中心大规模 Java 应用部署情况下， 可以大幅度提高稳定性、效率以及性能。Alibaba Dragonwell 8 是 OpenJDK 的下游( friendly fork )，使用了和 OpenJDK 一样的 license。Alibaba Dragonwell 8 与 Java SE 标准兼容，用户可以使用 Alibaba Dragonwell 8 开发和运行 Java 应用程序。此次开源的 Alibaba Dragonwell 8 是阿里巴巴内部 OpenJDK 定制版 AJDK 的开源版本， AJDK 为在线电商，金融，物流做了结合业务场景的优化，运行在超大规模的，1,000,000+ 服务器的阿里巴巴数据中心。
近期我们正在紧密筹备 Alibaba Dragonwell 11 的 release 。 Dragonwell 11 是基于 OpenJDK 11 的 Dragonwell 发行版本，拥有更多特性，可以更多地为云上场景赋能，模块化更加清晰，并将获得长期的支持，因此推荐大家关注和适时升级。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
