空桑

Appearance

[简要横评] 我的世界 15 个 JDK 千万行数据 大型测评项目 ​

Write by 空桑, publish on https://hqshi.cn

本文长度超过万字，可直接跳到测试记录部分。测试数据见末尾

说明 ​

本人玩 java 许久，一直是本地类原版红石生存。架构一般是 fabric+追新版本。不过原版红石嘛，懂得都懂，性能问题一直令人头大。除了修改机器架构、空置域或做到虚空分开加载外，还有一个盘外招就是更换更强的 JDK

不过看来看去，国内外没有一个令我满意的 MC JDK 测评。大部分的测评没有一个方便复现的标准，也没有一个可以量化分析的数据展示。不得不说让人感到遗憾

我曾经尝试换 graalvm 或是 dragonwell，但是在我的场景里人工观察 MSPT 却都感觉差不多。由于人力有穷，没法长期高精度的记录 CPU、内存、MSPT、加载区块等信息。为了解答 JDK 之间到底差多少，有哪些不同。我筹备了这个横评

JDK 以 JDK17 为主，这个是 LTS 版本，是一个比较有参考价值的比较对象。JDK21 新版本适配后我应该会再测一遍

省流助手，Graalvm-JDK 和 Zing 表现是最好的

测试说明 ​

主要考虑求同存异,本次大概会测全部 15 个 JDK 发行版 的 JAVA17 LTS 版本和部分 JDK 的最新版本和不同参数作为对比

每项测试约持续 10 分钟左右，一轮测试有差不多 8-12 项。应该能排除随机波动和 jvm 预热

考虑到求同存异，采用 unifiedmetrics 模组进行采样和导出

目前是 fabric 1.20.1 服务端视距 32，其他默认

  • 服务端: fabric-server-mc.1.20.1-loader.0.14.21-launcher.0.11.2.jar
  • 模组
    • fabric-api-0.83.1+1.20.1.jar
    • fabric-carpet-1.20-1.4.112+v230608.jar
    • fabric-language-kotlin-1.9.5+kotlin.1.8.22.jar
    • unifiedmetrics-platform-fabric-0.3.8.jar
  • 测试流程
    1. 预生成环境（虚空，相隔 1000 格建造机器）
      • 1、 预热(魔改版 hsds 测试单片+32x32 漏斗+TNT 爆炸及村民生成)
      • 2、 红石原件测试(黑山大叔测试单片魔改堆叠)
      • 3、 加载测试(65x65 漏斗)
      • 4、 爆炸测试(使用命令方块脉冲持续生成 5x5 TNT，自然下落爆炸)
      • 5、 ai 逻辑测试(使用命令方块脉冲生成 5 类实体（包含村民 铁傀儡等），一次生成 5x5=25 个。在约 64 高度自然跌落虚空)
    2. 随机生成环境(种子 114514)
      • 6、 多玩家测试（间隔 3 秒召唤 1 个玩家，直到达到 100 人）
      • 7、 生成测试（单玩家每秒传送 32 格位置）
    3. 真实场景环境（个人存档）
      • 8、 真实场景测试（三个假人分别加载半个全物品+工业区、一个农业区、女巫刷怪塔）
  • 主要测试指标
    • MSPT：最经典的指标，计算每一刻需要的时间，反正越低越好
    • 区块加载数：这个其实也是非常重要的指标，实测发现存在 JDK 因为区块加载数低而卡顿相对更小的
    • CPU 占用：没什么好说的.需要注意的是，与刻板的 MC 只吃单核的印象，疯狂跑图峰值可以超过 8 核
    • 内存占用：非常重要的一环，很多低配的机器往往 CPU 充足而内存不足
    • GC 时间：JAVA 中传统 GC 是有一个全局时停时间的(Stop The World)，如果 GC 时间过长，就会导致体感存在掉刻问题

软硬件环境 ​

系统环境和说明，由于测试持续时间可能长达一个星期，因此可能部分外部物理环境无法保证(室温 35 度降低到 25 度之类的)

NAS

我的机器是一个比较典型的 All In One 设置，开了差不多 7-8 个虚拟机，内存长期维持 80%占用，cpu 负载差不多 15% 左右。有文件共享、下载、游戏挂机等一系列服务

  • 宿主
    • 系统: PVE 8.0.3 Kernel 6.2
    • cpu: 5900X 默认，低于 30%负载下默认能稳 4.5G
    • 内存: 4x32G 3200MHz C18 带 KSM 内存回收
    • 磁盘: Micron 7450Pro M.2 1.92T(差不多 pm9A1 的大文件缓外速度和 pm983 的 4k)
  • 虚拟机:
    • 系统: Ubuntu Server 22.04 LTS kernel 5.15
    • cpu: 16c，非常充足
    • 内存: 32G 动态分配，够了
    • 磁盘: Virtio SCSI 512G 还凑合，不会造成瓶颈

JDK 介绍 ​

TIP

介绍部分接近万字，不关心的跳到测试结果看完后挑着看感兴趣的就行

