今天我们来讲讲整个Java生态下相当有分量的一位角儿——GraalVM。

要想搞清楚一个技术的主要适用场景，通常都是看官网。但是GraalVM的官网，怎么说呢，稍微有点营销号的感觉，不利于技术人理解它。咱们还是看维基百科上怎么说吧。

GraalVM是用Java实现的基于HotSpot/OpenJDK的JVM和JDK。它支持额外的编程语言和运行范式，例如对Java应用程序AOT，从而实现快速启动和低内存占用。

这段描述透露了三个信息：

  1. GraalVM可以代替JDK、JVM之前的工作。
  2. GraalVM除了支持Java，也支持多种语言。
  3. GraalVM可以对应用AOT，也就是把程序直接编译成二进制，从而提升启动速度、改进内存使用。

了解完这些背景知识，我们再看看官网怎么说。

Run Programs Faster Anywhere

  • Increase application throughput and reduce latency
  • Compile applications into small self-contained native binaries
  • Seamlessly use multiple languages and libraries

翻译一下就是：在各种地方跑起来都更快。提升应用的吞吐并减少延迟、把应用编译成独立本机的二进制程序、无缝使用多种语言和库。

对于上述特点，官网还有几个好看的图示：

16058588174202

不知道大家看了官网后有什么想法，反正我是感觉，这明显跟维基百科的画风不一样嘛，整个首页都在特意弱化Java的存在，应该是想让其受众更广泛，吸纳更多的用户。由此可见Oracle的野心不小。

不过野心归野心，是骡子是马还得遛遛才知道。下面我们分三个方面来捋捋：

  1. 性能有多强
  2. 多语言互相调用好使不
  3. 编译二进制香不香

一、性能有多强

这里我偷个懒啊，网上找了些使用了GraalVM框架的测试表现供大家参考，数据有点夸张哈，但是大趋势肯定是不会错的。

截屏2020-11-20 下午4.57.55 2

这个图片来自Quarkus官网，横轴表示时间，可以明显看出在GraalVM的加持下，Quarkus的启动后首次响应时间大概提升了50倍左右（0.016vs0.943），这算是一个相当恐怖的数据了。还有一个参考线“Traditional Cloud-Native Stack”，数据更夸张，但是并没有指名道姓，这个就稍微有点不老实了，大家就忽略它吧。

上面的数据证明通过GraalVM编译后，启动及响应速度是大幅跃进了。那么内存使用呢，这个也是云原生比较关注的点。请看下图：

截屏2020-11-20 下午4.57.55

大概有个5倍左右的改进吧，应该说相当不错了。如果说前面的响应速度影响的还是用户体验，那8G内存的服务器跟40G内存的服务器，那省下来的可是真金白银啊。

聪明的小伙伴可能会说了，你上面的数据强是强，但是万物互联时代，主要看吞吐，对别的技术栈来说，上面的两个维度数据即使不理想，也不能算硬伤。吞吐强，才是真的强。我们一起来看下图：

16061844042301

来自TechEmpower的数据测试。我只截取了使用JavaScript语言相关技术（都是后端哦）的成绩。先交代下背景，TechEmpower准备了同样的硬件环境，然后用不同的语言和框架来做同一件事情（提供后端HTTP API），并对它们进行压力测试记录下来成绩。所有参与测试的代码都是开源的，可以在GitHub上找到。当然这种“跑分”化的场景跟我们实际项目运行的情况肯定是千差万别的，TechEmpower考虑到实际情况的复杂性，准备了不同的测试场景，如图：

16061867928040

其中Fortunes要从数据库取数然后在服务端进行数据排序，我觉得还是比较有代表性，所以上面的“跑分”截图就用的Fortunes的成绩。

