因为oracle jdk从jdk8u201之后就不提供免费下载了，所以最近在看openjdk的分支实现，网上搜了下，有下列选择和比较（我们目前主要在跑的是open jdk，不少人推荐的zulu openjdk还没有跑过）。
JVM有许多不同的选择。哪个最好用？比较几种JVM性能; Zulu OpenJDK，OpenJDK，Oracle JDK，GraalVM CE（LZ补充说明，其实还有open j9也相当不错，如果内存压力大或运行时希望cpu利用率最大化的话，首选openj9，一个服务器跑很多应用、但是又不想或不能频繁重启的话，jdk 13的zgc是很好的选择，参见LZ原著基于金融大型交易系统benchmark长时间测试的深入分析https://www.cnblogs.com/zhjh256/p/11877069.html）。
在这篇博客中，我将描述我创建的用于同时在不同JVM上执行测试的设置。我还研究了资源隔离的影响（为进程分配特定的CPU和内存）。这种影响可以忽略不计。我的测试应用程序由一个反应性（非阻塞）Spring Boot REST应用程序组成，我使用Prometheus轮询JVM和Grafana进行可视化。除SoapUI外，一切都在Docker容器中运行。
使用了以下版本：
- GraalVM CE rc9 (8u192)
- OpenJDK 8u191
- Zulu 8u192
- Oracle JDK 8u181
CPU使用率：
GraalVM在测试期间总体CPU使用率最高。Oracle JDK的CPU使用率最低。
响应时间：
整体GraalVM的响应时间最短，OpenJDK最好，紧随Oracle JDK和Zulu。平均而言，OpenJDK和GraalVM之间的差异约为30％。
垃圾收集:
有趣的是，GraalVM加载了比其他JDK更多的类。OpenJDK加载最少的类。GraalVM和OpenJDK之间的差异大约是25％。我还没有确定这是否是GraalVM的固定数量的额外类开销，或者它是否与所使用的类的数量成比例，这是一个固定的百分比。这些额外的类可能导致垃圾收集期间的延迟（尽管这种相关性可能不一定是因果关系）。GraalVM更长GC暂停时间。
内存使用情况:
OpenJDK JVM使用大部分内存。GraalVM和Zulu的垃圾收集行为似乎相似，但GraalVM具有更高的基本内存使用率。Oracle JDK似乎不那么频繁地进行垃圾收集。在查看平均值时，OpenJDK JVM使用的内存最多，而Zulu使用的内存最少。在较长时间内查看缩小的图形时，Oracle JDK和OpenJDK的行为看起来不稳定，并且可能会达到相对较高的值，而Zulu和GraalVM看起来更稳定。
总结：
使用SOAP UI进行了负载测试，其中一个响应式Spring Boot REST应用程序在循环haproxy负载均衡器后面的4个不同JVM上运行。我每隔5秒使用Prometheus轮询JVM实例（使用Micrometer生成数据），并使用Grafana和Prometheus来显示数据。结果表明GraalVM不适合作为OpenJDK的替代品，因为它表现更差，使用更多资源，加载更多类并在垃圾收集中花费更多时间。
- GraalVM为同一个应用程序加载更多类
- GraalVM导致应用程序的响应时间最慢
- GraalVM使用大多数CPU（以实现最慢的响应时间）
- GraalVM使用大部分时间进行垃圾收集
- Zulu OpenJDK使用比较JVM的最少内存。与Oracle JDK和OpenJDK相比，Zulu OpenJDK和GraalVM的内存使用更稳定。
当然，由于GraalVM相对较新，Micrometer提供的指标可能无法正确显示实际吞吐量和资源使用情况。也可能是我的设置有负责导致这种差异。我试图通过查看不同情况下的指标来排除第二个问题。
如果您想使用GraalVM的多语言功能，当然其他JVM不提供合适的替代方案。GraalVM也提供了我没有测试的本机编译选项（我在同一个JAR上执行了测试）。此功能可能会大大提高性能。
https://www.jdon.com/50843
https://cn.azul.com/downloads/zulu/