jdk 有很多不同的发行版，但是实际底层的 jvm 主要是经典的 hotspot、Azul 的 zing(hotspot 魔改) 还有 IBM 的 J9。其实还有个编译成原生的 graalvm，但是这个就不在讨论范畴了

本次介绍以使用的 JVM 类型进行分类

虽然 JDK 有很多不同的发行版本，但是由于条件所限，本次测试只能测试部分项目，无法发挥每个 JDK 的最大性能

  1. 感谢 injdk.cn 整理的 JDK 列表，我自己也补充了点
  2. 附言: 阿里、腾讯等企业 内部都有自己的 JDK 实现未公开，这好吗？这不好，希望耗子尾汁！

支持环境 ​

简单说明下都有哪些环境

JAVA 代码虽然号称是一次编写，处处运行，但是还是需要 JDK 对底层硬件和操作系统适配。因此 JDK 的兼容性是需要考虑的

兼容性是一个很有意思的话题，比如说一个 JDK 支持 x86 和 arm 架构，也支持 windows 和 linux，但是并不代表能自由组合。比如说可能是 x86 的 windows 和 arm 的 linux。arm 的 windows 和 x86 的 linux 不支持

不过一般来说，主流的 linux+x86 一定是支持的

硬件 ​

基础设施 比如 intel 和 amd 的 U 就是 x86_64(兼容 x86 的 x64 架构)，手机的骁龙和苹果的 Apple Silicon 就是 aarch64

  • X86: 纯 32 位的 X86 架构
  • X64: 64 位的 X64 架构，也被叫做 x86_64 或者 amd64(amd 第一个发明的兼容 32 位的 64 位架构)
  • aarch64: 支持 64 位的 arm 芯片(V8 架构)
  • arm: 更宽泛的 arm 芯片(包含 V7 等架构)
  • ppc64le: IBM 的 Power PC 等架构，内部地址顺序为小端
  • ppc64: IBM 的 Power PC 等架构
  • s390x: IBM Z 系列大型机处理器的架构(再大的台式机也不过是微型机)
  • sparc v9: SUN 公司的处理器

操作系统 ​

Docker: 一般指 linux 下的 docker，是一种复用宿主机操作系统的容器。相比直接提供虚拟机而言，容器做到了资源隔离和更小的冗余开销。但是对于面板服而言，更加容易超开了，因此有很多人选择了看似不容易超开的 windows 虚拟机

实际上配合非常常见的内存压缩技术，windows 虚拟机可以回收超过 80%的空闲内存

  • Windows: 世界上使用量第一的桌面操作系统，图形化的管理很简单，但是基础资源消耗也不少，不建议低配置虚拟机用 win 开服
  • MacOS: 苹果的系统，一般，但 Apple Silicon 的单核性能还算不错，不知道开服会不会有什么魔法效果？
  • Linux: 最广泛的系统，默认资源消耗相对 Windows 小不少。适合 MC 开服
  • Alpine Linux: 为了云原生而生的 Linux，做了很多精简
  • AIX: IBM 的 UNIX 发行版
  • z/OS: 听名字就知道，IBM 的大型机专用
  • Solaris: SUN 开发的 Unix 类系统

收费政策: ​

实际上说白了就是即使是收费的 JDK，个人非商用基本不管。得益于 GPLV2 协议的传染性 OpenJDK 的下游 JDK 都是可以免费商用的

JDK 用到的许可证如下

参评 JDK 列表 ​

本文实际上经历了多次修改，所以 JDK 介绍里会包含一些测试的结果说明。这里就不剧透了

测试了部分表现好的项目的 JDK21 GA，普遍倒退了。可能是没做适配

主要选取 java17 LTS 版本，这个版本各个发行版都有。等 java21 稳定后再做一版试试

bash
$ ls jdks/ |grep tar # [org]package_name

[Alibaba]Alibaba_Dragonwell_17.0.2.0.2+8_x64_linux.tar.gz
[Amazon]amazon-corretto-17.0.1.12.1-linux-x64.tar.gz
[Azul]zing23.03.0.0-3-jdk19.0.2-linux_x64.tar.gz
[Azul]zing23.05.0.0-2-jdk17.0.7-linux_x64.tar.gz
[Azul]zulu17.36.17-ca-jdk17.0.4.1-linux_x64.tar.gz
[Azul]zulu21.28.85-ca-jdk21.0.0-linux_x64.tar.gz
[HUAWEI]bisheng-jdk-17.0.7-linux-x64.tar.gz
[IBM]ibm-semeru-open-jdk_x64_linux_17.0.3_7_openj9-0.32.0.tar.gz
[Liberica]bellsoft-jdk17.0.4.1+1-linux-amd64.tar.gz
[Microsoft]microsoft-jdk-17.0.2.8.1-linux-x64.tar.gz
[Oracle]graalvm-ce-java17-linux-amd64-22.3.0.tar.gz
[Oracle]graalvm-community-jdk-20.0.2_linux-x64_bin.tar.gz
[Oracle]graalvm-jdk-17_linux-x64_bin.tar.gz
[Oracle]graalvm-jdk-20_linux-x64_bin.tar.gz
[Oracle]graalvm-jdk-21_linux-x64_bin.tar.gz
[Oracle]jdk-17_linux-x64_bin.tar.gz
[Oracle]openjdk-17.0.1_linux-x64_bin.tar.gz
[Oracle]openjdk-20.0.2_linux-x64_bin.tar.gz
[RedHat]java-17-openjdk-17.0.7.0.7-1.portable.jdk.el.x86_64.tar.xz
[SAP]sapmachine-jdk-17.0.8_linux-x64_bin.tar.gz
[SAP]sapmachine-jdk-19_linux-x64_bin.tar.gz
[Temurin]OpenJDK17U-jdk_x64_linux_hotspot_17.0.1_12.tar.gz
[Tencent]TencentKona-17.0.3.b1-jdk_linux-x86_64.tar.gz