现在我们来具体看下成绩，TechEmpower的规则是以第一名的得分值作为基准，也就是100%。第一名es4x框架实际得分为237751，这个数字的含义截图中有提到——responses per second，也就是每秒响应数高达23万多，应该是个非常恐怖的数字了。我们可以对比看下nodejs的得分，也有91,799的每秒响应数，其实也很惊人，但是成绩也才有es4x的38.6%。如果你仔细看的话，会发现es4x的100%以及nodejs的38.6%数字后面还分别有两个百分比，这个数字代表其得分跟所有本次参与的技术及框架中最强者的比较。至于最强者是谁，我就卖个关子，有兴趣的朋友可以自己去官方网站查看。

好了，现在你应该同意es4x是一个相当有性能优势的技术了。而es4x之所以能取得如此不俗的成绩，就是因为它用到了我们今天谈论的主角——GraalVM。TechEmpower的GitHub上能看到说明，指出了这次测试是基于GraalVM的。略显遗憾的就是，TechEmpower并没有测试一版不依赖GraalVM的es4x，其实es4x是一种跑在JDK上的JavaScript技术（如果你对JDK上跑JavaScript感到惊奇，可以查看你不知道的Java），所以es4x跟GraalVM不是强关联的，只是es4x官方认为GraalVM性能更好，所以不论es4x的官网还是TechEmpower的跑分，都是把GraalVM作为了第一选择。

至此，我已经花了不少篇幅来介绍GraalVM的性能优势，相信你对它的性能水平有了一个大概的认识。前面的内容基本是拿来主义，重度依赖了互联网上已有的数据成果，下面我们开始第二个议题，真刀真枪的写点代码试一试。

二、多语言互相调用好使不

先来看看GraalVM支持哪些语言：

16062019446437

应该说有点意思，支持的语言还真不少。那我们就来动手试试吧。

安装GraalVM
我是通过sdkman来管理GraalVM的，建议你也这样做。

安装sdkman

curl -s "https://get.sdkman.io" | bash

使用sdkman查看可用的GraalVM

sdk list java

结果如图：

16062667123814

找一个最新版本安装，此处是20.3.0.r11-grl

sdk install java 20.3.0.r11-grl

这里提一句，执行完安装后，sdkman会询问你是否把刚安装的环境作为默认环境，我建议你选择否，这样就不会对你电脑之前安装好的Java、Node环境造成影响。当您想使用20.3.0.r11-grl的时候，只需要执行sdk use java 20.3.0.r11-grl，它只会影响当前终端上下文的环境。

基本的环境准备好后，你可以试试node --version，应该可以看到v12.18.4的输出，而如果你执行which node，应当会看到类似下面的内容：

16062719015306

有意思吧？GraalVM居然自带了一个node命令，一个不需要你安装https://nodejs.org就可以使用的node🤓。

安装完GraalVM，还需要安装多语言扩展包

# 根据个人口味，请适量添加😜
# js/node是一等公民，不需要特意安装，这个在上一节已经见识了😋
gu install python
gu install ruby
gu install r

经过漫长的等待，GraalVM及多语言环境就算安装完成，终于可以进入代码环节了。我们直接采用官方GitHub中的一个例子——polyglot-javascript-java-r，一个演示了JavaScript、R、Java混合使用的精彩demo。

你只需要准备两个文件就可以了，先来看看package.json，内容非常简单：

{
    "dependencies": {
       "express": "^4.16.3"
    }
}

重头戏都在server.js，内容如下：

const express = require('express')
const app = express()

const BigInteger = Java.type('java.math.BigInteger')


app.get('/', function (req, res) {
  var text = 'Hello World from Graal.js!<br> '

  // Using Java standard library classes
  text += BigInteger.valueOf(10).pow(100)
          .add(BigInteger.valueOf(43)).toString() + '<br>'

  // Using R methods to return arrays
  text += Polyglot.eval('R',
      'ifelse(1 > 2, "no", paste(1:42, c="|"))') + '<br>'

  // Using R interoperability to create graphs
  text += Polyglot.eval('R',
    `svg();
     require(lattice);
     x <- 1:100
     y <- sin(x/10)
     z <- cos(x^1.3/(runif(1)*5+10))
     print(cloud(x~y*z, main="cloud plot"))
     grDevices:::svg.off()
    `);

  res.send(text)
})

