空LibGdx游戏循环泄漏内存

Question

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

Answer 1

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

当你自己尝试时，调用System.gc()来自动触发GC会证明它不是内存泄漏，而只是一个懒惰的垃圾收集器。

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

Answer 2

通过添加-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps作为VM参数来记录GC，您将看到自动调用GC的时间。要查看应用程序确实需要多少RAM，请使用Oracle中的工具（jconsole.exe）。你看到的其他一切都不正确。你只看到VM，它对程序本身不具有普遍性。 （在桌面上我的应用程序确实有80mb的内存，但游戏本身只需要大约11mb！）你还可以看到你是否一直生成很多对象而不“删除”它们。如果是这样，你需要检查你的主循环，如果你在其中创建你明显不应该做的对象。只需检查一下它会告诉你很多关于你的应用程序的东西。但它只适用于desktopverison。但由于桌面是Android版本的“simelar”，你应该可以使用它。

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

Answer 3

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