使用的参数大致如下

auto 默认

aggress HostSpot+G1GC的JDK使用aikar参数，openj9用官方推荐的参数
G1GC "-XX:+UseG1GC -Xmx8G -Xms8G -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true"
j9 "-Xmx8G -Xms8G -Xss512K -Xaggressive -Xalwaysclassgc -XcompilationThreads4 -Xconmeter:dynamic -Xshareclasses -Xtune:virtualized"

zgc 官方: ZGC已经足够优秀了，所以指定用到的内存大小就差不多了
"-XX:+UseZGC -Xmx8G -Xms8G -XX:+AlwaysPreTouch"

shenandoah 同上
"-XX:+UseShenandoahGC -Xmx8G -Xms8G -XX:+AlwaysPreTouch"

OpenJ9 ​

IBM 开发的 JVM 实现，以前似乎效果不好，就给了开源组织，现在又拿回来了。注意，JVM 不和 jdk 绑定，只是我选择了 IBM 的带 OPENJ9 的 JDK

Eclipse OpenJ9（以前称为 IBM J9）是一种高性能、可扩展的 Java 虚拟机 （JVM） 实现，完全符合 Java 虚拟机规范。J9 JVM 成为许多 IBM 企业中间件产品的运行时引擎，在这些产品中，它以高性能、可伸缩性和可靠性而闻名。

2017 年，J9 成为 Eclipse 基金会的一个项目，名为 Eclipse OpenJ9。Eclipse OpenJ9 JVM 完全符合 Java JVM 规范。与 Oracle 的 HotSpot VM 相比，OpenJ9 在相似的整体吞吐量下具有更高的启动性能和更低的内存消耗。

IBM® Runtimes for Business(OpenJDK with Eclipse OpenJ9) ​

默认状态下内存极低，稳定性好，但是并不以高性能见长。也许和参数调优有关系，根据使用者所述，适用范围较广，需要针对性研究下

虽然说在单项测试中，被各类 JDK 吊起来爆锤。但是在实际测试中并不是吊车尾，内而且存也是一等一的节省。如果你的内存不太充裕，那可以考虑试试

我就简单的把 IBM 的这个 JDK 叫 OpenJ9，因为测评列表里只有它一个 J9 JVM

IBM Semeru Runtimes 使用 OpenJDK 中的类库以及 Eclipse OpenJ9 Java 虚拟机，使开发人员能够构建和部署 Java 应用程序，这些应用程序将快速启动，提供出色的性能，同时使用更少的内存。

Zing ​

官网的介绍概括下来就差不多这个意思，实测确实是一等一的强。不愧是以前做软硬一体，大神云集的公司

Azul Platform Prime：极快的性能，带来超乎想象的价值

Zing(Azul Platform Prime) ​

使用了大名鼎鼎的 G4GC(GPGC)，很早就宣称能够实现无 gc 暂停时间(实际由于 linux 本身就有低于 10ms 的暂停，所以一般不会配置真无 GC 暂停时间)

怎么说呢，完全就是全方位无死角。除了使用条款限制了只能个人非商用做测试

一个真正卓越的 Java 平台，可以将您的基础设施成本降低一半。Azul Platform Prime 通过超优化的运行时间增强 Java 生态系统的性能和可扩展性，最大限度地提高性能，同时显著降低基础设施成本。

本次测评包含了 17 LTS 和 19 STS 版本

HotSpot ​

经典 jvm，几乎所有的 JDK 都是基于 HotSpot

HotSpot，作为 Java HotSpot Performance Engine 发布，是一个用于桌面和服务器计算机的 Java 虚拟机，由 Sun Microsystems 开发，现在由 Oracle 公司维护和分发。它通过实时编译和自适应优化等方法提高了性能。

Oracle GraalVM ​

其实 GraalVM 某种意义上是独立于 HotSpot 的一个 JVM 实现，但是由于大量复用了 HotSpot 的代码，因此暂时和 HotSpot 放在一起