app.listen(3000, function () {
  console.log('Example app listening on port 3000!')
})

除了常规的node和express使用外，比较有意思的就是对Java和R的访问了。咱们一个个来看。

  • const BigInteger = Java.type('java.math.BigInteger')使得我们直接在JavaScript拿到了一个Java Class。后续就可以在JavaScript无缝使用Java中的功能，比如静态方法valueOf、pow、add。一通操作后，我们获得了一个10的100次方的超大整数，并让其和43相加。
  • Polyglot.eval('R','ifelse(1 > 2, "no", paste(1:42, c="|"))')演示了JavaScript中通过Polyglot.eval动态执行其他语言表达式。这里显然是执行了一个R的表达式。其他语言都是支持的，比如python你可以使用这样的代码var array = Polyglot.eval("python", "[1,2,42,4]")，就可以获得一个在python中制造的数组了。
  • 另一段比较长的Polyglot.eval就是本次demo的核心了， 其实也是R语言的专属技能。关于R语言的使用，已经超出了本文的讨论范围，有兴趣的小伙伴可以查看官方文档。

让我们来看看结果吧，先执行npm install把依赖安装好，然后你要用GraalVM的node命令启动项目，请一定注意，不是用你曾经熟悉的那个node哦。执行node --jvm --polyglot server.js，然后你会看到如下输出：

16062953427078

赶紧打开浏览器访问一下http://127.0.0.1:3000看看效果吧：

iShot2020-11-25 16.54.46

非常精彩，你不费吹灰之力就在html中构建了一个基于svg的三维坐标系，仿佛开启了在html展示数学技艺的大门——当然，如果你想进门转转的话，还得回头恶补一下数学和R语言，至少我是这么打算的😉。

现在你理解多语言的程序环境是一件多么激动人心事了吧。这里没有口水战，有的只是百家争鸣，取长补短，共建繁荣。所以我才说Oracle的野心真的很大，通过GraalVM拿出一个多语言支持的环境，并且性能还更强，还可以预编译成二进制文件，直接分发高效运行。如果真有这样的东西，谁不喜欢呢。

三、编译二进制香不香

下面终于到最后一个环节了，把程序打包成二进制程序。按照官网的指点，首先我们要安装native-image来解锁编译二进制文件的技能。你需要执行:

gu install native-image

安装完native-image后，当我满心欢喜的执行native-image --language:js server.js试图把上面演示的server.js编译成二进制的时候，居然报错了：

16062830173257

去官网查阅了native-image的文档才知道，native-image只支持JVM-based的语言，比如Java、Scala、Clojure、Kotlin这些JVM的亲缘语言。

没办法，那我们还是拿Java开刀吧，这里我准备了一个简单的Java类：

import org.graalvm.polyglot.*;

public class PolyglotJavaJS {
    public static void main(String[] args) {
        Context polyglot = Context.create();
        Value array = polyglot.eval("js", "eval('1+1')");
        int result = array.asInt();
        System.out.println(result);
    }
}

可以看到中间我用GraalVM提供的工具执行了一小段JavaScript脚本，通过JavaScript中的eval函数计算了1+1。eval这种开挂的函数在JavaScript这种动态语言里挺常见的，但是在Java这种静态语言就特别少见，也制约了好多编程场景，我个人感觉GraalVM能通过这种非主流的方式给Java带来eval的特性还挺香的。下面我们来把这个Class打包成二进制文件：

  • 第一步，编译.java为.class：
javac PolyglotJavaJS.java
  • 第二步，有了.class文件后我们可以验证一下代码：
Java PolyglotJavaJS

这时控制台打印了2，看起来一切正常。

  • 第三步，用native-image把.class编译可执行文件（也就是二进制文件）。
native-image --language:js  PolyglotJavaJS

