本帖最后由 紅葉 于 2022-1-29 17:22 编辑
GraalVM
新生代 JVM。
Eclipse OpenJ9
优缺点突出的 JVM。
鸣谢：
掷地有声
我不知道有什么优化办法，
能直接节约 43.3% 的内存占用，
或者是提升 36.9% 的cpu效率。
================================================================
为什么写这篇教程
优化是一个老生常谈的东西。
有些人使用过一些 调整jvm参数 的优化方案，
但是，有人想过直接更换 JVM 吗？
有哪种优化方案，能直接减少 40% 的内存占用？
有哪种优化方案，能直接提升 20% 以上的CPU效率？
================================================================
温馨提示
换JVM不仅针对服务器，对客户端也是有作用的。
换jvm之前，先考虑升级java吧。java16的gc一定比java11好，java11的gc一定比java8好
本篇教程虽然对于任何规模的服务器都会有帮助，
但是 <300人才能看出非常显著的作用，千人服还是多加点内存吧。
================================================================
各JVM介绍及场景示例
JVM，就是 Java虚拟机，是运行Java代码用的软件程序，关系着运行效率。
除官版以外，我挑选了一些已测评过，稳定且好用的版本介绍。
然后再介绍这些 JVM 适合的各种场景
JVM，就是 Java虚拟机，是运行Java代码用的软件程序，关系着运行效率。
除官版以外，我挑选了一些已测评过，稳定且好用的版本介绍。
然后再介绍这些 JVM 适合的各种场景
建议一个一个看完，因为我把好东西留在压轴了。
Hotspot
最寻常的JVM，它是本篇的参照物。
你在 java.com 和 oracle 官网下载的都会是它。实际上它可以算是“标准JVM”。
顺带一提，不知道为什么，Oracle的Hotspot比OpenJDK包含的Hotspot在CPU和内存效率上高些。
Hotspot
最寻常的JVM，它是本篇的参照物。
你在 java.com 和 oracle 官网下载的都会是它。实际上它可以算是“标准JVM”。
顺带一提，不知道为什么，Oracle的Hotspot比OpenJDK包含的Hotspot在CPU和内存效率上高些。
所以如果你坚持使用Hotspot，我建议你使用从Oracle官网下载的，而非从OpenJDK项目组下载的版本
数据(Hotspot 采用Oracle's测试)：
================================================================
GraalVM
新生代 JVM。
我测了这个数据，但是不好，就没有推荐
但是有位大佬表示想看，所以我就也写一写
优点：
CPU效率 和 内存占用 比Hotspot有微弱优势
缺点：
内存占用 和 CPU效率 不稳定
详细的数据对比(与Hotspot)：
提示：
我建议你看下面几个
Graal主要应用不是开mc服务器
它的提升主要在于把Java程序编译到native
但是不幸的是，minecraft服务器似乎不能。
下载：
================================================================
Eclipse OpenJ9
优缺点突出的 JVM。
由 Eclipse 基金会编译发行。
优点：
占用内存 极少，极少，极少。
经测试，在用于开mc服务器的时候，可以节省 30~40% 左右的内存。
你要不是用来开mc服务器还可以更变态：
缺点：
CPU性能比Hotspot 低。
GC渐渐不如Hotspot了，调优也赶不上。
有可能和某些插件 不兼容，比如momojs
OpenJ9的单线程优化比Hotspot差
详细的数据对比(与Hotspot)：
推荐应用场景及方法：
说白了就是以降低 约10% CPU效率 的代价
换取降低 约30%~40% 内存占用
适合CPU性能足够，而内存不足的场景
如 2核2g，4核4g等 CPU核心:内存G数 = 1:1 的服务器
一般在 Linux 服务器上使用更好，可以启用它的 metronome gc
注意，OpenJ9不兼容Hotspot的一些JVM参数，你可能需要另外配置
我这里推荐站友一篇文章，他的参数我一直在用，效果较好：
当然你也可以用在客户端上，客户端缺内存的情况倒是挺多的。
这样能使更多渣配玩家畅快游玩你的服务器。
下载：
================================================================
Azul Zulu
CPU效率和内存效率都很高 的 JVM
由 Azul 公司编译发行，免费。人是专门搞 JVM 的公司。
优点：
完美兼容 Hotspot JVM
CPU占用和内存占用 极其稳定，
经测试，在用于开mc服务器的时候，
最多可以节省 20% 左右的内存，
同时提升了 10~20% 的CPU效率
传承 azul 家老手艺，gc 几乎无暂停
解释：gc指java虚拟机回收内存中垃圾
缺点：
无。
纯纯的各方面提升Hotspot。
详细的数据对比(与Hotspot)：
推荐应用场景及方法：
任何场景下使用均比 Hotspot 好
如果你不是很缺内存，可以选择zulu
如果你 tps 低，zulu更能拯救你。
下载：
悄悄话：
但是azul的主打产品是zing vm，一个收费的大爹。
如果我把zing也拉到这篇测试里那其他的jvm都没有什么测的必要了。
不过zing收费都是几千几万的。。。我无法给你们推荐，我也买不起
================================================================
Alibaba Dragonwell
CPU效率和内存效率都 较高 的 JVM
由阿里巴巴公司编译发行，免费。
优点：
较为兼容 Hotspot JVM，不用担心兼容问题
CPU占用和内存占用 极其稳定，
即使进行大规模跑图、生成实体、tnt爆炸也 几乎无波动
经测试，在用于开mc服务器的时候，
节省 20~40% 左右的内存，
提升 10~30% 左右的CPU效率
缺点：
兼容性不如Zulu，有极少数插件不兼容（虽然我还没有遇到）
有些端的java检测有bug，尽管dw提供了java17版本，但是会要求java16..
详细的数据对比(与Hotspot)：
推荐应用场景及方法：
大部分场景下使用比 Hotspot 好
内存占用减少 20%~40%
CPU效率提升 10%~30%
极其稳定，不用担心 tps 波动
下载：
我不推荐用java8 Release Alibaba_Dragonwell_8.7.7 · alibaba/dragonwell8 (github.com)
================================================================
换jvm方法
================================================================
全部测试数据
应某位同学的需求测试了Kona，FDK，但是暂时不作推荐了
毕竟FDK并不是很多人能获取到，Kona的性能不是非常好。
优化建议
================================================================
释疑
mspt是什么？
好好看文章。
每tick计算时间，一般与cpu性能有关，越小说明计算速度越快
是一个缩写，全称是 microsecond per tick，即 毫秒/游戏刻
为什么不给TPS，而给一个"mspt"为单位来衡量CPU效率？
你这个测试有没有水分？
我尽力保证。
采用相同服务器核心，没有加任何JVM优化参数，也没有调整服务端参数
每次测试都是生成好世界，然后重启几次预热的
同时数据我也是等待适当时间后取得的平均数据，防止极值干扰
不过因为生成世界可能不同等等原因，我不能保证100%的公平，请见谅。
你为什么不直接传附件？github下载老慢了。
我没有权限传一个一百多M的附件。
================================================================
什么？你还想要一些建议？
你选对了JVM之后还想要更多的优化？
你选对了JVM之后还想要更多的优化？
我建议你升级Java版本。
1.12.2及以前版本最高使用 Java8
1.13以上可以随意用，我建议你直接拉到 Java16
当然 Dragonwell 现在只有 11。。
为什么？因为高版本有更多的 gc 策略
回收内存的效率更高，这样也更节省CPU
同时高版本的 JVM 的 JIT 策略也更完善
同时有些插件已经编译到高版本的 Java
高版本 Jvm 可以运行低版本的 Java字节码，反过来不行
================================================================
到此就结束啦！
趣闻：
趣闻：
鸣谢：
声明：
本文中所有数据都是本人自己测量的。
数据仅供参考，我不能保证在任何环境下都是这个结果。
引用本文任何部分请注明来源。
如果本贴帮到了您，请您回复、评分或者分享给他人，
使更多人能看到这个教程，感谢您。
如果对本文数据有疑问，请回复本贴，我可能会提供解答。
为什么不at我 渣男 分手吧
1a2s3d4f1 发表于 2021-7-29 20:49
GraalVM性能怎样呢？之前看到提高fps有用graalvm的
你好，我测了，你能从我全部测试数据里看到graalvm（第7行）。
但是因为和Hotspot差别真的不大，而且有些地方甚至比较拉，我没有写。不过下次我想起来可以把graalvm补上。
本帖最后由 1a2s3d4f1 于 2021-7-29 21:04 编辑
似乎openj9的GC性能也不高，参考10721（实际mc使用也可能出现gc问题，gc占用过高），真的奇怪，openj9的issue下还有比hotspot慢20倍的问题，实际使用却没怎么差
，我之前想从balanced gc入手，发现性能问题太严重，就发了issue，后面也出现了重改eden机制的pull
紅葉 发表于 2021-7-29 20:52
你好，我测了，你能从我全部测试数据里看到graalvm（第7行）。
但是因为和Hotspot差别真的不大，而且有些 ...
似乎openj9的GC性能也不高，参考10721（实际mc使用也可能出现gc问题，gc占用过高），真的奇怪，openj9的issue下还有比hotspot慢20倍的问题，实际使用却没怎么差
，我之前想从balanced gc入手，发现性能问题太严重，就发了issue，后面也出现了重改eden机制的pull1a2s3d4f1 发表于 2021-7-29 21:01
似乎openj9的GC性能也不高，参考10721（实际mc使用也可能出现gc问题，gc占用过高），真的奇怪，openj9的is ...
您好，我已经补上了GraalVM部分
关于OpenJ9的话，它的gc真的非常非常非常非常非常拉。其实它就是一个双刃剑vm，用垃圾gc和10%cpu效率换40%左右的内存占用，需求这种方案的服务器也是比较罕见的。
我建议的话还是选用Dragonwell，如果不是1.17的服
1a2s3d4f1 发表于 2021-7-29 21:01
似乎openj9的GC性能也不高，参考10721（实际mc使用也可能出现gc问题，gc占用过高），真的奇怪，openj9的is ...
我个人认为大多数服务器还是不很缺内存的，不需要选用j9。以及j9现在被扔进基金会了，感觉大的性能提升没有啥路了。阿里巴巴的龙井之类的变态优化也在内存上快追到了，j9现在优势真的不大，感觉只有非常非常缺内存才会用了。不过cpu要是烂的话，那还是给垃圾gc拖垮。
本帖最后由 1a2s3d4f1 于 2021-7-30 01:05 编辑
一般调下苗圃大小即可解决-Xmnx/-Xmns，但是这不太好把握，balanced gc最近在改的Eden收缩策略可能会修了这个问题（参考签名链接）。
紅葉 发表于 2021-7-29 21:08
您好，我已经补上了GraalVM部分
关于OpenJ9的话，它的gc真的非常非常非常非常非常拉。其实它就是一个双刃 ..
感谢楼主的测试，已经用上dragonwell了。本人是1.16.5的小型模组服，当服务器有15名玩家时，使用hotspot会占用约6~7G内存
使用dragonwell时内存占用居然奇迹般的维持在2~3G（之前几乎没对服务器进行任何优化）
并且tps也有肉眼可见的提高
感谢楼主，感谢阿里爹（）
1070150591 发表于 2021-7-29 22:13
感谢楼主的测试，已经用上dragonwell了。
本人是1.16.5的小型模组服，当服务器有15名玩家时，使用ho ...
感谢您的回复，因为我自己也就开了一个小服，测的数据不知道大家能否用上。。这样我推荐给别人的时候就更放心了
AdoptOpenJ9和EclipseOpenJ9是一样的吗？如果不是的话，楼主没提AoptOpenJ9。
L_inkOO 发表于 2021-7-30 10:32
AdoptOpenJ9和EclipseOpenJ9是一样的吗？如果不是的话，楼主没提AoptOpenJ9。 ...
我在OpenJ9下面给出的链接都是包含OpenJ9的AdoptOpenJDK了。。 这两个不是一个概念，AdoptOpenJDK是JDK，OpenJ9是JVM，JDK包含JVM。AdoptOpenJDK-OpenJ9 ver的概念，是使用OpenJ9作为JVM的JDK
本帖最后由 1a2s3d4f1 于 2021-8-13 20:40 编辑
现在AdoptOpenJDK转到了https://adoptium.net/，但是没得OpenJ9版本（原因参考），说明以后用openj9要自己构建
，实际上有些用OpenJ9的服务器目的不是牺牲TPS来压内存，参考htps://steinborn.me/posts/tuning-minecraft-openj9/（插话，当Xmx=Xms是，Eden堆完全扩展，为-Xmnx大小，如果用gencon，建议用-Xgc:concurrentScavenge降低gc时间）
balanced gc的主要性能问题有：1.异常的survivor堆（old堆为空，原本应该在balanced-old堆的在balanced-survivor堆，加重GC负担，但是在多次gc后会恢复正常，已修复#11862，未包含在0.27版中）
2.不合理的eden大小（Xms=Xmx时，直接调用最大eden大小为初始eden大小，可能导致性能问题），eden最大大小只有总堆大小的25%，与G1GC相比很小，考虑到mc服务端分配大量短命对象，这可能导致gc频繁触发影响性能，在修复中...（导致gc时间是g1gc 的三倍的屑gc机制）
现在AdoptOpenJDK转到了https://adoptium.net/，但是没得OpenJ9版本（原因参考），说明以后用openj9要自己构建
，实际上有些用OpenJ9的服务器目的不是牺牲TPS来压内存，参考htps://steinborn.me/posts/tuning-minecraft-openj9/（插话，当Xmx=Xms是，Eden堆完全扩展，为-Xmnx大小，如果用gencon，建议用-Xgc:concurrentScavenge降低gc时间）[警告]全局标记阶段处于在 52% 的时间内处于活动状态。这可能会影响应用程序的性能。增加堆大小可减少 GMP 的频率。
balanced gc的主要性能问题有：1.异常的survivor堆（old堆为空，原本应该在balanced-old堆的在balanced-survivor堆，加重GC负担，但是在多次gc后会恢复正常，已修复#11862，未包含在0.27版中）
2.不合理的eden大小（Xms=Xmx时，直接调用最大eden大小为初始eden大小，可能导致性能问题），eden最大大小只有总堆大小的25%，与G1GC相比很小，考虑到mc服务端分配大量短命对象，这可能导致gc频繁触发影响性能，在修复中...