java 未来的希望，向云原生转型的关键稻草(和本次测评没什么关系)。JAVA 全村的希望(性能真的强)

由于 graalvm 的本地编译需要知道用到的所有方法，但是 mc 用到了大量的反射，因此，只有原版可以编译为本地镜像。但是据说体感原生原版性能也就那样，代码还是太烂了

更快速、更智能、更精简。GraalVM 是一款高性能 JDK，可提高基于 Java 和 JVM 的应用的性能并简化 Java 云原生服务的构建和运行。它提供优化的编译器，可以更快地生成代码并降低计算资源消耗，实现微服务即时启动。GraalVM 包含在 Java SE 通用订阅中，无需额外付费

本次测评包含了 graalvm-ce 和 graalvm-jdk 作为新 JDK 的参考，graalvm-jdk 是 Oracle 的商业版，带了 Oracle 闭源的优化。某种意义上可以视作 zulu 和 zing 的关系

graalvm-ce-17 搁真实测试场景里是真的菜，换 20 版本倒是能名列前茅。但是 graalvm-jdk 的表现就是一等一的强了，和 zing 可以说难分伯仲

Oracle Java ​

正宗本家 java，吾未见其明也(人话: 晦气！)

Oracle Java 是广受欢迎的编程语言和开发平台。它有助于企业降低成本、缩短开发周期、推动创新以及改善应用服务。如今，Java 仍是企业和开发人员的首选开发平台，全球有数百万开发人员运行超过 60 亿台 Java 虚拟机。

Temurin(Adoptium OpenJDK) ​

以前经典的 openjdk，在 oracle JDK 要注册才能下载的年代，似乎大家都用这个。可以作为 java 标准性能的参考

实测效果已经不如更具独门秘籍的 JDK 了，老东西该爆金币了

Java™ 是世界领先的编程语言和平台。Adoptium 工作推进和支持高质量、TCK 认证的运行时和其相关技术，使其在 Java 生态系统中应用。Eclipse Temurin 是 Adoptium OpenJDK 发行版的名称。

  • 许可证: GPLv2+Classpath extension
  • 支持环境
    • Linux: X64, aarch64, s390x, ppc64le, arm
    • Alpine Linux: X64
    • Windows: X64, X86
    • macOS: X64, aarch64
    • AIX: ppc64
    • Solaris: sparc v9, X64

Open JDK ​

oracle 风味的 open jdk？目前似乎是由 oracle 管理，老 java 正黄旗的 jdk

还可以

这是什么？在开源上进行协作的地方 Java 平台、标准版和相关项目的实现。

本次测评包含了 17 LTS 和 20 STS

Zulu(Azul Platform Core) ​

不再使用 Azul 独有的 G4GC，而是改用了默认的 G1GC ，但是号称也能做到低 gc 时间。实测虽然没有 Zing 那么惊人的效果，但是也是 OpenJDK 里的第一梯队

世界上技术支持最好的 OpenJDK 版本。更多 JAVA – 比 Oracle 少 90%，Azul Platform Core 专为企业而设计，具有运行当今基于 Java 的业务关键型服务所需的认证版本、严格的安全性和成本效率。

  • 许可证: GPLv2+Classpath extension
  • 支持环境
    • Linux: X86, X64, aarch64, arm, ppc64
    • Alpine Linux: X64, aarch64
    • Windows: X86, X64, aarch64
    • macOS: X64, aarch64
    • Solaris: X64， sparc v9

Microsoft Build of OpenJDK ​

官方启动器钦定版本，微软的 OpenJDK 实现。实际效果只能说中规中矩

Microsoft Build of OpenJDK 是 OpenJDK 的一种免费分发版，它是开放源代码，任何人都可将其免费部署到任意位置。

  • 许可证: GPLv2+Classpath extension
  • 支持环境
    • Alpine Linux: X64
    • Linux: X64, aarch64
    • Windows: X64, aarch64
    • macOS: X64, aarch64

Red Hat build of OpenJDK ​

正统 Shenandoah GC，该 GC 是红帽研发的，因此红帽的 JDK 应该也是适配最好的。理论上来说，红帽 jdk 仅供 RHEL 使用，而 RHEL 是支持 arm64 的，但是下载包中并不包含 arm64 的，因此 arm64 兼容性未知

没什么特别的

Oracle JDK 已不再免费提供生产工作负载和补丁。红帽 ® 版 OpenJDK 是 Java 平台标准版（Java SE）的一个免费开源实现。该替代方案可以让您的企业在未来数年内几乎无需进行任何迁移工作，便能稳定和标准化自己的 Java 环境。

Liberica JDK ​

BellSoft 的号称 100% 开源的 JDK，似乎有一批拥趸。实际看效果也是比较一般的水平

适用于现代 Java 部署的 Java™ 运行时，由领先的 OpenJDK 贡献者提供支持。深受云公司的信赖。 高性能且安全

  • 许可证: GPLv2+Classpath extension
  • 支持环境
    • Windows: X86, X64, aarch64
    • macOS: X86, X64, aarch64
    • Linux: X86, X64, ppc64, aarch64, arm
    • Alpine Linux: X86, X64
    • Solaris: X86, X64， sparc v9