由于代码里我们用到了JavaScript相关内容，所以编译的时候需要提供参数--language:js。

经过一个漫长的等待（我这边是3分多钟），还有恐怖的内存消耗（被native-image进程消耗掉了6个多G），我们终于得到了如图的执行结果：

16062859097644

当然还有我们想要的可执行文件polyglotjavaJS，一个惊人的97M的文件。

16062859745462

好在这个文件执行起来还不赖，直接运行./polyglotjavajs就可以看到我们想要的结果了。如果在执行的命令前面加上time，我们就能和JVM解释执行的版本做个对比了：

16062862375387

可以看到，二进制版本确实有着更快的执行速度和更低的CPU使用率，跟JVM版本对比优势还是比较明显的。就是97M的文件大小，我觉得有点大了，不利于分发。下面尝试把JavaScript的相关内容移除，只实现最简单的逻辑：

public class PolyglotJavaJS {
    public static void main(String[] args) {       
        System.out.println("Hello GraalVM!");
    }
}

然后我们再次执行javac和native-image PolyglotJavaJS，又得到了一组新的编译日志：

16062869524972


可喜可贺，编译过程对内存和时间的消耗都只有之前的三分之一。再来看下编译后的文件大小：

16062870264971


只有7.7M了，瞬间觉得香了，有木有。同样的，我们再把二进制和JVM版的执行速度对比一下：

16062871976009


二进制版本依然保持了不俗的优势。

这么看来GraalVM打包二进制可执行文件的功能，在JVM系语言上还是有一定优势的。除了打包过程中耗时比较长以及对机器的CPU、内存有不小的占用，二进制程序执行速度还是挺快的，明显感觉比解释型执行的语言要快。打包出来的文件Size，确实不小，与主流的硬编译语言C、C++、Go、Rust比差太远了，我随便测试了一个Rust的Hello World程序，编译后的可执行文件才370K。这方面的差距，我觉得在很长一段时间GraalVM是不可能追赶上了。好在5G时代带宽可能不是个大问题，磁盘也越来越白菜价了，可执行文件的大小应该不是我们要考量的主要因素。

总结

GraalVM在整个JVM领域无疑是个异类，有众多激进的特性。并且由Oracle做背书，同时提供社区版和商业版，可持续性不需担心，未来的发展肯定是要越来越好的。但是Java作为一个有年代感的语言，早也不复舞台C位的荣光。最近几年JVM系的好东西涌现了不少，无奈国内接受度真的不高，这可能是我辈JVM系程序员最尴尬的境地了。

我个人感觉，那些没有历史包袱的公司，甚至有了包袱但已经在想办法甩掉包袱的公司，它们在做技术选型时，Java往往不是第一考量。相反，那些还在坚持Java路线的公司，往往也不是因为Java有多好，而是受制于公司软件资产规模，不好调头，或者压根不关心技术，本着能用就行的原则惯性地使用着Java（这里主要指Web领域）。

这么看，GraalVM能不能得到市场的认可，未可知也。说实话，我自己甚至觉得，有同样的时间，不如学学go、rust，难道不香么？

不过对于那些已经在JVM扎了根的公司，GraalVM的出现无疑是有建设意义的，它的多语言环境，能让Java充当主持人的身份，舞台不再属于Java一个人，而是“你方唱罢我登场”，大家一起唱好这出戏。至于编译成二进制可执行文件，我个人感觉不是很有必要，至少大部分Java之前已经做的很好的场景其实是不需要这个二进制文件的。这个功能更像是对Java的一些补充，用于应对某些特殊的情况。

当然我们也不要忘了node的程序员，GraalVM给了他们不同的世界，一个可以享受到JVM资产，可以访问R、Python语言的机会。毕竟Oracle下了一盘大棋，前所未有的让之前割裂的技术有机会协同工作，而这种高维度的演进，也许会在某个不经意的地方擦出你未想象过的火花🤓。

全文完。