java - linux/java 中的精确事件计时

Question

我正在用 Java 编写一个游戏，它在后台进行一些机器学习以进行程序生成，我希望它在 n 毫秒 后短暂地从后台训练例程中退出以渲染帧并更新NPC 等等。

关键是 n 不能被高估，因为游戏需要在所有可用的硬件上将帧锁定到 16 毫秒，而 lgwjl 中的渲染内容本身就是一种平衡行为。

问题是 System.nanoTime() 似乎在我的环境中不起作用(它导致超时比预期小几个数量级；根据我的经验，HPC 计时器非常不稳定) .并且 System.getCurrentTimeMillis 似乎没有明确指定的舍入行为，这意味着它可能会高估近一毫秒，这是 Not Acceptable 。

有没有人知道是否有好的方法来做到这一点？

Answer 1

这样做你会很痛苦。您所描述的本质上是上下文切换操作系统(或 JVM，在 Java 的情况下)应该从需要直接使用中抽象出来。

相反，您应该有一个线程来处理业务逻辑，以及一个完全独立的线程来管理和更新显示。这两个线程然后通过一个 Controller 进行通信，该 Controller 要么在自己的线程中运行，要么在与业务逻辑线程相同的线程中运行，具体取决于数据传输的复杂性。这个概念叫做 Model-View-Controller pattern , 和 many, many articles已经写了如何最好地实现它。

通过分离这些行为，您可以让您的业务逻辑连续运行而无需中断，并且您的 View 线程可以非常简单，基本上如下所示:

while(true) {
  long initTime = curTime();
  // this will refresh the GUI and also show any new data from the controller
  refresh(); 
  sleep(curTime()-initTime);
}

当然，我认为您的问题的核心是我在上面调用的这个神奇的 sleep() 方法。我将更新所花费的时间传递给它，以便它可以从所需的总 sleep 时间中减去该时间，但是如何确保实际 sleep 时间高度精确的问题更为复杂。

您说 System.nanoTime() 在您的环境中不精确，不幸的是，这很可能成为您的交易破坏者。 System.nanoTime() 将提供您的操作系统/处理器正在发布的最精细的耗时数据，因此如果此方法未提供您需要的数据，您的机器/JVM 可能无法提供您需要的粒度。

主要的游戏/模拟开发人员面临着同样的问题，并且早就通过消除精确的帧更新时间的要求来解决这个问题，因为尝试以任何可靠的方式将处理时间与现实世界的时间对齐实在太复杂了(假设，例如，操作系统暂停您的程序几毫秒，这样处理下一帧将花费比允许的时间更长的时间，您会怎么做？)。

相反，游戏和模拟等可视化的总体目标是尽可能计算模型的最新状态，并允许 View 尽可能查询新信息。考虑下表:

| Time | Model | Slow View | Med. View | Fast View |
|    1 |     1 |         1 |         1 |         1 |
|    2 |       |           |           |         1 |
|    3 |     3 |           |           |         3 |
|    4 |       |           |         3 |         3 |
|    5 |     5 |           |           |         5 |
|    6 |       |         5 |           |         5 |
|    7 |     7 |           |         7 |         7 |
|    8 |       |           |           |         7 |
|    9 |       |           |           |         7 |
|   10 |    10 |           |        10 |        10 |
|   11 |       |        10 |           |        10 |
|   12 |    12 |           |           |        12 |
|   13 |       |           |        12 |        12 |
|   14 |    14 |           |           |        14 |
|   15 |       |           |           |        14 |
|   16 |    16 |        16 |        16 |        16 |

在这里，我们看到任意时间单位(系统上可用的最精确度)传递一个模型，该模型尽快计算给定时间的状态，以及试图显示最新状态的 View 它可用的日期状态。 View 可以运行得越快，达到模型的速度， View 在视觉上就会显得越平滑，如果 View 运行得比这快，这并不是真正的问题，尽管它不会变得更平滑。但无论如何，从用户的角度来看，模型的状态是实时更新的。

这里的关键见解是让您的模型计算给定时刻的状态，无论该值可能是多少，而不是试图让您的模型以任何精确的速率运行，这在共享上基本上是不可能的硬件。