空的 LibGdx 游戏循环泄漏内存答案

【问题标题】：Empty LibGdx game loop leaks Memory空的 LibGdx 游戏循环泄漏内存
【发布时间】：2014-01-07 16:13:32
【问题描述】：

我正在调试我使用 Eclipse 的 libGdx 库编写的游戏。我有大量的内存泄漏，所以我在渲染循环中注释掉了行，直到我一无所有。但应用程序的 RAM 仍在上升。我最终使用 GTX 设置 UI 创建了一个全新的项目。当我开始它时，发生了同样的事情。它仍然以大约 ca 的速度上升。每秒 4 千字节。不多，但就是停不下来。在查看堆数据时，我看到 com.badlogic.gdx.backends.lwjgl.LwjglInput 可能是导致它的原因。但是我什至不知道我是否应该改变一些东西，当这个“问题”甚至出现在 GTX 设置 UI 创建的项目中时。这对于应用程序来说是否正常？我一直等到它从 34'800K 增加到 40'000K，所以它可能永远不会停止。这最终会导致 OutOfMemory 异常吗？（顺便说一句。我使用 Windows 任务管理器获取 RAM 值。而且我使用的是 Eclipse）

【问题讨论】：

实际上它并不（必然）意味着存在内存泄漏。也可能是垃圾收集器尚未运行以进行清理。
嗯...但是垃圾收集器不应该在整整 10 分钟后运行吗？还是在 5000 KB 之后？还是我必须告诉垃圾收集器这样做？
好的，我想现在它正在工作。我每秒调用 System.gc()，现在 RAM 使用量从 35'000 飙升至 39'000 后平均保持在 39'000。感谢您的提示。

标签： java windows eclipse memory-leaks libgdx

【解决方案1】：

不一定是内存泄漏。何时触发垃圾收集器可能非常随机，有时很长一段时间都不会发生。特别是如果只有 4kb/s 被分配。 GC 的触发也取决于你运行的 JVM。Android 上的 Dalvik 可能会更早地触发它。

你自己试过，自己调用System.gc()触发GC，证明不是内存泄漏，只是懒惰的垃圾收集器。

在桌面上（LWJGL 后端仅表示桌面）这不是很重要，因为您不会感觉到垃圾收集器。在移动后端，我希望 libgdx 开发人员对新实例更加小心，这意味着他们可能会比其他后端更多地使用池，以尽可能避免垃圾收集器。

【讨论】：

垃圾收集器偷懒当然不是真正的问题，要手动戳它直到它醒来；垃圾收集器可能确定不需要任何操作，因为剩余的堆已经足够多。它会在必要时运行——在程序运行期间甚至可能永远不会运行。鉴于它是一款游戏，我实际上更希望它尽可能少地开火。
因为没有人指出它是惰性垃圾收集器。如果你在执行期间不手动调用垃圾收集器是可取的......

【解决方案2】：

通过添加-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 作为VM 参数记录GC，您将看到GC 何时自动调用。要查看您的应用程序真正需要多少 RAM，请使用 Oracle 提供的工具 (jconsole.exe)。你看到的其他一切都不正确。您只看到虚拟机，它并不等同于程序本身。（在桌面上，我的应用程序确实有 80mb 的内存，但游戏本身只需要 11mb 左右！）您还可以查看是否在不“删除”它们的情况下始终生成大量对象。如果是这样，你需要检查你的主循环，如果你在其中创建了你显然不应该做的对象。只需检查程序，它就会告诉您很多有关您的应用程序的信息。但它只适用于桌面版本。但由于桌面与 android 版本“相似”，因此您应该可以使用它。

System.gc() 是一个很好的转折点，但如果你在主循环中调用它会消耗很多时间，因为它是一种“深度清理”。所以尽量避免这种情况。在 mapchanges 或类似的东西上调用它，你不会注意到滞后。

【讨论】：

哇！！谢谢，我整天都在寻找这样的工具！

【解决方案3】：

如果 System.gc() 解决了您的问题，那只是，就像其他人所说的惰性 GC。但通常 GC 会在需要时自动运行。因此，您不应将 System.gc() 称为 1) 它只告诉 GC 他应该运行，但不确定他是否这样做，并且 b) GC 需要很多时间，所以如果您想每秒都这样做，即使没有必要，它可能会导致 FPS 下降。如果您对 System.gc() 感兴趣，有很多关于它的讨论。大多数程序员说这是不好的做法，GC 知道他应该什么时候运行。

【讨论】：