在第一回合的基础上，意犹未尽的又引入GraalVM映像以使 Java 应用程序的执行环境更接近于 Go 应用程序的环境，添加了 GraalVM 映像测试(用 GraalVM EE 20.1.1ー JDK 11构建的本机映像)的结果是：
通过使用 GraalVM 映像在 JVM 上运行应用程序，我们没有看到吞吐量或响应时间方面的任何实质性改进，但是内存占用的确变小了。
下面是一些测试的响应时间图:
在第二轮测试中，使用一台更大的机器上运行测试。36核（每个核两个线程）、256GB内存、运行oraclelinux7.8的机器。
和第一轮类似，使用了100个线程，每个线程使用了10,000个循环，10秒的加速时间，以及相同版本的 Go，Java，Helidon 和 GraalVM。
结果如下：
这一回合是GraalVM 映像赢了！
下面是一些测试的响应时间图:
在这个测试中，Java变体的表现要好得多，并且在没有使用Java日志记录的情况下，它的性能大大超过了Go。Java似乎更能使用硬件提供的多核和执行线程（与Go相比）。
这一轮的最佳表现来自GraalVM native image，平均响应时间为0.25毫秒，每秒事务数为82426个，而Go的最佳结果为1.59毫秒和39227个tps，然而这是以多占用两个数量级的内存为代价的！
GraalVM映像比在jvm上运行的同一应用程序快大约30–40%！
第三回合这次，比赛在Kubernetes集群中运行这些应用程序，这是一个更自然的微服务运行时环境。
这次使用了一个Kubernetes 1.16.8集群，它有三个工作节点，每个节点有两个内核（每个内核有两个执行线程）、14GB的RAM和oraclelinux7.8。
应用程序访问是通过Traefik入口控制器进行的，JMeter在Kubernetes集群外运行，用于一些测试，而对于其他测试，使用ClusterIP并在集群中运行JMeter。
与前面的测试一样，我们使用了100个线程，每个线程使用了10,000个循环，以及10秒的加速时间。
下面是各种不同容器的大小:
Go 11.6MB 11.6 MB
Java/Helidon 1.41GB 1.41 GB
Java/Helidon JLinked 150MB 150mb
Native image 25.2MB 25.2 MB
结果如下：
下面是一些测试的响应时间图:
在这一轮中，我们观察到 Go 有时更快，GraalVM 映像有时更快，但这两者之间的差别很小(通常小于5%)。
Java似乎比Go更善于使用所有可用的内核/线程—我们在Java测试中看到了更好的CPU利用率。Java性能在拥有更多内核和内存的机器上更好，Go性能在较小/功能较弱的机器上更好。在一台“生产规模”的机器上，Java很容易就和Go一样快，或者更快
最后接下来会做更多的测试比赛，来看一看究竟谁更好！有兴趣的你也可以自己试一试，记得告诉我们结果哦！
本文参考：https://medium.com/helidon/can-java-microservices-be-as-fast-as-go-5ceb9a45d673
欢迎关注我的公众号：程序猿DD，获得独家整理的免费学习资源助力你的Java学习之路！另每周赠书不停哦～