Java 版开服教程维护与备份
性能定位与优化
先用数据找瓶颈，再做范围可控的改动，不靠复制粘贴参数赌运气
“卡”不是单一问题。客户端帧率低、网络延迟高、服务端单刻过慢，玩家感受都可能是卡顿，但处理方式完全不同。优化前先记录发生时间、在线人数、所在维度、最近安装的插件或模组，以及 logs/latest.log 中的异常。
先区分三类问题
| 现象 | 更可能的方向 | 先做什么 |
|---|---|---|
| 只有个别玩家画面卡 | 客户端性能、显卡、资源包或网络 | 让其他玩家复现，比较客户端 FPS 与延迟。 |
| 所有人动作延迟、方块回弹、动物不动 | 服务端刻耗时过高 | 看 MSPT、性能报告和实体/区块负载。 |
| TPS 正常但少数地区或玩家掉线 | 网络质量、路由、隧道或 Wi‑Fi | 分别测试有线、手机流量和不同网络。 |
list 只显示玩家，不会给出 TPS。不要把它当作性能指标。Paper 自带 spark 性能分析器；这是定位服务端负载的优先工具。
用 spark 先抓一次证据
在线人数与卡顿现象出现时，在控制台或游戏中执行：
/spark profiler start --timeout 300它会采集五分钟的性能数据并在结束后给出报告链接。若只想关注明显卡顿的刻，可以使用：
/spark profiler start --only-ticks-over 100 --timeout 300先保存报告，再改参数。Paper 官方排错文档建议通过 spark 报告定位具体的插件、实体、区块生成或磁盘 I/O，而不是先装所谓“万能优化插件”。Paper：Basic troubleshooting
从最小改动开始
- 确认内存边界：
-Xmx必须给操作系统、容器和其他程序留出空间。Java 进程占用接近-Xmx并不自动说明内存泄漏；优先看 OOM、GC 停顿和宿主机是否开始交换内存。 - 确认距离设置：适度降低
view-distance和simulation-distance能减少区块发送与刻更新范围。两者以区块半径计，通常应让模拟距离不高于视距。 - 处理有证据的热点：如果报告指出某插件、实体堆积、红石装置、区块预生成或磁盘写入占用异常，就只针对这一项处理并再次采样。
- 一次只改一组设置：记录改动前后参数与 spark 链接。没有对照，之后就无法知道是哪项设置造成副作用。
常见但风险很高的做法
| 做法 | 为什么不建议 | 更稳妥的替代 |
|---|---|---|
| 一键清掉所有掉落物 | /kill @e[type=item] 会删除玩家刚掉落、交易或红石系统需要的物品。 | 先通过报告确认掉落物确实是热点，再制定公告、白名单或受控清理规则。 |
盲目把 -Xmx 拉满 | 会挤占系统和容器内存，可能触发 OOM 或交换。 | 按实际余量设置上限，使用内存规划工具作为起点。 |
| 复制陌生“优化配置” | 可能改变刷怪、农场、红石或实体行为。 | 先备份原配置，只改已理解且能验证的项。 |
| 一次装多个优化插件 | 负载和兼容性反而更难定位。 | 先用 Paper 默认配置与 spark 报告找到单一问题。 |
关于世界和玩法
性能优化不是把世界“关到不能玩”。高频实体、无人维护的大型机器和过度预生成都会影响负载，但限制规则应提前向玩家说明。对生存服来说，稳定且可预期的体验通常比追求某个漂亮的 TPS 数字更重要。