我正在使用libgdx和android studio制作游戏。我对这两件事情的经验都比较少。我相信我有一个由图形引起的内存泄漏，但我不确定，因为我知道libgdx保留了大量的堆空间。 MAT分析说：
The class "android.content.res.Resources", loaded by "<system class loader>", occupies 17,790,184 (31.63%) bytes. The memory is accumulated in one instance of "android.util.LongSparseArray[]" loaded by "<system class loader>".
19 instances of "java.lang.reflect.ArtMethod[]", loaded by "<system class loader>" occupy 11,902,776 (21.16%) bytes.
Biggest instances:
•java.lang.reflect.ArtMethod[64707] @ 0x70b7e4b0 - 3,894,624 (6.92%) bytes.
•java.lang.reflect.ArtMethod[52675] @ 0x70be6888 - 3,061,192 (5.44%) bytes.
•java.lang.reflect.ArtMethod[21833] @ 0x70000ac0 - 1,336,112 (2.38%) bytes.
•java.lang.reflect.ArtMethod[14651] @ 0x771d2d60 - 966,680 (1.72%) bytes.
•java.lang.reflect.ArtMethod[11453] @ 0x71f964e0 - 806,432 (1.43%) bytes.
•java.lang.reflect.ArtMethod[11047] @ 0x709b39d8 - 662,680 (1.18%) bytes.
205 instances of "android.graphics.NinePatch", loaded by "<system class loader>" occupy 10,041,968 (17.86%) bytes. These instances are referenced from one instance of "java.lang.Object[]", loaded by "<system class loader>"
Keywords
java.lang.Object[]
android.graphics.NinePatch
32 instances of "java.lang.DexCache", loaded by "<system class loader>" occupy 6,358,016 (11.31%) bytes.
Biggest instances:
•java.lang.DexCache @ 0x70b50608 - 1,262,528 (2.24%) bytes.
•java.lang.DexCache @ 0x71d2f870 - 1,177,232 (2.09%) bytes.
•java.lang.DexCache @ 0x70bc4b60 - 903,320 (1.61%) bytes.
•java.lang.DexCache @ 0x72178f80 - 636,768 (1.13%) bytes.
•java.lang.DexCache @ 0x723d13f0 - 633,088 (1.13%) bytes.
如果需要我的代码，我可以提供它，但我不确定要提供哪个部分，因为我不确定泄漏的位置。我非常感谢任何建议
答案 0 :(得分：0)
GC行为随GC策略而变化，例如，如果策略是为了获得最大吞吐量，则JVM将分配对象，直到达到Xmx。当它达到阈值时，GC将启动以清除死亡物体。如果GC策略用于较少的暂停时间a）清除GC和b）全局Gc发生直到全局GC发生，我们无法确保是否清除了死对象。
最好在OOM上收集日志，这意味着GC会尝试清除死对象，然后JVM会抛出OOM错误。如果此时在堆转储上运行MAT，则可以正确找到泄漏嫌疑人。
有关谁正在对泄漏对象持有强引用的更多信息，请像这样编写OQL select * from“packagename.classname”执行后右键单击对象 - ＆gt; GC根路径 - ＆gt;排除soft / Weak / Phantom引用。在这样做时，MAT将提供有关谁持有引用的信息，因为GC没有清除对象。