你还在为你的大型 PaperMC 插件性能差劲而烦恼吗？来看看这些 tips 吧。

常见卡顿原因

在 Minecraft 的设计里，你的插件所有逻辑都是串行的，当你插件的某部分逻辑无法在指定时间内完成相应的任务则会造成卡顿。

我们一般使用 TPS（Tick Per Second）来衡量服务器是否能按照预期的执行速度来执行整个游戏内加载好的逻辑，默认情况下这个数值是 20，当你的服务器当前 TPS 低于 20那么意味着你的服务器已经***过载（Overloaded）***了。

• 计算瓶颈
  • 实体过多导致的过载
  • 算法缺陷
  • 加载项过多
  • 设计失误
• IO 瓶颈
  • 主线程访问数据库
  • 主线程访问外部网络
  • 缓存过载

可以使用 PaperMC 自带的 Spark 简单分析瓶颈出现在什么地方。

但，这些都是有 tradeoff 的：我们需要牺牲一些实时性来利用更强大的计算资源利用

优化手段

优化将会围绕两个重要的点进行：优化计算瓶颈，还是优化 IO 瓶颈？

计算瓶颈

对于计算瓶颈而言除了优化算法以外还可以优化架构等，优化算法算是个很小的切入点

分离计算到其他线程

假设我们可以从原始架构访问到基础类型，那么我们可以通过值传递的方式构造一个函数 ，令 为我们预期的副作用或者预期的值，使得该副作用可以以干净的方式包装起来应用到目标上，这样就实现了封装副作用的目的

举个例子

// 以下代码是在主线程外进行的 //
// 通过各种包装使得 f 是一个可以安全地在主线程外计算的函数
var someHeavyComputing = f();
Bukkit.getScheduler().runTask(pluginInstance, () -> {
    // 在完成计算后以同步的方式应用回计算结果，使得副作用可控
    applyHeavyComputingResult(someHeavyComputing);
});

使用 Singleflight

如果对于一个表达式会反复求值，并且其输入和输出可以遇见地一致，那么可以使用 Singleflight 等方式缓存下来该表达式的结果，在接下来的运算中将有机会节约该次运算的计算损耗。

任务队列

可以通过任务队列的方式限制执行数量，每 tick 只取指定数量任务执行

由于任务队列处理器可以感知处理任务消耗的时间，因此甚至可以实现智能截断防止任务过多使得服务器过载

因此可以实现以下几种任务执行策略：

• 溢出式
  • 该策略允许执行固定数量的任务，比如 1024 个任务、
  • 执行器只会执行小于等于 1024 个任务，多出来的任务本轮将不执行
• 自动截断
  • 由于执行器可以感知已消耗的时间，因此可以在本轮任务即将超时或者已经超时时停止继续执行任务
• 抛弃式
  • 只执行 1024 个任务，多余任务将会被抛弃

针对性缓存

可以利用精度缩减等方法来粗化搜索的粒度，并且实现针对性的缓存使得可以构建一个高效的缓存系统

精度缩减是一个很笼统的说法，举个例子：

• 将坐标归一化到方块中心，以方块中心为中心点开始搜索实体
• 由于已经归一化到方块中心并且搜索所有实体，该步骤可以缓存下来，本次 tick 都可以利用该缓存

对于这种很耗时的搜索，同时可以归约一下搜索范围为统一的几个值使得缓存可以被更高效利用：例如规定代码内使用的搜索范围为 3, 6, 8 等几个值

IO 瓶颈

很喜闻乐见的，有不少插件作者贪图简单选择直接在主线程里使用非常耗时的 IO 请求，这是难以避免的

分离 IO 逻辑到其他线程

该部分做法和上文提到的分离计算到其他线程做法一致，都是封装副作用在线程外计算，随后在主线程内应用。

不过你应该结合 Java 的异步基建来实现这一点：例如 Future