Minecraft 服务器需要多少 RAM？

到底是什么决定了你需要多少 RAM

决定一台 Minecraft 服务器需要多少内存的，只有两个杠杆。其余的一切，和它们相比都只是次要因素。

• 玩家数量会逐渐推高 RAM 占用。每位在线玩家都会加载自己周围的区块，所以玩家越多——加上更高的 view-distance——同一时刻保留在内存里的世界就越多。从 4 名玩家增加到 20 名是一次实实在在的增长，但仍在可控范围之内。
• 模组和插件才是那个大得多的杠杆。Vanilla 很轻量。装几个 Paper 插件只会多占一点点。而模组包完全是另一个量级：早在第一位玩家加入之前，每个模组就已经把自己的代码、物品、方块和世界生成逻辑加载进了内存，这也正是为什么一个 200 个模组的 CurseForge 整合包，在玩家数相同的情况下，可能需要 Vanilla 服务器好几倍的 RAM。

整套逻辑就是这么简单：Vanilla 随玩家数扩展，模组服随模组数量扩展。世界的大小和存续时间也会把这个数字往上顶一点——一张开阔、运行了好几年、加载了大量区块的地图，开销要比全新的地图更大——但你真正需要围绕来配置规格的，还是玩家和模组。接着往下读时，请把一件事记在心里：RAM 只是服务器诸多资源中的一种，过了某个临界点，它就不再是那个起决定作用的因素了（关于这一点，详见为什么更多 RAM 并不总是解决之道）。

按配置区分，Minecraft 服务器分别需要多少 RAM

下面就是我们制定套餐时所依据的规格配置——也是我们会推荐给朋友的同一组数字。“建议 RAM”指的是分配给服务器本身的内存，而不是你 PC 的总内存，后者还需要在此之上留出余量（见如何分配内存）。

正在跑模组包，却不确定自己落在哪一档？模组包的体量和玩家数量都会把你往表格上方推——Minecraft 模组服务器指南对各种加载器和模组包体量做了更详细的拆解。

如何把这些 RAM 分配给你的服务器

知道数字只完成了一半的工作；另一半，是真正把这些内存交给服务器。具体怎么做，取决于服务器跑在哪里。

自建：-Xmx 与 -Xms 参数

当你自己启动服务器 jar 文件时，有两个参数控制着它的内存。-Xmx 设定最大堆内存（上限），-Xms 设定初始堆内存。对于 Minecraft，经过大量验证的通行建议是把两者设为相等，让 JVM 一开始就把全部内存抓到手，而不是在负载下临时扩容：

java -Xms4G -Xmx4G -jar server.jar nogui

这行命令会启动一台分配了 4 GB 的服务器。有几个地方常常把人绊住：

• 使用 64 位 Java。32 位 Java 能寻址的内存不超过大约 1.5 GB，所以如果 -Xmx4G 无法启动，通常就是这个原因。任何当前版本的 Temurin 或 Java 25 构建都是 64 位的。
• 千万别把全部 RAM 都给服务器。至少给操作系统留 1-2 GB；如果你还在同一台 PC 上运行 Minecraft 客户端，就要留得更多——游戏本身需要在服务器之外占用自己的那份内存。
• 接着用 Aikar's flags 做调优。基本设置跑通之后，社区公认的“Aikar's flags”会针对 Minecraft 的内存特征重新调校 Java 的 G1 垃圾回收器，以一点点 RAM 为代价，换来明显更平稳的 tick。它是超越裸 -Xmx/-Xms 之后的标准下一步。完整的自建教程——jar 文件、EULA、端口转发等等——都在《如何搭建 Minecraft 服务器》里。

托管：选好规格，原地升级

在托管服务器上，没有任何参数需要你去编辑。下单时你用滑块选择 RAM，套餐就按那个规格开通——启动参数（包括 Aikar's flags）已经替你调好了。

当你超出最初的预估时，真正的优势就显现出来了：在 Minecraft 托管页面上，你把滑块往上拨，多出来的 RAM 就会应用到同一台服务器上，世界和设置原封不动——无需重装，无需迁移，大约一分钟就能搞定。这正是上面那条经验法则说“先选小的”的原因：在托管套餐上，日后加 RAM 只需花一分钟，别无成本。

服务器需要更多 RAM 的信号

你的服务器是不是内存吃紧，其实不用猜。它会用几种一眼就能认出的方式告诉你：

• tick 跟不上了。控制台会打印出 Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s)，在游戏里则表现为橡皮筋式的回弹、生物卡住不动，以及方块要过一会儿才被打破。
• 保存世界时卡顿。每隔几分钟出现一次短暂的卡顿，且时间点和自动保存对得上，往往意味着服务器正在为内存而挣扎。
• 直接崩溃。最明确的信号，莫过于崩溃日志里出现 java.lang.OutOfMemoryError: Java heap space——服务器申请的内存超过了它 -Xmx 上限所允许的额度。

想搞清楚到底是哪种情况，免费的 spark 性能分析器（运行 /spark health 或 /spark profiler）能显示 tick 耗时和内存占用，托管面板则会把实时 RAM 画成一张曲线图。如果内存始终紧贴上限，就加大规格；如果内存还有余量、tick 却依旧卡顿，请先读下一节。

为什么更多 RAM 并不总是解决之道

这一部分，是大多数配置建议都会略过的。Minecraft 的主游戏循环——也就是负责移动生物、催熟作物、处理红石的那个“tick”——主要跑在单个 CPU 线程上。内存负责装下整个世界；真正在“思考”的，是一个核心。一旦服务器的 RAM 足够装下所有东西，再往上加，也不会让那个核心变快分毫。

有两条推论值得你记牢：

• 如果 RAM 还有余量、tick 却在卡顿，那瓶颈就是 CPU，而不是内存。给一台卡在单核上的服务器堆上 32 GB，什么都改变不了。这是人们在配置规格时最常犯的一个错误。
• RAM 太多甚至可能帮倒忙。过大的堆会让 Java 的垃圾回收器一次要清扫的东西更多，这可能变成更长的暂停卡顿——这又是“宁可选小一号”这条法则成立的一个理由。

当 CPU 成为瓶颈时，真正能带来改变的是高主频。这正是为什么 HytHost 让 Minecraft 跑在高主频的 Ryzen 和 Intel i9 CPU 上，而不是一大堆慢核心——Minecraft 在意的是单个核心有多快，而不是核心有多少个。在软件层面，你可以通过调低 view-distance 和 simulation-distance、预先生成世界区块、运行 Paper 而非 Vanilla，或在模组配置上加入 Lithium 这类性能优化模组，来给那个核心减负。RAM 让你的世界得以加载；而 CPU 和你的软件选择，才决定了它运行得有多流畅。