阿里龙井(Dragonwell) ​

阿里的 AJDK 的开源版本，国内呼声很高，实测阿里的 JAVA 姿势水平确实高，性能和稳定性都不错

Alibaba Dragonwell 是一款免费的, 生产就绪型 Open JDK 发行版，提供长期支持，包括性能增强和安全修复。阿里巴巴拥有最丰富的 Java 应用场景，覆盖电商，金融，物流等众多领域，世界上最大的 Java 用户之一。Alibaba Dragonwell 作为 Java 应用的基石，支撑了阿里经济体内所有的 Java 业务

Amazon Corretto ​

为了应对 Oracle JDK 许可证的变化，亚马逊也维护了一份 OpenJDK 发行版。似乎是最早 frok java 的云厂商，但是没什么起色

forge 好像官方推荐这个。实际运行的效果也还可以，但是在单项测评中表现不佳

Amazon Corretto 是开放 Java 开发工具包 (OpenJDK) 的免费、多平台、生产就绪型发行版。Corretto 提供长期支持，其中包括性能增强和安全修复。亚马逊在内部的数千种生产服务上运行 Corretto，并且 Corretto 已被证明能够兼容 Java SE 标准。借助 Corretto，您可以在常用操作系统（包括 Linux、Windows 和 macOS）上开发和运行 Java 应用程序。

  • 许可证: GPLv2+Classpath extension
  • 支持环境
    • Linux: X64, aarch64
    • Windows: X64
    • macOS: X64, aarch64
    • Alpine Linux: X64, aarch64

毕昇 JDK(BiSheng) ​

普普通通 jdk 发行版，估计是为了适配自家平台。另外有趣的一点是和其他 JDK 以咖啡命名的方式不同，鲲鹏开发套件下的命名更具国风

实测感觉主要还是为了避免被断供应链？整体表现也只能说中规中矩。但是内存占用似乎很低

毕昇 JDK 基于 OpenJDK 开发，是一个高性能、可用于生产环境的 OpenJDK 发行版。毕昇 JDK 运行在华为内部多个产品上，积累了大量使用场景和 Java 开发者反馈的问题和诉求，解决了业务实际运行中遇到的多个问题，并在 ARM 架构上进行了性能优化。毕昇 JDK 运行在大数据等场景下可以获得更好的性能。毕昇 JDK 8 与 Java SE 标准兼容，目前支持 Linux/AArch64 和 Linux/x86_64 平台。毕昇 JDK 同时是 OpenJDK 的下游，会持续稳定为 OpenJDK 社区做出贡献。

腾讯 Kona(Tencent Kona) ​

腾讯的主要技术栈是 c++，不知道能否带来惊喜

实测表现平平无奇，就和 java 在鹅厂中的占比一样。是个小透明

腾讯 Kona 是一个基于 OpenJDK 定制的，生产环境可用，高性能，安全稳定，兼容多种运行平台的 OpenJDK 开源发行版本。提供企业级 JDK 服务，由腾讯专业技术团队提供技术维护、性能优化及安全保障等服务，为您提供最优的 Java 云生产环境及解决方案。

SapMachine ​

四大 ERP 软件开发商之一，也是个隐形冠军？

实测效果意外的还可以，可能这就是老牌厂家的深厚沉淀吧

此项目包含 OpenJDK 项目的下游版本。它用于为希望使用 OpenJDK 运行其应用程序的 SAP 客户和合作伙伴构建和维护 SAP 支持的 OpenJDK 版本。

  • 许可证: GPLv2+Classpath extension
  • 支持环境
    • Linux: ppc64le, X64, aarch64
    • Alpine Linux: X64
    • macOS: X64, aarch64
    • Windows: X64

测试记录 ​

具体的详细测试结果见附图，或者是附件

本次测试主要是一个简单的定性测试，所以跑的时长“相对不够”(指几个 GB 的日志数据)

指一个单元 10 分钟，每个 JDK 测试 8 个单元，一个 JDK 测试 2-4 种参数。一共跑了 4-5 天。原始数据差不多 3.5G，整理后的数据差不多 64M。好在压缩后只有 3M

shell
hqshi@server:~/mc$ cd logs/test/
hqshi@server:~/mc/logs/test$ du -sh *
3.5G    2023_07_19_16_15_05

使用说明 ​

为了方便展示性能，我手糊了一套监控系统。前端页面可以选择不同的 JDK+参数组合、不同的监控条目以及不同的参数(比如加载区块包含了三个世界)

可以点击选择或取消选择测试条目，点击测试数据进行排序

  • 数据根据单元测试的时间做了处理，可以选择显示总览或者是每一个测试单元的最低值 p1、平均值、p99、最大值和方差
  • 图表组件是 Echart。配置了滑动显示条，可以对 xy 轴进行调整
  • 具体数据研究下从哪下载比较好，压缩后的数据不大
  • 下载地址: https://hqshi.cn/open/shared
  • 代码和测试单元部分没想好怎么开源，定制化程度很高，得研究下

