Java：wait() 将 fps 限制为 64答案

【问题标题】：Java: wait() limits the fps to 64Java：wait() 将 fps 限制为 64
【发布时间】：2012-02-28 22:05:48
【问题描述】：

我在主循环中的代码中有这个（窗口中的 2D 游戏）：

try{
  synchronized(this){

    wait(3);
  }
}
catch(Exception ex) {
  System.out.println(ex);
}

这段代码导致 FPS 上限为 64，我不知道为什么。我不使用任何其他同步块。有趣的是，当网络浏览器打开时，fps 不再有上限。谁能告诉我如何摆脱 64 fps 的限制？我没有找到与此问题相关的任何其他主题。

编辑：

无需等待(3)； - 180 帧/秒。
等待 (3) 和浏览器 (Opera) 打开 - ~113 fps。
使用 wait(3) 且不使用浏览器 - 64 fps。

浏览器怎么会改变fps？

【问题讨论】：

谁在做匹配的 notify() 调用？
不封顶时你能得到多少 FPS？
FPS 在没有上限且没有指定 notify() 调用时约为 115。

标签： java limit wait synchronized frame-rate

【解决方案1】：

虽然wait 和sleep 的参数分辨率以毫秒为单位，但您几乎可以肯定永远不会得到您请求的确切延迟。

在 Windows 系统上，分辨率约为 15 毫秒，即 1000/15 = 66fps

【讨论】：

那么如何在后台运行网络浏览器（Opera）绕过它呢？
@JanBurak - 您的wait(3) 通常至少等待 15 毫秒。我不知道为什么 Opera 有帮助。也许它会增加刻度分辨率。我相信 Oracle 数据库可以。
哦，我明白了。我测量了等待前后的时间。在浏览器打开的情况下，时差是 0（根本没有等待）和其他时候 15-16 在一秒钟内。感谢您指出它实际上需要 15 毫秒而不是我想的 3 毫秒（我只是一个初学者，所以几乎所有信息对我来说都很重要）。如果没有浏览器，差异总是 15 或 16，因此浏览器必须以某种方式干扰 wait()。

【解决方案2】：

如果你不使用任何其他同步块，那么你的线程就没有人notify()。这意味着您可能会告诉您的应用在每次迭代时至少休眠 3 毫秒。此外，您可能会因为线程在进入睡眠状态时放弃其时间片而损失更多时间，并且时钟分辨率通常也超过 1 毫秒，具体取决于操作系统。

64 FPS 意味着一帧需要略高于 15 毫秒。告诉我们您的“无上限”FPS 是多少，计算每帧转换多少毫秒，看看有什么区别。如果没有丢失代码的帧时间差异约为 3-10 毫秒（10 毫秒可能是正常系统上时钟粒度的合理上限），这可能只是wait() 的结果.如果没有 wait() 你的帧只需要 1 毫秒，可能会有一些额外的效果。

在 Jan 的评论后编辑：115 FPS 意味着每帧 8.7 毫秒。因为wait(3) 从那个到 15 似乎是可能的。我不确定在后台运行另一个应用程序会如何影响它。也许在后台有另一个任务会影响调度程序的行为。其他任务是否使 FPS 回到 115 或某个中间值？

在 Jan 的第二条评论后编辑：如果是 180 而不是 115，我们每帧有 5.5 毫秒。这增加了差异，但由于 Windows 时钟相当粗糙（正如其他人指出的那样），这仍然在上述效果的范围内。

【讨论】：

无需等待(3); - 180 帧/秒。等待（3）和浏览器打开 - 113 fps。使用 wait(3) 且不使用浏览器 - 64 fps。让我困惑的是浏览器让它运行得更快。

【解决方案3】：

不要试图获得超过 60 fps。现代显示器的显示速度不会超过 60fps。

【讨论】：

问题是 fps 可能会下降到 60 以下，但实际上 fps 更稳定并且不会像设置上限时下降那么多。我仍然很好奇是什么导致了限制？
诀窍是不要低于 60fps。但是不需要计算更多的帧数。