重塑云上的 Java 语言( 五 )_作者|郁磊责编|Elle音乐无国界

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 过高导致系统雪崩。