选好后点击 Render 渲染图标，Dispose 返回选择界面

参数

测试结果样例，包含 MSPT、主世界区块加载、CPU 用量，堆内存用量等信息

样例

简评 ​

根据我以前撰写测评的经验，虽然说我已经设计的尽可能简化了，估计大部分人都没有看具体的测试报表的兴趣(甚至大部分人还是希望看视频，啧)。所以整理了一份文本版的图表

更具体的细节请看附件！这个分析只包含了默认模式

数据按照真实负载测试的均值 MSPT 升序排序。数据选择的是具有代表性的 auto 参数，前面有 real 的是真实负载测试子单元的数据

基准是 ms-jdk-17-auto

  • mspt 是平均 mspt，越低越好
  • rate 是加载的区块除 mspt，用于衡量 JDK 性能（有些 JDK 性能不佳，但是加载的区块少，MSPT 可能更低）。mspt 相近的，rate 越高，区块加载的越多。越高越好
  • mem99 jvm 的总内存占用的 P99，衡量内存占用 p99 比较好。越低越好
  • cpu99 cpu 占用的 p99，cpu 由于 MC 祖传单核优化，衡量高占用的情况下 P99 更合适一点，越低越好
名称msptratemem99cpu99real/msptreal/ratereal/mem99real/cpu99
[Azul]zing23.05.0.0-2-jdk17.0.7-linux_x64_auto44.44136.12%79.57%224.04%52.55137.73%138.71%298.7%
[Azul]zing23.03.0.0-3-jdk19.0.2-linux_x64_auto44.86133.93%79.97%233.58%52.95135.25%148.96%300.0%
[Oracle]graalvm-jdk-17_linux-x64_bin_auto44.13137.26%106.36%103.3%53.37140.13%109.52%119.79%
[Oracle]graalvm-jdk-20_linux-x64_bin_auto44.77136.55%82.15%115.41%53.78133.7%160.43%136.72%
[Oracle]graalvm-jdk-21_linux-x64_bin_auto47.03126.45%66.95%120.37%55.96124.02%145.08%125.52%
[Azul]zulu17.36.17-ca-jdk17.0.4.1-linux_x64_auto54.76103.3%101.92%99.45%56.52111.13%100.22%143.23%
[SAP]sapmachine-jdk-17.0.8_linux-x64_bin_auto57.297.61%106.47%104.4%57.86108.1%104.2%110.94%
[Amazon]amazon-corretto-17.0.1.12.1-linux-x64_auto55.13102.36%98.0%102.02%59.17106.03%83.95%130.81%
[Oracle]graalvm-community-jdk-20.0.2_linux-x64_bin_auto51.72110.69%53.36%103.67%59.27108.88%92.48%116.41%
[SAP]sapmachine-jdk-19_linux-x64_bin_auto56.2399.83%90.1%96.51%59.31103.88%126.12%111.72%
[Azul]zulu21.28.85-ca-jdk21.0.0-linux_x64_auto55.32102.25%59.94%116.15%59.47103.72%85.85%125.78%
[Alibaba]Alibaba_Dragonwell_17.0.2.0.2+8_x64_linux_auto54.28103.8%101.23%97.98%59.85103.22%95.97%109.9%
[Oracle]openjdk-20.0.2_linux-x64_bin_auto55.8100.97%57.66%109.72%60.26102.96%84.48%113.54%
[Microsoft]microsoft-jdk-17.0.2.8.1-linux-x64_auto55.98100.0%100.0%100.0%60.32100.0%100.0%100.0%
[HUAWEI]bisheng-jdk-17.0.7-linux-x64_auto56.3498.31%106.1%115.78%60.7299.83%79.37%131.72%
[Oracle]openjdk-17.0.1_linux-x64_bin_auto58.1993.97%93.95%100.55%60.82101.55%109.3%112.24%
[Tencent]TencentKona-17.0.3.b1-jdk_linux-x86_64_auto57.3995.68%96.61%101.47%61.0899.01%104.96%132.6%
[Temurin]OpenJDK17U-jdk_x64_linux_hotspot_17.0.1_12_auto58.1394.38%95.8%106.61%61.7497.55%100.14%123.44%
[Oracle]jdk-17_linux-x64_bin_auto56.2699.7%99.71%98.9%62.199.55%108.64%119.27%
[Liberica]bellsoft-jdk17.0.4.1+1-linux-amd64_auto56.598.3%94.36%99.45%62.2798.62%100.19%104.17%
[IBM]ibm-semeru-open-jdk_x64_linux_17.0.3_7_openj9-0.32.0_auto71.8369.25%41.72%95.23%63.290.28%65.82%92.19%
[RedHat]java-17-openjdk-17.0.7.0.7-1.portable.jdk.el.x86_64_auto57.3696.58%97.97%109.54%64.0494.75%78.31%124.22%
[Oracle]graalvm-ce-java17-linux-amd64-22.3.0_auto52.67107.28%96.83%103.85%73.7282.65%102.18%108.85%

