Minecraft Performance Flags Benchmarks
1.0.0
這是針對 Minecraft 調整 Java 的指南。每個標誌和調整都經過單獨基準測試以測試回歸，並根據 Java 預設值進行檢查以避免冗餘。
雖然這些調整顯著減少了一些伺服器和用戶端的卡頓，但最多只能實現適度的 TPS 增益 + 最小的 FPS 增益，並且會稍微增加 RAM + CPU 使用率。它們並不能取代使用 Spark 或 Observable 等 mods 來清除延遲的東西。
對於問題等的不和諧：https://discord.gg/zeFSR9PnUw
所有標誌均使用 Benchmark.py 腳本進行測試。請參閱正在進行的 Benchmarks.md。
對於 Minecraft 1.16.5 及更高版本，請使用 Java 17。 1.16.5 mod 都是相容的與Java 17。
有時，Java 11 可以工作，而 Java 17 則無法運作。
1.12.2 及以下版本通常需要 Java 8。
Azul、Microsoft、Adoptium、Amazon 等公司的 Java 執行階段基本上相同。一些值得注意的例外：
Oracle GraalVM 企業版具有更積極的 Java 編譯器。這是我個人用來運行 Minecraft 的，請參閱下面的 GraalVM 部分。
英特爾的 Clear Linux OpenJDK使用與任何其他 OpenJDK 相同的程式碼（使其高度相容），但建置過程本身和依賴項針對較新的 CPU 進行了最佳化。透過swupd 、Distrobox 或 Docker 從 Clear Linux 的儲存庫中取得它。請注意，您必須回滾到 Java 17 版本，而 Java 18 會恢復一些效能增強。
Azul 的 Prime OpenJDK非常快，因為它連接到 llvm，但它目前與大多數 mod 不相容，並且僅適用於 Linux。從這裡取得：https://docs.azul.com/prime/prime-quick-start-tar
Red Hat Java 8有 Shenandoah 垃圾收集器。它由免費電子郵件註冊提供：https://developers.redhat.com/products/openjdk/download
IBM 的 OpenJ9在 Minecraft 中慢得多，並且使用與任何其他 Java 構建完全不同的標誌，但它確實比基於 OpenJDK 的運行時消耗更少的記憶體。請參閱常見問題、基準資料夾和此要點以了解低記憶體消耗標誌。
如果您不知道該選擇什麼，我推薦 GraalVM EE（請參閱下文）或最新的 Adoptium Java 17 JRE：https://adoptium.net/
Couleur 在這裡維護著一份良好的 JRE 運行清單：https://rentry.co/JREs
這些優化標誌可與任何 Java 11+ 版本一起運作。它們在伺服器和客戶端上工作：
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysActAsServerClassMachine -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseNUMA -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M -XX:-DontCompileHugeMethods -XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 -XX:+UseVectorCmov -XX:+PerfDisableSharedMem -XX:+UseFastUnorderedTimeStamps -XX:+UseCriticalJavaThreadPriority -XX:ThreadPriorityPolicy=1 -XX:AllocatePrefetchStyle=3
您必須將垃圾收集標誌新增至這些 java 參數。
-Xmx8G -Xms8G -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseNUMA -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M -XX:-DontCompileHugeMethods -XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 -XX:+UseVectorCmov -XX:+PerfDisableSharedMem -XX:+UseFastUnorderedTimeStamps -XX:+UseCriticalJavaThreadPriority -XX:ThreadPriorityPolicy=1 -XX:AllocatePrefetchStyle=3 -XX:+UseG1GC -XX:MaxGCPauseMillis=37 -XX:+PerfDisableSharedMem -XX:G1HeapRegionSize=16M -XX:G1NewSizePercent=23 -XX:G1ReservePercent=20 -XX:SurvivorRatio=32 -XX:G1MixedGCCountTarget=3 -XX:G1HeapWastePercent=20 -XX:InitiatingHeapOccupancyPercent=10 -XX:G1RSetUpdatingPauseTimePercent=0 -XX:MaxTenuringThreshold=1 -XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5.0 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150 -XX:GCTimeRatio=99 -XX:+UseLargePages -XX:LargePageSizeInBytes=2m
最小和最大（ -xms和-xmx ）記憶體應設定為相同的值，如下所述：https://dzone.com/articles/benefits-of-setting-initial-and-maximum-memory-siz
一個例外是：如果您使用的是低內存系統，而《我的世界》幾乎佔用了您所有的 RAM，請將最小內存設置為低於最大內存，以盡可能節省內存。
大小以兆位元組 ( -Xms4096M ) 或千兆位元組 ( -Xmx8G ) 為單位設定
分配太多記憶體可能會破壞 gc 或減慢 Minecraft 的速度，即使您有足夠的空閒記憶體。分配太少也會減慢或破壞遊戲。當 Minecraft 運行時，請密切注意 Windows 任務管理器（或 DE 的系統監視器），並僅分配所需的空間（通常小於 8G）。 sparkc gcmonitor會告訴您分配是否太高（暫停時間太長）或太低（頻繁 GC，並在通知中顯示記憶體不足警告）。
垃圾收集標誌必須新增至 Minecraft 伺服器和用戶端，因為預設「暫停」會停止並收集垃圾清單，因為用戶端上會卡頓，伺服器上會出現延遲。使用 Spark mod 中的/sparkc gcmonitor指令來觀察遊戲中的暫停情況。任何老年代暫停都是不好的，年輕代 G1GC 收集應該不頻繁，但足夠短以至於難以察覺。
選擇一組標誌。我推薦在客戶端使用 Shenandoah ，在強大的 Java 17 伺服器上使用 ZGC ，在 Graal 上或在 RAM 和內核較少的伺服器/客戶端上使用 G1GC ：
ZGC 非常適合高記憶體/高核心數伺服器。我無法測量它對伺服器吞吐量的影響，並且絕對不會卡頓。然而，它比其他垃圾收集器需要更多的 RAM 和更多的核心。
不幸的是，它對我的（8 核/16 線程）筆記型電腦造成了顯著的客戶端 FPS 影響。請參閱基準測試資料夾中的“ZGC”基準測試。它在 Java 8 中不可用，並且在 Java 11 中的效能比 Java 17 低得多。
-XX:+UseZGC -XX:AllocatePrefetchStyle=1 -XX:-ZProactive啟用它，但會比通常為其他 GC 分配更多的 RAM 和更多的ConcGCThreads 。請注意，ZGC 不喜歡 AllocatePrefetchStyle=3，因此將其設為 1 會覆蓋先前的條目。 U
Shenandoah 在客戶端上表現良好，但在我的測試中降低了伺服器吞吐量。使用-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:ShenandoahGuaranteedGCInterval=1000000 -XX:AllocatePrefetchStyle=1啟用它
請在此處查看更多調整選項。 「herustic」和「mode」選項對我來說沒有太大變化（「compact」除外，您不應該使用它）。與 ZGC 一樣，Shenandoah 也不喜歡 AllocatePrefetchStyle=3。
請注意，Shenandoah 不在 Java 8 中。如果您是 Java 8 用戶，則必須使用 Red Hat OpenJDK 才能使用 Shenandoah：https://developers.redhat.com/products/openjdk/download
G1GC 是預設的垃圾收集器，也是 GraalVM 使用者唯一可用的垃圾收集器。 Aikar 著名的 Minecraft 伺服器 G1GC 參數在客戶端上運作得很好，但有兩個警告：它們透過將G1NewSizePercent設定得這麼高，有效地限制了MaxGCPauseMillis參數，在某些客戶端上產生長時間的口吃，並且它們收集舊代垃圾過於積極（因為客戶端產生的垃圾遠遠少於已填充的伺服器）。
這些與 aikar 標誌類似，但具有更短、更頻繁的暫停、不太激進的 G1 混合收集和更激進的背景收集： -XX:+UseG1GC -XX:MaxGCPauseMillis=37 -XX:+PerfDisableSharedMem -XX:G1HeapRegionSize=16M -XX:G1NewSizePercent=23 -XX:G1ReservePercent=20 -XX:SurvivorRatio=32 -XX:G1MixedGCCountTarget=3 -XX:G1HeapWastePercent=20 -XX:InitiatingHeapOccupancyPercent=10 -XX:G1RSetUpdatingPauseTimePercent=0 -XX:MaxTenuringThreshold=1 -XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5.0 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150 -XX:GCTimeRatio=99
G1NewSizePercent和MaxGCPauseMillis可用於調整年輕代集合的頻率/持續時間。如果您的設定出現任何舊年代暫停，則應刪除G1HeapWastePercent=18 。或者，您可以提高它並將G1MixedGCCountTarget設為 2 或 1，以使混合垃圾收集更加惰性（以更高的記憶體使用量為代價）。
伺服器上更容易接受較長的暫停。這些標誌非常接近 aikar 預設值：
-XX:+UseG1GC -XX:MaxGCPauseMillis=130 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=28 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=20 -XX:G1MixedGCCountTarget=3 -XX:InitiatingHeapOccupancyPercent=10 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=0 -XX:SurvivorRatio=32 -XX:MaxTenuringThreshold=1 -XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150
-XX:ConcGCThreads=[Some Number]控制垃圾收集器允許使用的後台執行緒的最大數量，預設為logical (hyperthreaded) cores / 4 。如果需要，最新版本的 Java 將減少 gc 執行緒的數量。
在某些情況下（特別是使用 ZGC 或 Shenandoh），您希望將此線程上限增加到超過預設值。我建議在具有 4 個執行緒的 CPU 上使用“2”，在大多數其他 CPU 上使用[number of real cores - 2] ，但您可能需要使用此參數。如果它太低，垃圾收集將無法跟上 Minecraft，並且遊戲將卡頓和/或開始消耗大量 RAM 並崩潰。如果它太高，可能會減慢遊戲速度，特別是如果您運行的是 Java 8。
不需要像ParallelGCThreads或JVMCIThreads這樣的其他「執行緒」標誌，因為它們在 Java 8+ 中透過良好的自動設定預設為啟用。
注意：大頁面需要 Windows 上的管理員權限。這是一個安全風險，如果您對此感到不舒服，您應該跳過此部分。
啟用大頁面可以提高 Minecraft 伺服器和用戶端的效能。以下是一些啟用它的精彩教學：
在 Windows 上，您必須以管理員身分執行 java 和啟動器。這意味著檢查javaw.exe 、 java.exe和your launcher.exe的「以管理員身份執行」相容性複選框，否則大頁面將默默失敗。將-XX:+UseLargePages -XX:LargePageSizeInBytes=2m加入您的參數。
在 Linux 上，您通常需要使用-XX:+UseTransparentHugePages 。要手動分配記憶體（以獲得更大的效能提升），Red Hat 為類似RHEL 的Linux 發行版（如Fedora、CentOS 或Oracle Linux）提供了一個很好的教學：https://www.redhat.com/ en/blog/optimizing -rhel-8-run-java-implementation-minecraft-server
檢查並查看 Java 17 中的-Xlog:gc+init java 參數是否支援大頁面。
在任何 Java 版本/平台中，如果大頁面不起作用，您將在日誌中收到類似於以下內容的警告：
Java HotSpot(TM) 64 位元伺服器 VM 警告：JVM 無法使用大頁面內存，因為它沒有足夠的權限來鎖定內存中的頁面。
GraalVM 是 Oracle 的一款新 Java VM，可提高（經過修改的和普通的）Minecraft 的效能。雖然客戶端 FPS 提升不大，但伺服器端工作負載（例如區塊產生）可以獲得 20% 以上的提升！
只有 GraalVM 企業版附帶全套優化。透過 Oracle 的直接連結下載：
Windows AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-windows-amd64-22.3.1.zip
Linux AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-linux-amd64-22.3.1.tar.gz
Linux AARCH64（ARM 64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-linux-aarch64-22.3.1.tar.gz
Mac AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA17_22_3_1/graalvm-ee-java17-darwin-amd64-22.3.1.tar.gz
Windows AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-windows-amd64-22.3.1.zip
Linux AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-linux-amd64-22.3.1.tar.gz
Linux AARCH64（ARM 64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-linux-aarch64-22.3.1.tar.gz
Mac AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA11_22_3_1/graalvm-ee-java11-darwin-amd64-22.3.1.tar.gz
Windows AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-windows-amd64-21.3.5.zip
Linux AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-linux-amd64-21.3.5.tar.gz
Mac AMD64（64 位元）：https://oca.opensource.oracle.com/gds/GRAALVM_EE_JAVA8_21_3_5/graalvm-ee-java8-darwin-amd64-21.3.5.tar.gz
（AUR 和 Oracle Linux 儲存庫上也提供了部分 GraalVM EE 版本）
適用於 ARM Mac 的新版本需要在 Oracle 的主要下載頁面上免費註冊：https://www.oracle.com/downloads/graalvm-downloads.html
這些版本不是 Java 安裝程式。您需要手動替換啟動器的 Java 版本，或使用支援指定 Java 路徑的 Minecraft 啟動器。我推薦 ATLauncher、Prism Launcher 或 GDLauncher。指定 java 路徑時，導覽至 GraalVM 下載中的「bin」資料夾並使用「javaw.exe」或「java.exe」。
對於伺服器，您需要將伺服器啟動 sh/bat 檔案中的「java」命令替換為 graalvm java 的完整路徑（以引號引起來）。
或者，您可以按照 Oracle 指南在系統範圍內安裝它：https://www.graalvm.org/22.2/docs/getting-started/#install-graalvm
GraalVM EE 22+ Java 17（或 Java 11）的參數：
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysActAsServerClassMachine -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseNUMA -XX:AllocatePrefetchStyle=3 -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M -XX:-DontCompileHugeMethods -XX:+PerfDisableSharedMem -XX:+UseFastUnorderedTimeStamps -XX:+UseCriticalJavaThreadPriority -XX:+EagerJVMCI -Dgraal.TuneInlinerExploration=1 -Dgraal.CompilerConfiguration=enterprise
您必須將 G1GC 與這些參數一起使用。 GraalVM 目前無法與 ZGC 或 Shenandoah 配合使用。
GraalVM EE 22.3.0 修正了所有已知的 Minecraft 錯誤
如果您執行基於 Java 8 的舊版 GraalVM，則存在一些潛在問題：
VectorizeSIMD使用 Optifine、Iris 或 Occulus 等著色器模組將實體變為不可見...但僅限於特定條件。這將在 GraalVM EE 22.3.0 中修復。請參閱：oracle/graal#4849
GraalVM CE 和 EE 都破壞了 1.16.5 Astral Sorcery 中的星座渲染。這可能與著色器錯誤有關。請參閱：HellFirePvP/AstralSorcery#1963
我還沒有觀察到任何伺服器端錯誤。
如果您遇到任何其他可以追溯到 GraalVM 的 mod 問題，請建立 Github 問題或在 Discord 中發佈！一般來說，您可以透過停用主要dgraal最佳化標誌來解決這些問題，或者透過使用Dgraal.PrintCompilation=true找到正確的函數，並在找到錯誤編譯的函數後使用-Dgraal.GraalCompileOnly=~...解決它。
SpecialK 是一種類似 ReShade 的「通用」Windows 模組，具有 2 個主要效能優勢：
「智慧型」幀限制器，可減少卡頓、消除撕裂、節省電力並節省 CPU TDP，以便在需要時進行提升。它甚至可以與 VRR 或 Nvidia Reflex 結合使用。
稱為 OpenGL-IK 的 OpenGL 到 DirectX11 包裝器，可消除 Minecraft 的視窗模式開銷，並啟用其他功能（例如自動 HDR 或可調整大小的無邊框視窗）。
在這裡下載：https://wiki.special-k.info/en/SpecialK/Tools
新增您的 MC 啟動器，然後選取「提升服務」複選框。然後導航到 javaw.exe 所在的 java bin 資料夾，並建立一個名為SpecialK.OpenGL32的空檔案。使用 SpecialK 啟動器啟動您的 Minecraft 啟動器，然後啟動器會將 SpecialK「注入」到 Minecraft 中。 
您可以透過 SpecialK UI 建立 Minecraft 啟動器的桌面快捷方式，以更加方便。
請務必關閉 VSync 和遊戲中的 Minecraft 幀限制器。
一位用戶報告運行 SpecialK 時 FPS 降低。如果您遇到這種情況，請透過 Discord 或 Github 告訴我！
啟動 Minecraft 後，使用工作管理員將 Java 設定為在 Windows 中以「高於正常」進程優先權執行：
Linux 用戶可以將sudo nice -n -10添加到啟動命令的開頭，但請注意，低於 0 的 Nice 級別（“最大”為 -20）需要以sudo運行 Minecraft。或者，在啟動 Minecraft 後使用renice指令來避免此安全風險。
這是尋找效能模組的絕佳儲存庫：https://github.com/NordicGamerFE/usefulmods
我會推薦更相容的替代方案，例如 Sodium + Iris 或 Rubidium + Oculus，而不是 Optifine。
我建議使用 Java 17，否則，請使用 Java 11，除非絕對需要 8。但如果是的話，這些標誌將與 OpenJDK8 一起使用，以及 Shenandoh GC（適用於客戶端上的 Red Hat OpenJDK）或 G1GC（適用於其他一切）：
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysActAsServerClassMachine -XX:+ParallelRefProcEnabled -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:+PerfDisableSharedMem -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:MaxInlineLevel=15 -XX:MaxVectorSize=32 -XX:+UseCompressedOops -XX:ThreadPriorityPolicy=1 -XX:+UseNUMA -XX:+UseDynamicNumberOfGCThreads -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=350M -XX:-DontCompileHugeMethods -XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 -XX:+UseFPUForSpilling -Dgraal.CompilerConfiguration=community
x86 Java 8 使用者（也稱為大多數 Java 8 使用者）可以新增下列附加參數：
-XX:+UseXMMForArrayCopy
您也可以從 Oracle 站點上的 21.X 部分取得 Java 8 版本的 GraalVM EE，並使用下列參數：
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+AlwaysActAsServerClassMachine -XX:+ParallelRefProcEnabled -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:AllocatePrefetchStyle=1 -XX:ThreadPriorityPolicy=1 -XX:+UseNUMA -XX:+UseDynamicNumberOfGCThreads -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=350M -XX:-DontCompileHugeMethods -XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000 -XX:+UseFPUForSpilling -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:+EagerJVMCI -Dgraal.TuneInlinerExploration=1 -Dgraal.CompilerConfiguration=enterprise -Dgraal.UsePriorityInlining=true -Dgraal.Vectorization=true -Dgraal.OptDuplication=true -Dgraal.DetectInvertedLoopsAsCounted=true -Dgraal.LoopInversion=true -Dgraal.VectorizeHashes=true -Dgraal.EnterprisePartialUnroll=true -Dgraal.VectorizeSIMD=true -Dgraal.StripMineNonCountedLoops=true -Dgraal.SpeculativeGuardMovement=true -Dgraal.InfeasiblePathCorrelation=true
如果運行著色器，請務必將-Dgraal.VectorizeSIMD設定為false 。
在 Clear Linux 上運行您的 Minecraft 伺服器！它是迄今為止最優化的開箱即用的 Linux 發行版，而且它還有一些其他不錯的功能（如無狀態配置系統）。它也可以很好地在AMD/Intel GPU 上運行客戶端：https://web.archive.org/web/20220916090057/https://docs.01.org/clearlinux/latest/tutorials/multi-boot/ dual-boot- win.html
Oracle Linux 對於伺服器來說也是一個不錯的選擇，因為它開箱即用，優化良好，並且可以透過套件管理器使用 Graalvm EE。對於客戶來說，基於 Arch 的發行版（例如 CachyOS 或 EndeavorOS）非常出色，因為它們對大多數硬體都有廣泛支援。
確保 Minecraft 用戶端使用的是您的獨立 GPU！檢查 F3 選項卡，並強制 Minecraft 在「 Windows 圖形設定」中使用它，而不是AMD/Nvidia 控制面板（因為它們似乎不再工作）。
Minecraft 用戶端 Linux 使用者應該查看 https://github.com/Admicos/minecraft-wayland
關閉後台的所有內容，包括 Discord、遊戲啟動器和瀏覽器！ Minecraft 是資源密集型的，不像其他應用程式那樣產生 CPU 中斷或佔用磁碟 I/O、RAM 等。
Java 18/19 有一些模組不相容。據報道，他們可以使用一些模組包，但我不確定是否有任何性能優勢。
Java 調整提高了伺服器效能和客戶端卡頓，但它們並沒有大幅提高客戶端平均 FPS（如果有的話）。為此，運行正確/最新的圖形驅動程式和效能模組更為重要：https://github.com/NordicGamerFE/usefulmods
本指南假設您在運行 Minecraft 時有一點空閒 RAM。如果您的設定受到 RAM 限制，請嘗試特別刪除以下參數： -XX:NmethodSweepActivity=1 -XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M爭論。
正如其聲譽所示，IBM 的 OpenJ9 確實節省了 RAM，但在我的測試中，伺服器 chunkgen 的速度慢了 30% 以上。如果有任何標誌使其與 OpenJDK 競爭，請在 Discord 或此處告訴我：#9
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions只是解鎖更多要使用的標誌。這些可以透過-XX:+PrintFlagsFinal和-XX:+JVMCIPrintProperties標誌列出，請參閱標誌轉儲-XX:G1MixedGCCountTarget=3 ：這是「混合」GC 中目標的 oldgen gc 區塊數。這些混合收集速度要慢得多，而且 Minecraft 用戶端不會很快產生 oldgen，因此我們可以將此值降低到 3、2 甚至 1，以獲得更短的 GC 暫停時間。-XX:+UseNUMA啟用多插槽系統的最佳化（如果適用）。不確定這是否適用於 Ryzen 或 Epyc 等 MCM CPU，但如果不適用，它會自動停用。-XX:-DontCompileHugeMethods允許編譯巨大的方法。 Modded Minecraft 有其中一些，我們不關心更高的後台編譯器 CPU 使用率。-XX:MaxNodeLimit=240000 -XX:NodeLimitFudgeFactor=8000啟用較大方法的最佳化。請參閱：https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8058148-XX:ReservedCodeCacheSize=400M -XX:NonNMethodCodeHeapSize=12M -XX:ProfiledCodeHeapSize=194M -XX:NonProfiledCodeHeapSize=194M為編譯後的程式碼保留更多空間。所有部分都必須「加起來」到ReservedCodeCacheSize 。我觀察到，經過修改的 Minecraft 使用XX:+PrintCodeCache時會遇到預設的 250 MB 限制，但即使未填充，較大的大小也會使編譯程式碼的驅逐變得不那麼激進。-XX:NmethodSweepActivity=1 （預設 10）將「冷」程式碼在快取中保留更長時間。也不存在「填滿」程式碼快取的風險，因為冷程式碼在填滿時會被更積極地刪除。-XX:+UseStringDeduplication-XX:+UseFastUnorderedTimeStamps避免系統呼叫來取得時間。其影響因係統而異，但我們並不真正關心記錄時間戳的準確性。-XX:+UseCriticalJavaThreadPriority任何東西都不應搶佔 Minecraft 執行緒。 GC 和編譯器執行緒可以等待。-XX:ThreadPriorityPolicy=1使用更廣泛的執行緒優先權。在 Linux 上需要 sudo 才能運作。有些 JDK（例如 Graal）預設啟用此功能，但有些則不然。-XX:G1SATBBufferEnqueueingThresholdPercent=30 -XX:G1ConcMarkStepDurationMillis=5 -XX:G1ConcRSHotCardLimit=16 -XX:G1ConcRefinementServiceIntervalMillis=150 ：優化G1GC 的並發收集線程/p111 .pdf-XX:G1RSetUpdatingPauseTimePercent=0 ：我們希望所有這些工作在 G1GC 並發線程中完成，而不是在暫停中完成。-XX:G1HeapWastePercent=18不要費心從老一代收集，直到它超過這個百分比。這可以避免觸發較慢的「混合」年輕代 GC，這很好，因為 Minecraft（具有足夠的記憶體）不會那麼快地填充舊代。想法來自：https://www.reddit.com/r/Minecraft/comments/k9zb7m/tuning_jvm_gc_for_singleplayer/-XX:GCTimeRatio=99作為目標，1% 的 CPU 時間應該花在垃圾收集。預設值為 12，似乎太低了。 Java 8 的預設值為 99。-XX:AllocatePrefetchStyle=3每個快取行產生一個預取指令。更積極的預取通常對於具有大緩存的較新 CPU 有用。看來要打破ZGC了。請參閱：https://github.com/openjdk/jdk/blob/bd90c4cfa63ba2de26f7482ed5d1704f9be9629f/src/hotspot/share/opto/macro.cpp#L1806-Dgraal.LoopRotation=true非預設最佳化，可能很快就會預設。-Dgraal.TuneInlinerExploration=1花更多時間做內嵌決策。對於 Minecraft，我們希望 C2 編譯器盡可能緩慢且激進。-Dgraal參數預設為啟用，並且要么作為健全性檢查、用於調試，要么作為故障安全（例如，如果有人在不知情的情況下使用其他一些標誌禁用了 JVCMI）。-XX:MaxInlineLevel=15 -XX:MaxVectorSize=32 ）只是從 Java 17 預設值複製而來。其他（如+AggressiveOpts ）僅在某些較舊的 Java 8 版本中不是預設的。-Dgraal.BaseTargetSpending=160 （預設 120）和 OpenJDK 中的一些其他標誌。具有較大快取的 CPU 可能會從中受益。-XX:+AlignVector -XX:+OptoBundling -XX:+OptimizeFill -XX:+AlwaysCompileLoopMethods -XX:+EnableVectorAggressiveReboxing -XX:+EnableVectorSupport -XX:+OptoScheduling -XX:+UseCharacterCompareIntrinsics -XX:+UseCopySignIntrinsic -XX:+UseVectorStubs-Dgraal.LSRAOptimization=true-Dgraal.OptWriteMotion=true和graal.WriteableCodeCache=true ，看起來不穩定，但在 GraalVM 22.3.0 中可能更穩定G1HeapWastePercent值。-XX:+PrintFlagsFinal和-XX:+JVMCIPrintProperties標誌來轉儲標誌描述/預設值。
