Ubuntu 18.04 搭建 Minecraft 服务器：Java 调优与 screen 稳定运维实战

1. 项目概述：为什么在 Ubuntu 18.04 上亲手搭一个 Minecraft 服务器，比点几下鼠标更有价值

如果你搜过“Minecraft 服务器搭建”，大概率会看到一堆一键脚本、图形化面板、甚至云服务商的“三分钟开服”广告。但真正用过的人心里都清楚：那些方案要么锁死版本、要么埋着收费陷阱、要么连 Java 内存参数都给你写死在配置里，改都不让改。我从 2015 年开始在树莓派、VPS、甚至旧笔记本上反复折腾 Minecraft 服务器，踩过的坑比红石电路还密——比如某次更新后世界加载卡在 99%，查日志发现是 Java 的 G1GC 垃圾回收器和 Minecraft 1.16+ 的 Chunk 加载机制冲突；又比如用 screen 挂起服务后，SSH 断连导致 session 被 kill，结果整个世界存档损坏。这些事，一键脚本不会告诉你，面板也不会报错，它只会安静地等你花三天重做地图。

Ubuntu 18.04 这个版本很特别。它不是最新的 LTS（那是 20.04），也不是最老的（16.04 已停更），但它自带 OpenJDK 11，内核稳定，apt 源干净，对 Java 应用的兼容性经过了数年生产环境验证。更重要的是，它足够“轻”——没有 systemd-journal 的疯狂日志刷屏，没有 snap 包的权限迷宫，所有路径、权限、服务管理逻辑都清晰可溯。你搭的不是一个“能运行的服务器”，而是一个 完全可控的沙盒环境 ：你知道每个进程 PID 是多少，知道 -Xmx 和 -Xms 参数改的是哪块内存，知道 world 文件夹里 level.dat 里 GameType 字段怎么手动改成 1（生存模式）或 2（创造模式）。这种掌控感，是任何图形界面或托管服务给不了的。

标题里那个西班牙语 “Cómo crear un servidor de Minecraft en Ubuntu 18.04”，其实是个信号——它暗示着操作者可能正面对一份非母语文档，或者正在一个资源受限、网络不稳定的环境里工作。这恰恰说明：这个任务的核心价值，从来不是“炫技”，而是 可靠性、可复现性、低依赖性 。它不需要你懂 Java 八股文，但需要你知道 java -version 输出里 “OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.18.04.1)” 这串字符里，最后的 “18.04.1” 意味着什么；它不考你 JVM 调优的理论，但要求你实测出 -Xmx4G 在 8GB 内存机器上，为什么比 -Xmx6G 更稳；它不让你背诵 screen 的所有快捷键，但必须清楚 screen -S mcserver 和 screen -r mcserver 之间差的不是字母，而是整个服务器是否在线的生死线。这篇文章，就是写给那个正在终端里敲下 sudo apt update 、手心有点出汗、但心里清楚“这次我要自己把它跑起来”的人看的。

2. 整体设计与思路拆解：为什么放弃 Docker、Systemd、Web 面板，坚持用最“土”的方式

很多人看到“Ubuntu 18.04”第一反应是：“直接 docker run -d -p 25565:25565 itzg/minecraft-server” —— 确实快，三秒完事。但我在实际运维中发现，Docker 在这个场景下有三个硬伤：第一，文件权限混乱。Minecraft 服务器启动时会动态生成 plugins、mods、world 文件夹，Docker 容器内 UID/GID 和宿主机不一致，导致你用 ls -l 看到一堆 ? ? ? ，备份时 cp -r 直接 Permission Denied；第二，Java 内存不可见。 docker stats 显示容器只占 1.2GB 内存，但 jstat -gc <pid> 却告诉你堆内存已用满，这是 JVM 在容器内无法正确读取 cgroup memory limit 导致的，OpenJDK 11 默认不开启 -XX:+UseContainerSupport ，得手动加；第三，调试链路断裂。当服务器卡顿时，你进不去容器内部， docker exec -it mcserver bash 可能卡死，而 jstack <pid> 这种救命命令根本用不上。这不是 Docker 的问题，是它和 Minecraft 这种“半实时、高 IO、强状态”的 Java 应用天然存在抽象层摩擦。

那用 systemd 呢？ systemctl start minecraft 听起来很现代。但 Ubuntu 18.04 的 systemd 版本（237）对 Java 进程的生命周期管理并不友好。我试过把 ExecStart=/usr/bin/java -Xmx4G -Xms4G -jar server.jar nogui 写进 service 文件，结果发现：当世界生成大量新区块时，Java GC 暂停时间超过 30 秒，systemd 会误判为“服务无响应”，自动执行 KillMode=control-group ，把整个进程组（包括正在写入磁盘的 RegionFile）强行 kill -9。一次这样的误杀，就足以让 region/r.-1.0.mca 文件损坏，整片海洋地形消失。systemd 的健康检查逻辑，是为 HTTP 服务、数据库这类有明确心跳协议的应用设计的，不是为 Minecraft 这种“靠玩家移动触发计算”的游戏引擎准备的。

至于 Web 面板（如 McMyAdmin、AMP），它们本质是另一个 Java 进程套在 Minecraft 进程外面。我部署过 AMP，它确实能点点鼠标改 OP、传插件，但代价是：它默认占用 8080 端口，和 Nginx 冲突；它的 Java 进程和 Minecraft 进程共享 JVM 参数，你调大 Minecraft 的 -Xmx，AMP 就可能 OOM；最致命的是，它的文件上传功能基于临时目录 /tmp/amp-upload-xxxxx ，而 Ubuntu 18.04 的 /tmp 默认挂载了 noexec 选项，上传的 .jar 插件根本没法被 ClassLoader 加载，错误日志里只有一行 java.lang.ClassNotFoundException ，你得翻三天文档才知道是 mount 选项惹的祸。

所以最终方案回归原始： 纯 Bash + screen + 手动 JVM 参数 + 独立用户账户 。这不是怀旧，是权衡后的最优解。screen 的价值被严重低估了——它不是“老古董”，而是唯一能同时满足“进程守护”、“会话保持”、“输出捕获”、“热切换”四个需求的工具。 screen -S mcserver 创建一个命名会话， Ctrl+A, D 能安全分离， screen -r mcserver 能随时回来，所有控制台输出（包括崩溃堆栈）都保留在 buffer 里， Ctrl+A, [ 进入复制模式， Ctrl+A, ] 粘贴上一条命令，全程不依赖网络连接。更重要的是，screen 启动的进程，其父进程是 init（PID 1），不受 SSH session 生命周期影响， kill -9 不会误伤， kill -TERM 会优雅转发给 Java 进程触发 save-all。这种“简单即可靠”的哲学，在服务器运维里，永远比“高级即强大”更经得起时间考验。

3. 核心细节解析与实操要点：从 Java 环境到 server.jar 的每一个关键决策

3.1 Java 版本选择：为什么必须是 OpenJDK 11，而不是 Oracle JDK 或 OpenJDK 17

Minecraft 服务器对 Java 版本极其敏感。标题里没写具体版本，但结合 Ubuntu 18.04 的默认源和当前主流模组生态， OpenJDK 11 是唯一安全的选择 。我们来拆解几个常见误区：

• “Oracle JDK 更稳定”？错。 Ubunt