分析 ​

浮光掠影 ​

虽然在对比查询国内外资料后，我敢说全世界的 MC JDK 横评测评文章中都没有我对比的 JDK 数据多，测试数据全

但是摸底测试挑选了太多的 JDK 和参数组合了，很多测试无法做的很细致。比如说一次单元测试的时间只有 10 分钟， 而不是预定的一个小时。可以看到在真实测试中，运行状态并没有达到稳态

这次测试也没有加入 spark 分析等内容，也是相对可惜的。有了 spark 分析，可以更深入的看出到底是哪个方法耗时最长，是否因为不同 JDK 同一个方法运行效率不一样，所以 MSPT 也不一样。这些就有待下一次精测进行分析了

还有很多测试都是我自行定下的，不是特别能反馈实际状况。比如说红石测试中，应该加入全物品开启分类，世界吞噬者运行、大生物量的农场等场景进行测试。地图加载应该也划分新地图的生成和重新加载预生成好的地图两种测试模式

高压力的大型服务器如何模拟也不太清楚，模拟测试只是单纯的加载了 100 个玩家，还需要进一步的研究如何模拟

这些就有待之后继续完善了

庸人自扰 ​

在我朴素的理解中，优化后的 G1GC、ZGC 和 Shenandoah GC 的性能应当至少不显著低于默认的 G1GC

但是具有黑色幽默意义的是，默认的 G1GC 在性能和内存占用上，具有巨大的优势

因此除非是高版本大内存占用服(16G+)或机器本身存在限制外，不推荐任何性能优化参数或使用其他 GC

日久见人心 ​

实际测试中发现，并不一定是高版本比低版本强，而且新版本比旧版本强。这个可能比较抽象，简言之就是高版本不一定新(非 LTS 版到下一个版本更新后就不维护了)

对于 GraalVM 和 Zing 这种商业版本，LTS 版本才是维护和更新的重点。但是对于后向移植没有那么热衷的普通版本而言，新版本一般会好一点

路遥知马力 ​

仔细观察图表，发现了一些有意思的事情。Graalvm 或 Zing 简称 G/Z

  1. 选择好正确的测试场景很重要，在 JDK 综合性能测试中，graalvm-ce-17 的性能其实蛮高的，但是在实际测试中，性能居然是垫底的。非常奇怪
  2. G/Z 在初期由于编译热点方法消耗资源，MSPT 实际上并没有和其他 JDK 拉开了太大的差距
  3. 在真实负载测试中，普通 JDK 随着加载区块数量的增加，MSPT 呈下降趋势。但是 G/Z 却能保持稳定的 MSPT
  4. 虽然说 Zing 的内存消耗比较高，但是仔细观察后发现 zing 的内存占用比较稳定，峰值压力反而比很多 JDK 低。但是这是接近两倍的 CPU 占用换的，服务器单开 MC 可能没问题，如果是多任务环境就需要考虑 CPU 性能是否够用了
  5. 虽然说在纯理论测试中，Open j9 的性能存在很大的缺陷，但是真实场景中，由于区块加载的少，所以性能反而和正常 JDK 差不多
  6. 这个 G(C)吧，越搞越大？目前看了下，G1GC 的 GC 时间都能保持在平均 10ms 以内。OpenJ9 的峰值 GC 时间在 100ms 以内，我不太懂是否所有阶段需要 STW(全局暂停，会导致卡顿)。然后性能最强的 Zing GC 时间可能会达到 1 秒，不过这个应该是不需要暂停的，所以无所谓。ZGC 和 Shenandoah 也是同理
  7. 到底谁在 jit？仔细观察 graalvm 和 zing 的 mspt 波动曲线，我发现了个有意思的地方。在切换场景时，zing 会产生一个比较明显的波动，同时在待机类？的测试中，和其他 jdk 有比较微小但是非误差范围内的优势。比如预热阶段、65x65 漏斗阶段和 100 名玩家召唤待机阶段

王侯将相宁有种乎？ ​

综合来看，jdk 只有三类

  1. 极致性能：Zing 和 GraalVM(都有许可证限制)
  2. 传统优化：Dragonwell or 普通 JDK
  3. 极低内存：OpenJ9

有的 JDK，生来就在罗马，而有的 JDK，生来就是牛马。依托 Azul 和 Oracle，zulu 和 graalvm-ce 的性能都不算差

综合来看 Zing(Azul Prime)和 GraalVM 即使是不优化，性能也能稳稳地处于第一梯队。而 IBM 的 OpenJ9...，只能说需要性能的场合不适合它，更适合内存不足的场景

