针对 Minecraft 1.8.9 Forge 的某些大量监听事件的屎山 Mod 进行优化的 JVM 参数

2025-05-18 暂无评论

你是否遇到过这种问题？

明明玩的是低版本 Minecraft，但加了几个 MOD 后，帧数突然严重下滑，甚至缩小窗口也毫无改善？
游戏画面时常一卡一卡的，明明帧数还算正常，但顿挫感却非常明显？

其实，这并不是你的电脑太差，而是Minecraft 本身就存在性能问题，加上 Forge、Java 8，以及各种监听事件频繁的 MOD 叠加在一起，就形成了严重的性能瓶颈。

我这次回坑玩 Hypixel Skyblock，同样遇到了这个问题，特别是遇到 NEU 这种重量级屎山 MOD 时，一加它你原版能跑800帧的电脑瞬间只剩60帧，稳60还都难。
NEU 就是典型的性能杀手，它拥有大量监听事件，本身内存读取负担就够大的了，但回收内存又不积极，甚至可以说是肆意妄为的拉屎，导致你的游戏性能严重下滑，甚至某些时候帧数还正常，但画面却一卡一卡的。这其实就是回收机制导致的问题，因为 Java 8 的 G1GC 回收时会直接阻塞主线程，MC 这种究极单核屎山游戏，它的渲染线程一定会跟着垃圾回收卡死。

所以我针对这些情况，精心调试了一套专门优化过的 JVM 参数。
经过实际测试，这套参数能够：
✅ 把原本只有 60 帧的情况提升到 80 帧以上；
✅ 彻底解决那种频繁出现的明显顿挫感问题。

如何使用？

你只需要复制下面的这段启动参数到你使用的启动器（比如 HMCL、PCL）的 JVM 参数框内即可：

-XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=60 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=10 -XX:InitiatingHeapOccupancyPercent=20 -XX:G1MixedGCCountTarget=5 -XX:G1HeapWastePercent=7 -XX:GCTimeRatio=20 -XX:MaxGCPauseMillis=30 -XX:SurvivorRatio=6 -XX:MaxTenuringThreshold=10 -XX:+UseTLAB -XX:-ResizeTLAB -XX:+AlwaysPreTouch -XX:+TieredCompilation -XX:CompileThreshold=500 -XX:+OptimizeStringConcat -XX:+UseFastAccessorMethods -XX:ParallelGCThreads=8 -XX:+ParallelRefProcEnabled -XX:+ExplicitGCInvokesConcurrent -XX:+DisableExplicitGC -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=2 -Xms6G -Xmx6G -Dsun.java2d.opengl=false -Dsun.java2d.dpiaware=true -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTLAB -XX:+PrintAdaptiveSizePolicy -Xloggc:"logs/gc.log"

注意事项：

如果你的 CPU 真的很差，连八个大核都没，那请把：-XX:ParallelGCThreads=8
这一参数的 8 改成你处理器的大核数。

然后，再换一个更好的 JDK，进一步提高性能：

推荐使用 Amazon Corretto 8u452+ 或阿里巴巴 Dragonwell 8u452+
Amazon Corretto 性能更加激进，帧数明显更高，但有概率在部分环境，启动超过一小时之后出现性能衰退（虽然理论上来说我这个优化后的参数已经基本不会出现）
所以如果你一次启动游戏就是玩几个小时甚至更久，我建议使用长期运行更稳定的 Dragonwell。

下载地址：
Amazon Corretto：点此下载
阿里 Dragonwell：点此下载

注意事项：

如果使用 Amazon Corretto，游戏启动后的前三分钟帧数可能较低，这是正常现象，不用担心。几分钟后就会恢复正常。
这是这个 JDK 配上我的启动参数出现的特性，热点提前编译，进入 C2 优化态后性能大幅提升。

实测效果：

众所周知，Minecraft 的性能瓶颈绝大多数都在 CPU，这在 NEU 这种大量监听事件的 MOD 环境中就更加明显了。
无论你是用 2K 分辨率全屏还是 854x480 的小窗口，帧数几乎不会改变，因为瓶颈在 CPU 和内存，而不是显卡，也就是说：全都是 CPU 帧。
（疑似9800X3D暗广）

测试环境：
CPU：Intel 12600KF
内存：DDR4-3200 CL16
显卡：RTX 4070
MOD 环境：NEU + Skytils 等各种 HUD，加上部分歪瓜端的 ESP，Nametag 等透视功能全部开启。
测试环境：Hypixel Skyblock，日常游玩（例如矮人矿洞）和往大量实体的地方跑（例如 Hub 一号大厅）

📌 默认启动参数表现：
在 Skyblock 矮人矿洞（实体少的地方）：55~60 帧，且画面非常容易出现明显顿挫感。
在玩家多的 Hub 一号大厅，ESP，Nametag 开满：甚至掉到十几帧，并且伴随明显卡顿，观察内存回收发现非常不规律不合理，导致顿挫感非常强，单次回收就是 150ms 以上的延迟。

📌 使用我的优化参数 + Amazon Corretto 后表现：
在矮人矿洞（实体少的地方）：稳定提升到 75~85 帧，非常流畅。
在玩家众多的主城（ESP、Nametag 开满）：仍可保持在 40 帧以上，且几乎无感知卡顿，因为内存回收优化合理，单次回收基本控制在 40ms，是几乎无感知的状态，非常丝滑。

如果你也用 NEU，记得去它的设置里的 Notification 类去把内存警告关了。它就是屎山，因为它自己控制不好回收才只建议你用 4GB，放高了就地狱，实测 6GB 这个 G1GC 甜品量在这个环境是最合适的，而且我也针对 6GB 专门做的回收参数。当然，8GB我也试过，但无论怎么优化，就是相比起 6GB 出现了 10% 左右的性能损失，故而也从实践证明，这里 6GB 的这套参数就是最合适的。

✨ 这套 JVM 启动参数的设计目标是：
在 Minecraft 1.8.9 超高内存瓶颈场景中，稳定实现高帧数和极低的卡顿感
利用 Java G1GC 垃圾回收策略，精准控制内存占用，避免频繁回收导致的卡顿
将内存回收控制在约 4.5~5.2G 之间，避免频繁的 GC
将 GC 停顿时间控制在 30~70ms 之间，大多数时候你都几乎察觉不到

适用环境：

这套优化的要求如下：

Java 环境：Amazon Corretto 8u452+ 或阿里巴巴 Dragonwell 8u452+；
JVM 内存：建议分配 6GB（-Xms6G -Xmx6G）；
推荐 CPU：8核及以上处理器；