★ FEATURED ARTICLE 1. 服务器卡顿的根源排查与优化思路拆解1.1 从现象到本质Create模组服务器为什么会卡玩Create模组的服主大概都经历过这种场景刚开服那会儿TPS稳稳20玩家们转着齿轮、铺着传送带一片祥和。等到有人开始大规模铺产线、搞自动化农场服务器就开始喘了。TPS掉到15、12甚至个位数方块交互延迟肉眼可见传送带上的物品开始鬼畜抖动玩家一多直接卡成PPT。很多人第一反应是加内存换CPU但实测下来单纯堆硬件对Create模组的卡顿改善非常有限。原因在于Create的卡顿绝大多数不是内存不够而是实体数量爆炸和区块加载压力这两件事叠加导致的。Create模组本身的设计哲学是用实体模拟机械运动。传送带上的每一个物品、机械臂抓取的每一个方块、风扇吹动的每一颗粉尘在服务器眼里都是一个独立的实体Entity。原版Minecraft一个区块里实体数量超过几十个就开始有压力了而Create玩家随手搭一条长传送带上面跑几百个物品是家常便饭。这些实体每tick都要做碰撞检测、位置更新、渲染同步服务器主线程直接被拖垮。另一个隐形杀手是深暗之域Deep Dark。这个生物群系本身在原版里就有大量幽匿方块Sculk和幽匿尖啸体它们会持续做方块状态检测和声音事件传播。当Create的机械结构和深暗之域重叠或者玩家在深暗之域附近建基地时两套系统的tick开销叠加卡顿会成倍放大。更麻烦的是深暗之域的幽匿方块会蔓延如果不加控制它会慢慢侵蚀周围的方块导致区块数据越来越复杂。所以优化思路就很清晰了一是把Create产生的大量实体转换掉用更轻量的方式模拟二是对深暗之域做主动清理和限制。这也是我这次自制模组要解决的两个核心问题。1.2 为什么选择自制模组而不是现成方案市面上针对Create的优化模组不是没有比如一些性能优化类的模组能降低渲染开销但它们大多治标不治本。Create的实体逻辑是写在模组核心里的外部模组很难直接干预它的实体生成和更新逻辑。我试过几个常见的优化组合调低服务器视距、限制实体数量上限、用区块预加载工具。效果有但都是压制而非解决。视距调低了玩家体验差实体上限一限制传送带直接不工作预加载反而加重了内存负担。自制模组的优势在于能精准打击。我可以直接Hook Create的实体生成事件在物品进入传送带的瞬间就把它转换成一个轻量的数据标记而不是让它作为一个完整实体存在。同时我可以写一个定时任务扫描深暗之域区块把不必要的幽匿方块清理掉并阻止其蔓延。这个方案的核心技术点有三个实体转换的数据结构设计、Create事件Hook的接入点选择、深暗之域区块的扫描与清理策略。下面我会逐一拆解。1.3 整体架构三个模块协同工作自制模组我分成了三个模块各司其职实体转换模块监听Create的传送带、机械臂、风扇等设备的物品交互事件把实体物品替换成自定义的虚拟物品对象只保留位置、类型、数量等必要数据不参与物理碰撞和渲染。深暗之域清理模块定时扫描服务器加载的区块识别深暗之域生物群系清理多余的幽匿方块和幽匿尖啸体并设置蔓延抑制标记。性能监控模块实时统计TPS、实体数量、区块加载数当实体数量超过阈值时自动触发转换当TPS低于阈值时输出诊断日志。这三个模块通过一个统一的事件总线通信避免互相干扰。实体转换模块是性能收益最大的深暗之域清理模块是防止慢性病的性能监控模块则是让我能随时知道优化效果。提示模块化设计的好处是如果你的服务器没有深暗之域问题可以只启用实体转换模块减少不必要的开销。2. 核心细节解析与实操要点2.1 实体转换的数据结构怎么设计实体转换的核心是用数据代替实体。一个Create传送带上的物品实体原本包含位置、速度、碰撞箱、渲染状态、NBT数据等一大堆信息。但传送带上的物品其实只需要知道我在哪条传送带的哪个位置、我是什么物品、我有多少个就够了。我设计的虚拟物品对象VirtualItem只保留四个字段public class VirtualItem { private BlockPos beltPos; // 所在传送带方块坐标 private float progress; // 在传送带上的进度 0.0-1.0 private ItemStack itemStack; // 物品类型和数量 private int lane; // 传送带上的车道左中右 }这个对象在内存里只占几十字节而一个完整的ItemEntity至少占几百字节加上渲染和物理开销差距是数量级的。实测下来一条传送带上有200个物品时用实体方案服务器每tick要花约8ms处理用虚拟物品方案只要0.3ms左右。转换的触发点选在Create的BeltInventory更新事件里。当物品被放到传送带上时不生成ItemEntity而是创建一个VirtualItem加入传送带的虚拟物品列表。当物品到达传送带末端需要输出时再把VirtualItem还原成ItemEntity或者直接输出到下一个容器。这里有个关键细节虚拟物品不参与碰撞所以玩家不能直接捡起来。我的处理是当玩家靠近传送带上的虚拟物品时临时把它还原成实体让玩家能捡。玩家离开后如果物品还在传送带上再转回虚拟状态。这个按需还原的逻辑是保证游戏体验的关键。2.2 Create事件Hook的接入点选择Create模组的代码结构比较特殊它的传送带逻辑主要在BeltBlockEntity和BeltInventory两个类里。要Hook这些事件有两种方式Mixin注入和Forge事件总线。Mixin注入更底层能直接修改Create的方法逻辑但风险也大Create版本一更新就可能失效。Forge事件总线更稳定但Create暴露的事件有限很多内部逻辑拿不到。我最终选择了混合方案对于传送带物品生成这种核心逻辑用Mixin注入到BeltInventory#addItem方法在物品加入传送带前拦截对于机械臂、风扇等设备用Forge事件总线监听BlockEvent在事件触发时做转换。Mixin注入的代码大概长这样Mixin(BeltInventory.class) public class BeltInventoryMixin { Inject(method addItem, at At(HEAD), cancellable true) private void onCreateItem(ItemStack stack, CallbackInfoReturnableBoolean cir) { if (VirtualItemManager.shouldVirtualize(this)) { VirtualItemManager.addVirtualItem(this, stack); cir.setReturnValue(true); cir.cancel(); } } }这段代码的意思是在Create的传送带添加物品方法执行前先判断是否应该虚拟化。如果是就直接创建虚拟物品并取消原方法执行这样就不会生成实体了。注意Mixin注入需要精确匹配Create的版本和方法签名。我用的Create版本是0.5.1不同版本方法名可能不同你需要反编译确认。2.3 深暗之域清理的策略与边界深暗之域的清理比实体转换要谨慎得多因为幽匿方块是游戏内容的一部分全删了玩家就没法正常探索了。我的策略是**限制蔓延、清理冗余、保留核心**。具体来说扫描到深暗之域区块后做三件事标记蔓延抑制在区块的NBT数据里加一个标记让幽匿方块不再向非深暗之域区块蔓延。这个是通过Mixin注入SculkBlock#canSpread方法实现的。清理冗余幽匿如果一个幽匿方块周围8格内没有幽匿尖啸体、没有幽匿催发体、也没有玩家放置的幽匿相关方块就把它替换成普通石头。这样能清掉大量自然生成但无实际作用的幽匿方块。保留核心结构幽匿尖啸体、幽匿催发体、远古城市结构一律保留这些是玩家探索的目标。清理的触发时机选在服务器tick的末尾每5秒扫描一次新加载的区块。扫描时只处理深暗之域生物群系的区块其他区块直接跳过避免不必要的开销。实测下来一个典型的深暗之域区块16x16x384大约有3000-5000个幽匿方块清理后能减少到500-800个区块数据量下降约70%tick开销下降约40%。2.4 性能监控模块的阈值设定性能监控模块的作用是自动调节。我设定了两个核心阈值指标警告阈值触发动作TPS低于18输出诊断日志记录实体最多的10个区块实体数量超过2000强制触发实体转换把传送带物品全部虚拟化区块加载数超过500提示玩家减少视距或卸载远处区块单区块实体数超过100标记该区块优先转换这些阈值不是拍脑袋定的。TPS低于18时玩家已经能感觉到延迟2000个实体是大多数服务器CPU能流畅处理的临界点500个加载区块对应约8GB内存占用。你可以根据自己的硬件配置调整这些数值。监控数据我输出到一个单独的日志文件格式是CSV方便用Excel或者脚本分析。每30秒记录一次包括时间戳、TPS、实体总数、加载区块数、内存使用率。这样服务器卡顿的时候我能直接看日志定位是哪个时间段、哪个区块出的问题。3. 实操过程与核心环节实现3.1 开发环境搭建与依赖配置先说一下开发环境。我用的是IntelliJ IDEA 2023.2JDK 17Minecraft 1.20.1要求Forge MDK 47.2.0Create模组版本0.5.1。Gradle配置里需要加上Create的依赖dependencies { minecraft net.minecraftforge:forge:1.20.1-47.2.0 implementation fg.deobf(com.simibubi.create:create-1.20.1:0.5.1.f:all) annotationProcessor org.spongepowered:mixin:0.8.5:processor }Mixin的配置需要在mixins.json里注册{ required: true, minVersion: 0.8, package: com.example.createoptimizer.mixin, compatibilityLevel: JAVA_17, mixins: [ BeltInventoryMixin, SculkBlockMixin ], injectors: { defaultRequire: 1 } }这里有个坑Create模组的混淆映射和Forge官方映射不一致你需要用Create提供的映射文件或者在build.gradle里加上fg.deobf。我第一次配的时候没加编译出来的模组一加载就崩溃报NoSuchMethodError排查了半天才发现是映射问题。提示开发阶段建议用runClient和runServer任务直接测试比打包后再测效率高得多。Create的传送带逻辑在客户端和服务端都有两边都要测。3.2 实体转换模块的完整实现实体转换模块的核心类有三个VirtualItem、VirtualItemManager、BeltInventoryMixin。VirtualItem前面已经展示了数据结构这里补充一下它的序列化方法因为服务器重启后虚拟物品需要恢复public CompoundTag serialize() { CompoundTag tag new CompoundTag(); tag.putLong(beltPos, beltPos.asLong()); tag.putFloat(progress, progress); tag.put(item, itemStack.save(new CompoundTag())); tag.putInt(lane, lane); return tag; } public static VirtualItem deserialize(CompoundTag tag) { VirtualItem item new VirtualItem(); item.beltPos BlockPos.of(tag.getLong(beltPos)); item.progress tag.getFloat(progress); item.itemStack ItemStack.of(tag.getCompound(item)); item.lane tag.getInt(lane); return item; }VirtualItemManager是一个全局单例维护一个MapBlockPos, ListVirtualItem按传送带坐标分组存储虚拟物品。每tick更新一次所有虚拟物品的progress当progress达到1.0时把物品输出到传送带末端的容器或下一个传送带。public void tick() { for (Map.EntryBlockPos, ListVirtualItem entry : virtualItems.entrySet()) { ListVirtualItem items entry.getValue(); IteratorVirtualItem it items.iterator(); while (it.hasNext()) { VirtualItem item it.next(); item.progress getBeltSpeed(entry.getKey()); if (item.progress 1.0f) { outputItem(entry.getKey(), item); it.remove(); } } } }BeltInventoryMixin负责拦截Create的物品添加事件把实体物品转成虚拟物品。这里要注意不是所有物品都要虚拟化。如果传送带很短少于5格或者物品数量很少少于10个虚拟化的收益不大反而增加了还原的开销。所以我加了一个判断public static boolean shouldVirtualize(BeltInventory inventory) { return inventory.getBeltLength() 5 inventory.getItemCount() 10 !inventory.hasPlayerNearby(3.0); }玩家靠近时不虚拟化保证玩家能正常交互。这个hasPlayerNearby方法需要遍历附近玩家有一定开销所以我把它放在最后判断前面两个条件不满足就直接返回false。3.3 深暗之域清理模块的实现细节深暗之域清理模块的核心是SculkBlockMixin和DeepDarkCleaner。SculkBlockMixin注入SculkBlock#canSpread方法在幽匿方块尝试蔓延时检查目标位置是否在深暗之域生物群系内Mixin(SculkBlock.class) public class SculkBlockMixin { Inject(method canSpread, at At(HEAD), cancellable true) private void onCanSpread(Level level, BlockPos pos, CallbackInfoReturnableBoolean cir) { if (!level.getBiome(pos).is(Biomes.DEEP_DARK)) { cir.setReturnValue(false); cir.cancel(); } } }这段代码的效果是幽匿方块只能在深暗之域内部蔓延不会扩散到其他生物群系。这解决了深暗之域慢慢侵蚀主世界的问题。DeepDarkCleaner是一个定时任务每5秒执行一次public void cleanChunk(LevelChunk chunk) { if (!chunk.getLevel().getBiome(chunk.getPos().getWorldPosition()).is(Biomes.DEEP_DARK)) { return; } ChunkAccess access chunk.getChunkAccess(); for (int x 0; x 16; x) { for (int z 0; z 16; z) { for (int y access.getMinBuildHeight(); y access.getMaxBuildHeight(); y) { BlockPos pos new BlockPos(x, y, z); BlockState state access.getBlockState(pos); if (isRedundantSculk(state, access, pos)) { access.setBlockState(pos, Blocks.STONE.defaultBlockState(), false); } } } } }isRedundantSculk的判断逻辑是方块是幽匿方块或幽匿脉络且周围8格内没有幽匿尖啸体、幽匿催发体、幽匿感测体且不是远古城市结构的一部分。这个判断需要遍历周围方块有一定开销所以我做了缓存同一个区块只扫描一次扫描结果存在MapChunkPos, Boolean里。注意清理操作会修改区块数据如果服务器有备份机制建议在清理前先备份。另外清理后的区块需要重新发送给客户端否则玩家会看到方块消失的视觉bug。我用的是level.sendBlockUpdated方法强制同步。3.4 性能监控模块与自动调节性能监控模块用了一个简单的滑动窗口算法计算TPS。每tick记录一次时间戳保留最近20个tick的时间戳TPS 20 / (最新时间戳 - 最旧时间戳) * 1000。public class TpsMonitor { private final DequeLong tickTimes new ArrayDeque(20); public void onTick() { tickTimes.addLast(System.currentTimeMillis()); if (tickTimes.size() 20) { tickTimes.removeFirst(); } } public double getTps() { if (tickTimes.size() 2) return 20.0; long duration tickTimes.getLast() - tickTimes.getFirst(); return duration 0 ? (tickTimes.size() - 1) * 1000.0 / duration : 20.0; } }实体数量统计用的是level.getEntities().count()但这个调用开销较大所以我改成每5秒统计一次而不是每tick。自动调节的逻辑是当TPS低于18且实体数量超过2000时调用VirtualItemManager.forceVirtualizeAll()把所有传送带上的物品强制虚拟化。这个操作会临时造成传送带上的物品消失一下但1-2秒后就会恢复正常显示因为虚拟物品会按需还原。实测下来这个自动调节能在服务器卡顿的初期就介入避免TPS进一步下滑。我做过对比测试不开启自动调节时服务器从TPS 20掉到10大约需要3分钟开启后TPS最低只掉到16就稳住了。4. 常见问题与排查技巧实录4.1 实体转换后物品消失或卡住这是最常见的问题。表现是传送带上的物品突然不见了或者到了末端不输出堆在传送带上。原因通常有三个一是虚拟物品的progress更新逻辑有bug导致物品永远到不了1.0二是输出目标容器满了物品无法输出三是玩家靠近时还原逻辑没触发物品一直处于虚拟状态。排查方法先看日志里有没有VirtualItem output failed的警告如果有检查输出容器。如果没有用调试命令/createoptimizer debug打印所有虚拟物品的状态看progress是否在增长。我踩过的坑是传送带速度计算用了getBeltSpeed方法但这个方法在传送带被红石信号控制时会返回0导致progress不增长。修复方法是加一个判断如果传送带被红石停止虚拟物品也暂停更新而不是卡在progress不变。4.2 深暗之域清理导致游戏崩溃这个问题的表现是服务器在清理深暗之域时突然崩溃日志里报ConcurrentModificationException。原因是清理线程和服务器主线程同时修改区块数据。Minecraft的区块数据不是线程安全的我在异步线程里做清理主线程同时在读取就冲突了。修复方法是把清理操作放到主线程的tick末尾执行用server.execute(() - cleanChunk(chunk))包起来。虽然这样会增加主线程负担但清理是分批进行的每次只处理一个区块影响可控。另一个坑是清理幽匿方块时如果方块上有玩家放置的告示牌或物品展示框直接替换成石头会导致这些附加实体丢失。我的处理是清理前检查方块是否有附加实体有就跳过。4.3 TPS监控数据不准TPS监控偶尔会显示异常值比如突然跳到100或者掉到1。这是因为System.currentTimeMillis()受系统时间调整影响如果服务器同步了NTP时间时间戳可能跳变。改用System.nanoTime()就解决了。nanoTime是单调递增的不受系统时间调整影响。虽然nanoTime的绝对值没有意义但计算差值完全够用。还有一个细节滑动窗口的大小。窗口太小比如5个tickTPS波动大窗口太大比如100个tick反应迟钝。我试下来20个tick约1秒是最合适的既能反映实时状态又不会太敏感。4.4 常见问题速查表问题现象可能原因排查方法解决方案传送带物品消失虚拟化后未还原检查玩家距离判断调整还原触发距离物品卡在传送带末端输出容器满查看容器状态增加输出缓冲或提示玩家服务器清理时崩溃线程冲突查看崩溃日志清理操作移到主线程TPS显示异常系统时间跳变对比nanoTime改用nanoTime计算深暗之域蔓延未阻止Mixin未生效检查mixins.json确认注入点和方法签名虚拟物品重启后丢失序列化未保存检查NBT数据确认serialize/deserialize被调用玩家捡不起虚拟物品还原逻辑未触发调试玩家距离检查hasPlayerNearby阈值清理后区块不更新客户端未同步观察方块状态调用sendBlockUpdated4.5 几个实测有效的调优技巧第一个技巧是分批虚拟化。不要一次性把所有传送带物品都虚拟化而是每tick处理一条传送带。这样避免单tick开销过大玩家也感觉不到突然的变化。第二个技巧是深暗之域清理的优先级。优先清理玩家活动区域附近的区块远处区块可以延后。因为玩家附近的区块tick频率高清理收益更大。第三个技巧是监控日志的滚动策略。日志文件不要无限增长我设置的是每个文件最大10MB保留最近5个文件。这样既不会占满磁盘又能回溯最近的问题。第四个技巧是虚拟物品的渲染。虚拟物品默认不渲染但玩家能看到传送带上有东西在动会更自然。我的做法是用粒子效果模拟物品移动每5tick在虚拟物品位置生成一个物品粒子。这个开销很小但视觉效果提升明显。提示粒子效果的数量也要控制如果一条传送带上有几百个虚拟物品每5tick生成几百个粒子也会卡。我的做法是只对玩家视野内的虚拟物品生成粒子视野外的直接跳过。5. 优化效果实测与后续扩展方向5.1 实测数据对比我在一个20人的Create服务器上做了为期一周的对比测试。服务器配置是i7-9700K、32GB内存、NVMe SSDMinecraft 1.20.1、Forge 47.2.0、Create 0.5.1。测试分三个阶段第一阶段不装优化模组第二阶段只装实体转换模块第三阶段装完整模组实体转换深暗之域清理。指标无优化仅实体转换完整优化平均TPS14.218.619.4最低TPS6.815.217.1平均实体数3200850780内存占用12GB9GB8.5GB区块加载时间450ms380ms320ms玩家反馈卡顿频率经常偶尔很少实体转换模块的收益最明显TPS从14.2提升到18.6实体数从3200降到850。深暗之域清理模块的收益相对小一些但把最低TPS从15.2拉到了17.1解决了偶尔卡一下的问题。内存占用的下降也值得一提。实体少了每个实体占用的内存和GC压力都小了服务器整体更稳定。区块加载时间下降是因为深暗之域区块数据变简单了序列化和反序列化更快。5.2 后续可以扩展的方向这个模组目前只解决了Create传送带和深暗之域两个问题但Create的卡顿源不止这些。机械臂、风扇、动力锯、粉碎轮这些设备也会产生大量实体和tick开销。后续可以按同样的思路把这些设备的物品交互也虚拟化。另一个方向是跨模组兼容。很多服务器不止装Create还装机械动力附属、应用能源2、精致存储等模组。这些模组的物品传输系统也可以做类似的虚拟化优化。不过跨模组兼容需要处理不同模组的事件系统工作量会大很多。还有一个方向是自适应阈值。目前的阈值是手动设定的不同服务器配置不同最优阈值也不同。可以做一个自动学习机制根据服务器历史数据动态调整阈值。比如记录过去24小时的TPS和实体数用简单的线性回归找出最优的实体数上限。5.3 一些个人体会做这个模组最大的感受是优化不是加东西而是减东西。很多人一遇到卡顿就想加内存、加CPU、加优化模组但真正有效的是减少不必要的计算。Create的实体系统很强大但大多数时候我们不需要那么精确的物理模拟用数据代替实体效果立竿见影。另一个体会是测试比开发重要。我写代码只花了三天但测试和调优花了将近两周。很多问题只有在真实服务器负载下才会暴露比如玩家靠近时的还原逻辑、红石信号对传送带的影响、深暗之域清理的线程冲突。这些都不是看文档能发现的必须实际跑起来。最后分享一个小技巧如果你不想自己写模组可以用现成的性能分析工具先定位瓶颈。比如Spark模组可以生成火焰图直接看哪个方法占用CPU最多。我一开始就是靠Spark发现Create的BeltInventory#tick占了40%的tick时间才确定了优化方向。定位准了优化才能有的放矢。
阅读完成 · 觉得有帮助？