由于现有 JDK 很多实现都会同步到 OpenJDK 这个上游，很多特性也是有开源实现的(比如 zing 的 g4gc 的初始版本)。因此除了故意藏着掖着的特性，大部分的特性其实没有太多的黑魔法，没有速度超级加倍的可能

一份性能，一分消耗。综合来看，资源消耗最低的 openj9 性能是最差的，而性能最强的 zing 的消耗则是多得惊人

大道至简 ​

目前来看，除了跑图，几乎所有的游戏处理都依赖单线程性能。而且最神奇的是，即使是编译成了原生的二进制文件的 MC 原版服务端(有一些 graalvm 测试)，不使用 java 解释器，性能也非常的差

可以说 mc 服务端的处理能力和处理器的单线程性能有着线性相关的关系，E5 上就算是优化到了极点，一颗超频到 6.0GHz 的 13900ks + Openj9 默认也能秒杀

如果真想开一个 MC 服务器，除了优化游戏和运行环境参数外，也需要大力出奇迹，直接对 java 进行一个狂暴鸿儒

极致性能的服务器的选型建议（主要看思路，14 代已出|2023-11）

  • 处理器和主板 1x600K(1x7K 都可以) + 微星 z690i unify (5000)
    • 由于 MC 服务器的性能主要和单线程有关，对多线程和主板扩展的要求低。ITX 主板不仅节约空间而且双槽内存槽的超频能力强，能加速计算
    • 关闭超线程，保证低负载 6.0ghz(动态超频，定频 5.8)，手动降频小核到 4.0ghz 以下，避免抢功耗。这应该是能保持长期稳定的挡位，但是散热需要做好
    • 如果服务端被调度到小核。手动绑定相关性，指定服务端在大核上跑
  • 内存 24Gx2 oc 到 c36@7600+ (1000)
    • MC 服务器不需要太多内存，24Gx2=48G 内存足够使用了，在不够就换成 48x2=96G。可以尝试提高带宽以提高计算性能
    • 24G 内存是 16g 内存的演进，超频性能上和 16G 接近，比 32G 好，48G 同理。超内存时两条大容量大于四条小容量
  • 硬盘 900P 280G (800)
    • 同样由于 MC 服务器不需要太多存储空间，因此可以选择性能超强的傲腾存储，重要的随机读写速度上没有对手，能打败傲腾的只有傲腾（MC 也不吃 4K 就是了，地图文件的分块很大）
    • 可以再来一个 ssd，当作备份存储的副盘
  • 额外注意
    • 如果内存超过 96G 建议使用四槽主板，内存 48Gx4，频率就别指望了。2x24G 定 7600+、2x48G 争取稳 7200+，4x48G 能 5600 开机就不错了
    • ITX 与好散热其实有点冲突的，虽然关闭了超线程后散热压力只有 253W，但是也需要一个旗舰风冷或者是一个一体水冷。建议风冷选利民、水冷选 VK，可以 B 站找 51972 的横评，yyds
    • 这是个理想情况，减配可以换 13600K、主板只需要在负载下稳定运行、固态不要掉盘就行

其实寻思了下，实际上铭瑄 H610I 加个 13600K 关超线程似乎也挺不错的，单核稳 5.8 应该没问题。2x32G 的 DDR4@3200MHz 内存很便宜，随便来个固态存储也够了。MC 其实主要是单核计算能力瓶颈，其他的我看虚拟机统计数据，没什么压力

总结 ​

整体测试下来，感想上面也说得差不多了。这里简单说下 JDK 选择分类吧

graalvm-ce 指社区版，graalvm-ee 指商业版

  • 提高性能：Zing(CPU 性能强、非商用) 或 graalvm-ee-17(泛用)
  • 降低消耗、提高性能：这个就得结合场景具体分析了，比如降低内存最大上限可以用 graalvm-ce-20，综合优化可以用 dragonwell
  • 降低消耗：Open J9

应朋友的推荐，写个简单的服务器性能调优。这个东西其实和电脑超频一样，不要指望有革命性的提升

  • 提高性能的前提是稳定，不能太过激进，总不能玩着玩着就崩溃
  • CPU 可以考虑提高频率或者定个高频，记得打开睿频。AMD auto 就好，Intel 尽量调高低负载时的睿频频率。电源计划没什么所谓，最多开个高性能就行
  • 内存可以考虑在默认(或者 XMP)设置的基础上提升频率或者降低时序，提高吞吐量。具体的可以看下平台和条子，然后找作业。比如搜索 Z790-H + 海力士Adie超频作业

这就是硬件调优指南了，主要是个人玩家更多的是有什么用什么，不会大费周章的专门买一套设备。我认识一个专门开 MC 服务器的朋友都是空调机房+定制机箱+水冷机柜，13700K 关超线程，超频到 6.0ghz 的。别说平均水平了，我自己的 13900KS 也就低负载能到 6.0ghz，还没有恒温空调冷却

总之，JDK 简单横评就差不多到这就算完结了。之后我优化一下测试流程，提高测试精度，再来一期表现好的 JDK 的精测

祝大家永不崩服，永不掉刻